Given-When-Then is a way to represent behaviors or ‘features’ of a system. Also, know as Gherkin it is heavily used in Behavior-Driven-Development or BDD as well as Test-Driven-Development TDD.
Here is a quick definition of each part of the style.
- Given – This describes the state of the system before any action is taking. In other frameworks, this is knowns as the arrange in (AAA) or the setup in most unit testing frameworks.
- When – This is the action that is taken or what behavior is performed. This is also known as the act or exercise.
- Then – This is the expected state of the system after the behavior has occurred. This is also known as assert or verify.
Example:
Feature: User Access
Scenario: Deny user access to certain books
Given I have a set of books
And there are books that are restricted
When a user tries to read a restricted book
Then the user is denied access to that bookIf you want to dive deep into the different ways you can write this pattern this is a good reference article that goes deep into the different syntax that can be used. Guide
I have been looking into the value of using this pattern when writing acceptance criteria as well as when writing both unit and functional tests. I have come across a few key takeaways that could be useful to you.
One – When you start down this path make sure you fully understand the difference between imperative and declarative styles of writing the Given-When-Then cases. When the scenarios drift into the imperative style it gets hard to understand what is changing to the system for each scenario and what needs to be coded or tested. I would say you should always learn hard into the declarative style.
Check Out these links for more information
Two – I have learned that for this to work as well as the advocates of this style would like you to think you have to have buy-in from top-down for this style. The product owner has to be writing the acceptance criteria in this style. The developers have to be writing their unit tests following this pattern and QA needs to be writing their test case in this style. If any part of the chain is not using this style it gets hard to work as a team and the pattern makes things more difficult than easier.
Three – This style shines the brightest when using it with automated tools. Given-When-Then gives you a nice wrapper around creating a testing harness that can be reused and automated for building out your testing suite. A good example is if you have a process to login into your application. It is likely that you would want an authenticated user for most of the tests. So with a given statement like this:
Given an authenticated userYou could code in an automated tool how to do this once and use it in every test. This provides good reusability and also speeds up the time of building out good tests.
Check Out These Automated Tools:
Four – Given-When-Then gives the ability for everyone to talk in the same language. One of the hardest things in building good software is getting everyone on the same page. Given-When-Then allows you to speak the same language when talking about the behaviors of your system. This is commonly called developing a domain-specific language and Given-When-Then forces a team into this pattern.
Domain-Specific Language (DSL)
In the end, I found that there is value in using Given-When-Then language in building good software. It should be considered for your team or organization if some of the benefits out way the downfalls. I do think though that a lot of the benefits of using this approach are a wash if you are disciplined in writing good acceptance criteria, have a good development process and are following good development practices and patterns when writing your code.
What do you think? Am I right? Leave a comment below.
