Should you use the Given/When/Then format to specify automated acceptance tests?

This post is part of the Pride & Paradev series.

Should you use the Given/When/Then format to specify automated acceptance tests?

You should use given/when/then scenarios to specify automated acceptance tests

The Given/When/Then format provides a high level domain specific language to specify the intention of automated acceptance tests separate to the implementation of your automated acceptance tests. This separation allows changing the test implementation method (eg. moving from testing the UI to testing a service) without changing the intention of the test and how it is written.

There are tools in nearly every programming language that allow you to specify tests this way: for example, Cucumber, SpecFlow and JBehave all use this format, and this format has become quite ubiquitous in automating acceptance tests.

If the acceptance criteria on your user stories are specified in the Given/When/Then format then these are very easily transferred from a user story to an automated acceptance test.

You don’t need the Given/When/Then format to specify automated acceptance tests

Writing automated tests in the Given/When/Then format creates an overhead of maintaining a collection of step definitions so that the plain language specifications are machine executable.

One of the biggest selling points of writing automated acceptance tests in the Given/When/Then format is that they are readable by non-technical members of your business. But in reality, business will seldom, if never, read your Given/When/Then specifications, so it makes no sense to invest in the overhead required to implement these tests if they provide no extra communication benefit.

You are better off spending this effort on collaborating on non-executable story acceptance criteria that is fully understood between the business and your development team. These can be implemented however the team choose to do so without considering the need for business to access these.

Other domain specific frameworks such as RSpec allow readable automated test specifications without the overhead associated with implementing the Given/When/Then format, and these frameworks are often a better choice than a Given/When/Then based one when it is not needed.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

5 thoughts on “Should you use the Given/When/Then format to specify automated acceptance tests?”

  1. I have often called Gherkin Scripting (Given/When/Then scripts) the glue that can bring a team together. If you are practicing BDD/ATDD they are critical. It puts everyone on the same page of what needs to be done; they are the business way to telling everyone “this is what we want”, they tell the developers “this is what we should be building”, and they tell the testers “this is what we should be testing.” Once EVERYONE on the team (business included) has reviewed and approved, tasks can be created and the sprints can begin.


  2. I’ve been on the fence for a while in regards to G/W/T tests. I’ve been a few big .NET projects where I inherited a fully UI based acceptance test suite using Specflow and it left me with a pretty bad taste in my mouth and both times I did my best to tear the system apart because it turned into a fight between code reuse and readability.

    The best case I’ve made for Gherkin tests are in sharing language when describing features across all parts of teams (BA/QA/DEV/Bus). I’ve found success when clients have requested something demoable for a feature that had no UI component that we could show on showcase day.


  3. This is an interesting post. Wonder what the general QA, dev, paradev public opinion is on the topic. Would love to see more comments about it. I see validity in both points.

    If RSpec is a good tool that alleviates the overhead, then wish there were variants of RSpec but for other languages.


  4. I found the G/W/T syntax makes the steps logically organized and consistently styled. This feature helps different stakeholders to understand user stories/scenarios easily.
    More important, this makes the reuse of the step definition possible. I can easily create many more test cases by copy&pasting + minor modification. Other team members, the developers in my team, can quickly create integration test cases without spending much time in the low level step definition.
    Therefore, I would like to vote for using G/W/T for acceptance test cases.


Comments are closed.