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
- You don’t need given/when/then scenarios 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.