Learning Objectives
By the end of this lesson you will be able to:
- Explain why a scenario over roughly ten lines is a smell, not just a style preference
- Split an overly long scenario into multiple focused scenarios
- Recognize scenario mixing — a second case glued onto a positive scenario with
But
Why Ten Lines Is the Line
There's nothing magical about the number ten. It's a practical trigger: once a scenario grows past that length, it is almost always because it stopped testing one thing. Extra Givens pile up to set up a second condition. Extra Whens creep in to trigger a second action. Extra Thens appear to check a second, unrelated outcome. The scenario is still "about" the feature, but it's no longer about one business rule.
This matters because of the discipline you already learned in the beginner course: one scenario, one business check. Scenario length is simply the visible symptom of that rule being broken.
What Goes Wrong When Scenarios Grow
A long scenario is harder to review — a business analyst skimming a ten-plus-line block will miss which parts matter. It's harder to maintain — a single UI or business rule change now requires editing a wall of text instead of one focused block. And when it fails, the failure tells you that something in this bundle of behavior broke, but not cleanly which business rule did.
The Split
Take an overly long scenario testing checkout with a discount code:
Scenario: Checkout with discount
Given a cart containing one item priced at $50
And a discount code "SAVE10" that is currently active
And the user is logged in with a valid session
When the user applies the discount code
And the user proceeds to payment
And the user enters valid payment details
And the user confirms the order
Then the order total reflects the 10% discount
And a confirmation email is sent
And the discount code is marked as used
And the loyalty points balance increases by 5
Eleven lines, and at least three business rules are bundled together: discount application, order confirmation, and loyalty points accrual. Split it:
Scenario: Discount code reduces the order total
Given a cart containing one item priced at $50
And a discount code "SAVE10" that is currently active
When the user applies the discount code and confirms the order
Then the order total reflects the 10% discount
Scenario: Confirmed order sends a confirmation email
Given a cart ready for checkout
When the user confirms the order
Then a confirmation email is sent
Scenario: Confirmed order accrues loyalty points
Given a cart ready for checkout
When the user confirms the order
Then the loyalty points balance increases by 5
Each scenario is now short, and each failure tells you exactly which business rule broke.
Scenario Mixing: The Sneaky Cousin
A related smell doesn't grow a scenario line by line — it welds a second, unrelated scenario onto the end of a first one using But:
Scenario: Login
Given a registered user with a valid password
When the user logs in with correct credentials
Then the user sees their dashboard
But an expired account is rejected with an error message
That last line isn't extending the first scenario — it's an entirely separate case (an expired account) smuggled in as an afterthought. It needs its own Given (an expired account), its own When, and its own Then. Split it into two real scenarios and the mixing disappears along with the confusion.
Pro Tip: If you can't summarize a scenario's purpose in a single sentence without using the word "and" to join two unrelated ideas, it's probably testing more than one thing.
Key Takeaways
- A scenario over roughly ten lines is almost always testing more than one business rule at once
- Split it by business rule: each resulting scenario should still follow "one scenario, one check"
- Scenario mixing glues a second, often negative case onto a positive one with a trailing
But— split it into its own scenario with its own full Given/When/Then