In late 2010 I heard from my colleague Stefan Roock who organized some Story Test Workshops, or – rather – Story Test Dojos. At one client, he asked to write collaboratively story tests using the Given/When/Then schema from the behavior-driven development. However, he experienced one fallacy there, which one of the Product Owner fell into.
Though, the technique was introduced in English – or maybe just because of that – there was a confusion about the meaning of the “When” part of the format. Now, when translating “When” to German, there are two possible meanings – the resulting word is “wenn” in either case. One meaning is the right one, the temporal “wenn”, as in “when I press the button”. The other possible translation is a causal if, like in “if I press the button”.
Now, what confused the story tests was the occurrence of the causal meaning of the “when” part. “Given a user interface, when I press the button, then something happens” now gets two different meanings – depending on how I translate and interpret it. While there is one translation which is in the sense of the inventors, there is yet another, which adds complexity.
The causal meaning adds complexity to the interpretation of the test. If I interpret it the “When” part as a causal meaning, I get a condition into my tests. The flow through the story test gets split up into two branches. One where the condition in the causal “When” part is met, and one where it isn’t. Besides the fact that no reasonable Agile-friendly tool interprets the “When” part in this manner, the resulting tests get confusing, since they basically have to evaluate two branches.
Now, I challenged this fallacy over twitter, and Olaf Lewitz fired up some possible alternatives to “When” or “Wenn” in German. One alternative was to use “anlässlich”, which reveals the purpose of the following step. The problem I have with “anlässlich” is, that it gets confusing, since it’s such an unsually used word, and might further deepen the confusion around the term. Another proposed alternative was to use “sobald”, which could be a good one, but is also rather unusually used.
This week I had the opportunity to visit this particular client. While conducting a story test dojo on my own, the confused product owner was not present, unfortunately. Yet, I tried to bring in the alternatives as Setup-Execute-Verify from the xUnit Test Patterns book, as well as the Build-Operate-Check from the FitNesse UserGuide. These alternatives helped to understand the active part of the second phase.
However, what can we learn from this? An approach aimed at getting ambiguities out of the user stories might contain ambiguous elements in itself. Maybe this just happens for one out of hundred Germans who cross this approach, still it might happen. There is one way to overcome this with training, and mentoring. Just like we overcome the ambiguities in user stories, by collaboration and communication, we overcome the same short-comings in the same way by using education, communication and collaboration.
Or don’t use Given/When/Then at all. You don’t need it. Write the example as if you were explaining it to someone on the back of an envelope. You wouldn’t use such a formal structure as Given/When/Then if you were just talking and jotting down an example. Given/When/Then is clumsy and unnatural in English, let alone in German. The specifications are much more pleasant to work with when they’re written for humans rather than computers. With the right tool you don’t have to compromise.
More:
http://blog.davidpeterson.co.uk/2010/09/refactoring-givenwhenthen.html
http://blog.davidpeterson.co.uk/2011/01/bdd-concrete-examples-arent-enough.html
http://www.concordion.org
Oh, in the particular context this even makes sense. They use Concordion for their test automation, but have problems to focus them. I started to led away from the structure in order to gain the insight that there are more ways to describe this. Thanks for the pointers. I will use them and pass them on.
I agree, maybe Given/When/Then is not very natural in English. However, for me there is a great value in using it anyway.
First of all, Given/When/Then starts to become a mantra. For me it becomes natural to describe stories/requirements using this mantra. It helps to give a good structure of the requirements and imposes the question like ‘what is required as input?’ (->Given), ‘what is the action under test?’ (->When). This also helps to clarify which stuff is mocked and where to use the real production code.
Furthermore, in the context of one team it can help to build a common language, pattern and structure how to express the requirements. Especially for several teams working together. the existence of a common language helps a lot to reduce misunderstandings.
The common language to express your examples is crucial. As Gojko said at his workshop in London, specifying the scope through examples is crucial for the whole team to understand the new feature at hand. A common language helps, but – of course – everyone on the team has to have a common view on this.
Thus far, I have just seen this getting confused once. Maybe this is a no-brainer for some people, but maybe there is something lurking. I found the story interesting in this light.
In the 2nd paragraph you mentioned two times “Then” where it should be “When”, since the meaning of “When” is “Wenn”.
But you’re right, it is a little confusing at first sight.
Einfach “Wenn” im Sinne von “Wann” sagen. :)
Hi Greg,
thanks for spotting the typos and your comment. I corrected the mistakes.
Thanks for the article. I will be doing an ATDD workshop in Germany next week, so this is timely.
An alternative to Given / When / Then is
Setup / Trigger / Expected
Hi Markus,
it is very interesting how these schematic phrases can cause irritation if translated to other languages!
Regarding your translation issue, what do you think of using “nachdem”?
Cheers,
Nicole