At the ACCU 2017 conference last week, Seb Rose presented a 90-minute Behaviour-Driven Development (BDD) workshop on Writing good BDD scenarios. This workshop was a great example of the excellent in-depth sessions from experts that I enjoyed attending at ACCU 2017. This blog summarises what I learned.
We started the workshop with two examples of feature scenarios, written in what we later learned to be a language called Gherkin. The first scenario described an end-to-end cash withdrawal:
Scenario: Dispense $50 cash in multiple denominations Given I have $100 in my account And I have a card with the PIN 5173 And I push my card into the machine And I enter 5173 for my PIN And I push the button next to Withdrawal And I push the button next to Checking When I push the button next to $50 Then a $20 bill should be ejected by the cash dispenser And a $20 bill should be ejected by the cash dispenser And a $10 bill should be ejected by the cash dispenser
The second version described the same scenario, but focused on the specific business rule about which denominations to use:
Scenario: Dispense $50 cash in multiple denominations When $50 is dispensed by the ATM Then the following bills should be received: | count | denomination | | 2 | $20 | | 1 | $10 |
For the first exercise, we discussed the pros and cons for each version of the scenario. Seb then cleverly tricked us into listing the benefits and disadvantages of each version, after which he explained why all of our observations about the long version were really disadvantages. For example, we liked how the scenario included pre-conditions such as having enough money in the account, and how it describes a complete user interaction. However, we learned that there are always more preconditions than you want to include, such as there being power to the ATM, so these are properly the subject of separate scenarios. Similarly, our observations about the short version all turned out to be advantages.
Our first lesson was that feature scenarios that focus on a single business rule are better than end-to-end scenarios. The latter include details that are best described in separate scenarios. What wasn’t yet clear was how a single feature description generally includes many independent scenarios.
The second lesson was that even such a simple scenario leads to a lively group conversation while we explored the scenario. This was even more clear when we attempted to discuss another example, based on borrowing books from a public library. It turns out that having a conversation about concrete examples is a key BDD technique.
The Three Amigos
In BDD, The Three Amigos refers to a conversation between a product owner, a developer and a tester about a feature. (Apparently, the name comes from the 1986 American film Three Amigos, which Seb assured us is terrible.) This conversation should explore concrete examples in order to distill feature scenarios like the Dispense $50 cash in multiple denominations scenario we had just looked at.
The benefit of this meeting, as we had just learned by actually doing, is that having this kind of conversation about a feature quickly unearths many different scenarios. Even in the workshop setting, we understood that this identified scenarios far more quickly than if a developer had just started coding.
The third lesson was therefore that a short up-front conversation that includes business, implementation and QA perspectives can quickly identify functional scope, and any likely problems or areas that the business do not yet fully understand. We also saw how you can write up the result of this discussion as scenarios using the Given-When-Then structure that we recognise from unit tests, which is equivalent to Arrange-Act-Assert. It turns out that this language is called Gherkin.
Gherkin is a simple language for describing features and test scenarios. The Given-When-Then encourages a structured approach to writing feature scenarios that all three amigos can understand.
Intriguingly, Gherkin’s grammar supports other spoken languages, so you can also write Given-When-Then as Angenommen-Wenn-Dann or Soit-Quand-Alors (or dozens of others). The key point is that this is business language, which leads to the more important insight that Gherkin is designed to elicit that holy grail of Domain-Driven Design: the ubiquitous language.
More broadly, Gherkin seems to be one of those ‘technologies’ whose low-tech simplicity hides its clever choices that make it so useful: in this case how it works for the business people.
Another workshop exercise had us write scenarios in Gherkin for the public library example. Writing Gherkin feature descriptions turns out to be harder than it might look, given the simplicity of the result. At this point, Seb’s Gherkin tips made a lot more sense:
As always, the thorny issue of naming appears, hence the first tip to use Friends episode (television series) naming: The one where the ATM dispenses cash or something.
Towards the end of the workshop, I was getting more curious about Cucumber, which it had become clear that we weren’t going to cover. As far as I can tell, Cucumber is a tool for executing Gherkin scenarios in the form of automated tests. It turns out that Seb co-wrote a book about Cucumber - The Cucumber for Java Book, so I guess I know what I have to do next.
One more thing: at one point, Seb told us that you can also use Gherkin to describe and test an API, rather than user-facing application functionality. That sounds like a big topic all by itself that deserves further investigation.