Liz Keogh's blog

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.

A mother was cooking a joint of meat for her family. She cut off a large slice from the side of the joint, then put both pieces into the gravy.

“Why are you doing that?” her daughter asked.

“It helps it cook properly. That’s the way my mother always did it,” the mother replied.

“Why does it help?”

“I don’t know. Maybe I’ll ask your grandmother next time I phone her.”

So the mother phoned the grandmother. “Why do you always cut a slice of meat from the side when you cook the joint?” she asked.

“It helps it cook properly,” said the grandmother.

“But why?”

“I don’t know. It’s just the way my mother taught me to do it. Maybe we should ask her why!”

So the family went to see the elderly great-grandmother. “Why do we always cut a piece of meat from the side of the joint, before we put it in the sauce?” the mother asked.

“You still do that?” the old lady laughed. “I love you, and love that you trust in what I do, but you should find your own way to cook. I did it because it was the only way it would fit in my pot!”

(My father told me this story when I was a child; apparently it appears in “Surely you’re joking, Mr Feynman” by Richard Feynman.)