Someone told me that out there, somewhere, are people who believe that “Given, When, Then” is the only way to analyse a story. I don’t believe it’s true. Sometimes there are more concise ways to get the same information. For example:

“Refunded or replaced items should always be returned to stock, unless they’re faulty.”

That’s four separate scenarios, encapsulated quite well in a very short sentence!

So why do we emphasise Given, When and Then in BDD?

Well, we can describe the behaviour in a different way. However, when we’d like to know when we’re done, we have to use a concrete example, whether it’s automated or manually driven. The only way to know whether the above sentence holds true for our system – whether the behaviour is correct – is to actually run through all four scenarios. Until they all work, we’re not done.

So, perhaps you, the business representative or analyst, don’t like using the language of contexts, events and outcomes. However, we devs use it all the time, as do QAs. However you get the information, and however you phrase it to us, the examples that you pass on to us define the scope of the story, the detail, and the end product.

An automated example sets up some contexts, causes some events to occur, and checks for certain outcomes (and perhaps then uses the result as the basis for more events and outcomes).

A manual test does this too.

With automation, particularly, it seems that contexts, events and outcomes are frequently reused to create different scenarios. Phrasing things in a way which makes them explicit can sometimes help us to reuse code in our scenarios, making the regression test suite cleaner and easier to maintain. This makes it easy to create new examples for behaviour we haven’t coded yet, which means we know more quickly when we’re done, which means you get your system delivered faster.

If we get the wrong Givens, Whens, or Thens, or we’ve missed a couple of contexts that might lead to different outcomes, then perhaps the system we produce might behave in ways that you didn’t intend, if at all.

You don’t have to be pedantic about the language – it’s OK to balance common sense with detailed explanations, and concentrate on the unexpected and on edge-cases – but if in doubt, you may find that using examples makes things a little clearer.

You may also want to read through our examples when we’re done. Just to check.