Should I have user stories dealing with the case where user is not authenticated?

Question

In my software, a lot of services expect user to be authenticated before performing.

In positive scenarios, I have this kind of context:

Given I am authenticated
When I create meeting X
Then meeting X is well created 

I am used to write a symmetrical scenario like this for each of my services that deals with user authentication requirement:

Given I am not authenticated  //note the 'not' word
When I create meeting X
Then meeting X is not created
And an authentication error should be thrown

It forces developer to handle check of user authentication at the top of the service implementation, to prevent any potential "hacker" or malicious code to call the API (in this example 'meeting creation') directly while not being authenticated.

Is it a practice I should keep?
Am I right to consider this "defensive" scenario as a real business rule that I may discuss with "Business" team?

Note that my acceptance tests do not test through the GUI part, but only directly through the use cases part (services / business rules).

Answer 1

Short answer: yes, it is perfectly fine to account for negative cases.

I'm used to seeing this a bit differently. Usually a User Story is one step up like:

As a user, I'd like to be able to add a meeting on the calendar so that I can track my schedule for the day"

Then I would have both of these as acceptance criteria on that story.

This recommendation is more a matter of style though. I like this because it groups them better so that important business cases don't fall through the cracks. What you are doing is certainly not wrong.

Answer 2

Capture Business Concepts (Not Engineering Steps) In Gherkin

Is it a practice I should keep?

Maybe. Negative test cases, like boundary conditions, are good things to test from a quality assurance perspective. However, from an engineering or product management perspective, it's worth asking why you need a narrow scenario like this rather than either a more comprehensive feature or a scenario outline. And from a business perspective, low-level details in acceptance tests are generally an anti-pattern.

Express the Business Case

For example, rather than having all sorts of odd entry points as separate use cases, a more comprehensive feature might say:

Given that a user is not authenticated
When the user performs any action
Then the user is redirected to the login page.

This captures the real business case better and more clearly, although you would probably want individual steps or a scenario outline to test all the possible entry points and to be able to report individual failures more effectively.

The benefit of this type of story is that it captures the business logic a lot better than an implementation-centric story does. On the other hand, a failure within one of the steps is a lot less communicative, and requires knowledge of the underlying steps to narrow down specific failures.

There's a middle ground: senario outlines.

Use Scenario Outlines

The main problem with expressing only the business domain without also defining some context or targeted use cases is that you can't determine with specificity where a test group is failing. That's where Cucumber scenario outlines can help.

For example:

Scenario Outline: force authentication on all pages
  Given an unauthenticated user
  When the user connected to the <function> page
  Then the user should be redirected to the login page.

  Examples:
    | function |
    | meeting  |
    | calendar |
    | profile  |
    | launch thermonuclear warheads |

With this type of outline the business goal is clear, and you also have a set of high-level tests that can pass or fail independently of each other. The top-level reporting is both granular and cohesive, while avoiding the sort of "test sprawl" that you would get from adding negative scenarios for each behavior.

Summary

Testing is more of an art form than a science, so your mileage may vary. However, agile testing should function as self-documenting behavior rather than low-level detail, and acceptance criteria should focus more on business logic or user-visible behavior than on underlying implementation details.

Answer 3

TL;DR: Yes, you may keep it this way.

Long Answer

Depending on what you are using the scenarios or business rules for, there are several ways to write them down

First case: The scenario is used for acceptance criteria

Story

As a user, I want to create meetings, to...

Acceptance criteria

• Authenticated user may create meetings over a GUI / API
• Anonymous users should not be able to create meetings and get an error instead

First case: The scenario is used for acceptance / regression tests, which are fragmented instructions to click through the application. All these tests should pass after every story (or at least before every release).

Incomplete example:

happy path

1. open browser -> login screen appears
2. authenticate -> login successful message
3. create a meeting -> see meeting details

without authentication

1. open browser -> login screen appears
2. create a meeting -> see creation failed due to authentication error

Side note

I would recommend to do the regression tests through the GUI by a user. If they are written well, they can be implemented in code and run automatically.

Answer 4

As others have written, accounting for negative cases is good. However, the structure of your negative case is not, because it contains an internal contradiction.

The problem is that you are describing outcomes as if they were user actions. But they are actually the action the software takes in response to the user action. Failures have user actions, but the expected output never occurs, because the failure prevents it from actually happening, so a story predicated on the event is never satisfied.

Bad:

Given I am authenticated

When I create meeting X

Better:

Given I am authenticated

When I submit a "create meeting" request

This is still operating at the level of the backend, it doesn't refer to specific UI elements such as menus or buttons, and covers network activity not generated by the approved frontend (covering the "hack" concern).