How to write Given/When/Then Scenarios without Given and When being the same

Question

Given that I want to write a Given/When/Then scenario
When I write a Given/When/Then scenario
Then my Given and When are generally the same thing

I've been trying to practice writing user stories in Given/When/Then but I often end up with something like above; the Given and When are identical. I find that high level stories come natural but when I try to break them down into manageable tasks I end up with stories like the above.

Here's an example on a "reporting" system I'm working on where security issues can be reported and reviewed. At a high level, the stories are easy and make sense:

Given a Security Problem is dicovered
When the Issue is reported to SecurApp
Then an Item is created for review

At the system level, we'll take in a "request" which goes on a queue, gets picked up, and a report is generated

Given a request to create a report
When a report is created
Then the user is notified that the report is created

But now I've got this weird duplication between Given and When. This happens a lot.

What's a good way to think about Given/When/Then? Because I have a feeling I'm approaching this incorrectly. Or maybe, does Given often get repeated across similar stories?

Answer 1

What's a good way to think about Given/When/Then?

Given/When/Then is a friendly way of describing a Hoare triple.

{P}C{Q}

Where

• P is the precondition
• C is the command
• Q is the post condition

Another way of thinking about it is that we are describing a state machine; if we assume we are in state P, and then we follow transition C, we arrive in state Q.

// Given the clock reads noon
// When we advance the clock one hour
// Then the big hand is on the 12, and the little hand is on the 1.

It's somewhat common that "When" goes away; if the "command" is a NoOp, then you are left with P implies Q.

// Given the clock reads noon
// Then the big hand is on the 12, and the little hand is on the 12.

I think it's normal for Given-Then tests to show up in the early part of a test driven design exercise -- our solution has no business value if we cannot extract information out of it, so it is logical to start with queries from a known state, later adding the commands that take you from one state to another.

Answer 2

The Given stuff should detail state that drives the behavior one way or another — it is data/information, e.g. inventory levels, back order dates, recent orders, etc..  The initial conditions, not including the a newly occurring event/action.  The same Given state can be common for many scenarios.

The When part should be an event that initiates the requirement for the desired behavior — an action requiring a response (a customer makes an order, a return, etc..) — these require the system to make a change in business state.

And the Then is that desired behavior of your system in response to the event occurring in the context — the Given, the business conditions captured as state/information.

Old events (and their responses) qualify as state — they are information, not requests for change in state.  New events are requests for response, which likely requires change in state (somewhat internal to the business like updating inventory or more visible like shipping a product).

Answer 3

Each step in a scenario should be a grammatically correct sentence. Most grammatically correct sentences have a subject. The subject of the sentence is a noun. There is nothing wrong with repeating the noun across steps.

Given a request to create a report

When a report is created

Then the user is notified that the report is created

What you see as repetition really serves to reinforce the overall subject of the entire scenario: a report. There is nothing fundamentally right or wrong with this repetition. The most important aspect of a scenario is the behavior it communicates, not the terseness or uniqueness of each step.