In a behaviour scenario, what do the Given, When and Then steps each describe?

juniormust knowfreq 80%

answer

One worked example of a rule
Three parts, three different jobs
Only the middle part is an event
The last part must be visible from outside
Continuation steps inherit the type above

basics

~20 s

Given states the context that already holds before the behaviour under test. When names the single event that triggers it. Then states the observable outcome that must follow. All three describe behaviour, not interface mechanics.

solid answer

~50 s

A scenario is one worked example of a rule, split into three jobs. Given establishes the world before the event — the data, the state, the actor's standing — written as facts, not as the actions someone performed to reach that state. When is the single event under test, in the active voice: one thing the actor or a scheduled job does. Then is the oracle: an outcome someone outside the system could observe and would care about, such as a stored order, a rejection with a reason, or a notification — not a widget on a screen. Steps beginning with And or But continue whichever type came before them. Written this way a scenario reads as a specification: a reader who has never seen the product can say whether the rule itself is right. Once a Given contains "clicks" or a Then names a button, it has quietly become an automation script.

A scenario is one worked example of a rule, split into three jobs. **Given** establishes the world before the event — the data, the state, the actor's standing — written as facts, not as the actions someone performed to reach that state. **When** is the single event under test, in the active voice: one thing the actor or a scheduled job does. **Then** is the oracle: an outcome someone outside the system could observe and would care about, such as a stored order, a rejection with a reason, or a notification — not a widget on a screen. Steps beginning with And or But continue whichever type came before them. Written this way a scenario reads as a specification: a reader who has never seen the product can say whether the rule itself is right. Once a Given contains "clicks" or a Then names a button, it has quietly become an automation script.

code

pseudocode · 6 lines

pseudocode

Scenario: Reordering a shared playlist reaches every collaborator
  Given a shared playlist "Late Shift" holds 14 tracks
  And two collaborators have editing rights on it
  When an editor moves the ninth track to first position
  Then the playlist order starts with that track for every collaborator
  And the change is attributed to the editor who made it

go deeper

for a junior

Be ready to say what each of the three parts holds and to spot a step in the wrong one. Practise rewriting a click-by-click scenario as context, one event and one outcome — that rewrite is the exercise interviewers actually set.

for a middle

An interviewer expects you to explain why the single-event rule exists and what a continuation step inherits. Show that you can split a conjunction step into separate facts and say what that buys when the scenario goes red.

for a senior

Demonstrate judgement about the oracle: which outcome is worth asserting, why a visible proxy can be green while the promised behaviour is broken, and how you decide that a fact in the Given is incidental and should be deleted.

for a principal

Own the standard. Be able to say what shape you require across many teams, how you keep scenarios reviewable by people outside engineering, and how you handle an existing corpus written as interface scripts without stopping delivery to rewrite it.

One example, three jobs

A scenario is not a test script. It is one concrete example of a rule, written so that someone who cannot read code can judge whether the rule itself is correct. The three step types divide that example into the three parts any example needs: the situation, the thing that happens, and what must be true afterwards.

Given — the context that already holds. Given steps are facts about the world at the moment before the event, phrased in the present or present-perfect: "a shared playlist named Late Shift holds 14 tracks", "the listener has editing rights on it". They are deliberately not the actions someone performed to arrive there. That distinction carries weight: the reader must be able to accept the context without auditing it. How the playlist came to hold 14 tracks is irrelevant to the rule under test, and narrating it buries the rule. Several Given steps are normal; each should be an independent fact the rule genuinely turns on, and anything the rule does not turn on should be deleted rather than kept "for realism".

When — the single event under test. The When is the one thing that happens, named in the active voice with its actor: "an editor moves the ninth track to first position". Everything before it is context; everything after it is consequence. This is why one When per scenario is the working rule. With two events in the When, a red scenario no longer tells you which event misbehaved, and the example has stopped being an example of a rule and become a narrated flow.

Then — the observable outcome. The Then is the oracle: the statement that decides whether the behaviour was wrong. Two properties make it a good one. It must be observable from outside the system — something a user, an integrating service or an auditor could see — and it must be the outcome the rule promises rather than a proxy for it. "The playlist order starts with that track for every collaborator" is an outcome. "The row is highlighted" is a proxy that can be true while the outcome is false. Screens are often where an outcome becomes visible, but the wording should still name the outcome, and the check should look where the effect actually lives.

And / But — continuations. A step opening with And takes on the type of the step above it: an And after a Given is another Given, an And after a Then is another assertion. But behaves identically and exists only so that a contrasting fact reads naturally in prose — "But the archived playlist is not affected". Continuations exist so a reader is not forced to reread the same keyword five times; they add no semantics.

Why the shape is worth enforcing

Four things fall out of it, and each one is a reason interviewers ask.

Failure attribution. One event and separately-stated facts mean a failure points at a single cause. A scenario with a conjunction step — "Given the playlist is shared and public and has 14 tracks" — fails as a lump, and you learn only that one of three facts could not be established.

Reviewability. The audience for a scenario includes people who will never open the automation. If the steps read as intent, they can confirm the rule; if they read as keystrokes, they can only confirm that someone described a click path.

Reuse. Facts stated as facts are reusable context; narrated setup is not.

One rule per scenario. The three-part shape makes an overloaded scenario visible. Two unrelated assertions in Then usually mean two rules, and they belong in two scenarios that can fail independently.

A worked example, and the same thing done badly

The good version names a rule about a shared playlist and asserts what collaborators end up with. The bad version opens a page, types into a search box, drags a row, and asserts that a toast appeared. Both may pass; only one survives a redesign, and only one tells a reader what the product promises.

Common wrong turns

Writing the Given as a login sequence is the most frequent, because authentication genuinely happens first — but the rule almost never turns on the act of signing in, only on who the actor is, which is a fact. Putting an assertion in the middle, before the When, is another: a mid-scenario check usually means the scenario is trying to cover two rules. And using Then to change state so a later check can run inverts the shape entirely — nothing after the When may alter the system.

A useful self-test before committing a scenario: read only the Then aloud. If it does not describe something a person outside the team would care about, the scenario is testing the interface rather than the behaviour.

### One example, three jobs A scenario is not a test script. It is one concrete example of a rule, written so that someone who cannot read code can judge whether the rule itself is correct. The three step types divide that example into the three parts any example needs: the situation, the thing that happens, and what must be true afterwards. **Given — the context that already holds.** Given steps are facts about the world at the moment before the event, phrased in the present or present-perfect: "a shared playlist named Late Shift holds 14 tracks", "the listener has editing rights on it". They are deliberately not the actions someone performed to arrive there. That distinction carries weight: the reader must be able to accept the context without auditing it. How the playlist came to hold 14 tracks is irrelevant to the rule under test, and narrating it buries the rule. Several Given steps are normal; each should be an independent fact the rule genuinely turns on, and anything the rule does not turn on should be deleted rather than kept "for realism". **When — the single event under test.** The When is the one thing that happens, named in the active voice with its actor: "an editor moves the ninth track to first position". Everything before it is context; everything after it is consequence. This is why one When per scenario is the working rule. With two events in the When, a red scenario no longer tells you which event misbehaved, and the example has stopped being an example of a rule and become a narrated flow. **Then — the observable outcome.** The Then is the oracle: the statement that decides whether the behaviour was wrong. Two properties make it a good one. It must be observable from outside the system — something a user, an integrating service or an auditor could see — and it must be the outcome the rule promises rather than a proxy for it. "The playlist order starts with that track for every collaborator" is an outcome. "The row is highlighted" is a proxy that can be true while the outcome is false. Screens are often where an outcome becomes visible, but the wording should still name the outcome, and the check should look where the effect actually lives. **And / But — continuations.** A step opening with And takes on the type of the step above it: an And after a Given is another Given, an And after a Then is another assertion. But behaves identically and exists only so that a contrasting fact reads naturally in prose — "But the archived playlist is not affected". Continuations exist so a reader is not forced to reread the same keyword five times; they add no semantics. ### Why the shape is worth enforcing Four things fall out of it, and each one is a reason interviewers ask. *Failure attribution.* One event and separately-stated facts mean a failure points at a single cause. A scenario with a conjunction step — "Given the playlist is shared and public and has 14 tracks" — fails as a lump, and you learn only that one of three facts could not be established. *Reviewability.* The audience for a scenario includes people who will never open the automation. If the steps read as intent, they can confirm the rule; if they read as keystrokes, they can only confirm that someone described a click path. *Reuse.* Facts stated as facts are reusable context; narrated setup is not. *One rule per scenario.* The three-part shape makes an overloaded scenario visible. Two unrelated assertions in Then usually mean two rules, and they belong in two scenarios that can fail independently. ### A worked example, and the same thing done badly The good version names a rule about a shared playlist and asserts what collaborators end up with. The bad version opens a page, types into a search box, drags a row, and asserts that a toast appeared. Both may pass; only one survives a redesign, and only one tells a reader what the product promises. ### Common wrong turns Writing the Given as a login sequence is the most frequent, because authentication genuinely happens first — but the rule almost never turns on the act of signing in, only on who the actor is, which is a fact. Putting an assertion in the middle, before the When, is another: a mid-scenario check usually means the scenario is trying to cover two rules. And using Then to change state so a later check can run inverts the shape entirely — nothing after the When may alter the system. A useful self-test before committing a scenario: read only the Then aloud. If it does not describe something a person outside the team would care about, the scenario is testing the interface rather than the behaviour.

Can a scenario legitimately have no Given at all?
Yes. When the rule holds from an empty starting state — a first-time listener who owns no playlists creating one — the absence of context is the context, and inventing a Given to fill the slot adds a fact the rule does not turn on. What you should not do is drop a Given that the rule silently depends on, because the scenario then passes or fails on whatever the environment happened to contain.
Where does the actor belong — in the Given or in the When?
Both, in different forms. Who the actor is, and what standing they have, is context: "a collaborator with editing rights". What the actor does is the event: "the collaborator removes the last track". If the actor's identity only appears inside the When, a reader cannot tell whether the rule is about that role or about anyone, which is exactly the ambiguity the Given exists to remove.
How concrete should the data in a Given be?
Concrete enough to be a real example, sparse enough that every value is load-bearing. Naming a playlist and giving it 14 tracks is useful when the rule turns on the position or the count; giving it a creation timestamp, a cover image and an owner's country when the rule ignores all three just gives future readers three things to wonder about and three things to maintain.

It reads like an incident report written before the incident: the situation on arrival, the one thing that happened, and what was true afterwards.

saying these in an interview costs you the question

Describes Given as the sign-in steps the user performs
Puts two or three events under When and calls it one flow
Asserts a button label or toast message in Then
Treats And and But as distinct step types
Uses Then to change state for a later check
Says the scenario must mirror the click path exactly

In a behaviour scenario, what do the Given, When and Then steps each describe?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

One example, three jobs

Why the shape is worth enforcing

A worked example, and the same thing done badly

Common wrong turns

▾common follow-ups3 questions

▾analogy~10 s

▾red flags6 flags

§ context

▾related questions6 questions

▾related topics3 topics

One example, three jobs

Why the shape is worth enforcing

A worked example, and the same thing done badly

Common wrong turns

answer

go deeper

context