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.
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.
| 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.
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.