Great work!

XP to next level

BugEater

Then — The Expected Outcome

Learning Objectives

By the end of this lesson you will be able to:

  • Explain what a Then step must contain to be verifiable
  • Distinguish an observable outcome from an internal implementation detail
  • Identify a Then step that's secretly performing another action

Then Verifies, It Doesn't Act or Set Up

Then describes what should be observably true after the When action happens. It's the payoff of the scenario — the thing a QA tester, an automated check, or a business reviewer confirms actually occurred.

Then the cart total reflects a 10% discount
Then the system shows an "expired code" error
Then the user's session is invalidated

Each of these can be checked: read the total, read the error message, check the session state. That checkability is the whole point of Then — a step nobody can verify isn't a real assertion.

Observable, Not Internal

A good Then describes something visible to the user or externally verifiable — not an internal implementation detail the business or a manual tester has no way to check:

# Too internal — a manual tester can't easily verify this
Then the DiscountService.apply() method returns true

# Correct — an observable, checkable outcome
Then the cart total reflects a 10% discount

If verifying your Then requires reading source code or a database row directly rather than observing system behavior, the step is written at the wrong altitude.

The Trap: Sneaking Another Action Into Then

Just as Given sometimes hides an action, Then sometimes hides one too — usually a second action performed to "check" something:

# Wrong — clicking is an action, this belongs in When, not Then
Then the user clicks "View Receipt" and sees the discount applied

The correct fix either makes viewing the receipt its own scenario, or rephrases the assertion to check state directly without an extra click:

Then the order confirmation page shows the discount applied

Multiple Then Steps Are Fine

Unlike When, having multiple Then steps is completely normal — a single trigger can produce several observable outcomes:

When the user applies the discount code "SAVE10"
Then the cart total reflects a 10% discount
And the discount code field shows a confirmation checkmark

Pro Tip: Read your Then step out loud and ask "could I check this by just looking at the screen or the response, without clicking anything else?" If the answer is no, rewrite it.

Key Takeaways

  • Then describes a verifiable, observable outcome after the When action
  • Assertions should stay at the level of visible behavior, not internal implementation details
  • A Then step that performs another action (like clicking) is a smell — it belongs in When or a separate scenario
  • Multiple Then steps are normal; multiple When steps are not

Quiz

What must a Then step be, above all else?

Why is "Then the DiscountService.apply() method returns true" a poorly written Then step?

What is wrong with "Then the user clicks 'View Receipt' and sees the discount applied"?

Is it acceptable for a scenario to have multiple Then steps?