Acceptance test-driven development (ATDD) is awesome

Test-driven development (TDD) has been a pretty decent standard in software development for the past years. Writing solid unit tests is something every professional developer should do. (Nightly) builds execute these tests all in order to validate the quality of your code. But for those of you that know the testing pyramid from Mike Cohn, will also know there are more tests than unit tests.

This article will show you the first step into Acceptance test-driven development (ATDD) to test the UI-layer of the application you’re building. It might help you get your business requirements in focus to make sure that what you’re building is right.

This article is the first part about this subject and I’ll post the next updates in the upcoming weeks. If you want to hear me speak about this subject, feel free to join my "Turn specs into high quality apps"-presentation at TechDaysNL 2016.

Why ATDD?

When you’re building your own project, everything seems ok. You’re the one that has all the requirements of the application in your head and creating it means just building those specifications. Sadly, many times you’re building something that someone else needs. This means that you’ll need to get the requirements/specifications out of their head in order to make sure that what you’re building is the thing they really want. Miscommunication looms which might cause you to build something the user doesn’t want.

So, where TDD (unit testing) helps you to Build the thing Right (making sure the code you’ve written actually works), ATDD can help you to Build the right Thing (making sure what you’ve build is what is needed). But in order for everyone to get these specifications written down everybody (business and programmer) can understand, we’ll need a singular language that is so easy no misunderstanding can occur.

Gherkin, a Domain-Specific Language (DSL)

One of these languages that can help you with this, is Gherkin. As stated on their site, Gherkin [..] is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. It can be used as a great form of documentation.

Gherkin describes the Features of the application, all specified in different *.feature-files that contain several Scenarios. It’s awesome if the business (for example, the Product Owner) can write down these specifications and discuss them over with the development team to make sure everyone is on the same page.

Gherkin follows the test format from ATDD:

Given (setup): A specified state of a system
When (trigger): An action or event occurs
Then (verification): The state of the system has changed or an output has been produced

You’ll find these steps in the *.feature-file and will look something like this:


 Feature: User can check out books
 
   Scenario: User successfully checks out a book
     Given book that has not been checked out
       And user who is registered on the system
     When user checks out a book
     Then book is marked as checked out
 
   Scenario: A different situation
       ...

It’s just as simple as that! Even though you don’t know anything about books or a checkout system, I’m pretty sure you understand what this feature contains. All the specifications could be written in this way, making sure everybody is on the same page.

Examples

But to make these Features even more useful, we might want to add Examples in the mix. This has everything to do with Specification by example (SBE) that shows that Examples are a great with to communicate between people in order to understand what they want.

When writing a Gherkin file, these examples can be found in the Scenario Outline. You could write a separate Scenario for each example, but that would make these files cluttered with too much text. Simply place placeholders in the Scenario that’ll contain these examples, which might look something like this:


 Feature: User can check out books
 
   Scenario Outline: User successfully checks out a book
     Given there are <available> books available
     When the user checks out <checkout> books
     Then there are <left> books left

     Examples:
        | available | checkout | left |
        |     12    |     5    |  7   |
        |     20    |     5    |  15  |

These Examples can make it more clear for everyone how the system should work. Also, when in Operations, these Examples can help to check if the system still works as it is intended.

What’s next?

You might think that this is just a way to write down specifications, but don’t forget that this is so easy to minimise misunderstandings – everybody can read and understand these *.feature-files. Also, this gives us the opportunity to automate these steps in a later stage. If you still think these *.feature-files are somewhat hard to read, these are easily transformed to a even more human-readable document using Relish, Pickles or Augurk.

The upcoming articles will dive into the the test automation of these feature files and eventually how to place this into your (nightly) builds for full test automation. This will help you build and deploy your software even faster. Let me know what you think through Twitter!

Want to learn more about this subject? Feel free to join my "Turn specs into high quality apps"-presentation at TechDaysNL 2016. Hope to see you there!

Marcofolio.net