The products with good quality win! Any product’s quality strategy requires to adapt a framework that enables building quality-in. Building quality-in is assuring at every stage of building a product, continuous validation is performed against the needs/requirements of the user.
Acceptance Test Driven Development (ATDD) is about discovering the users’ needs collaboratively and writing requirements specifications to enable continuous, automatic product validation against them.
ATDD can be compared to a group of chefs preparing a special meal for guests
- Chefs come together to learn about the guests. Then together agree the menu including ingredients, process of cooking. (#discover).
- During the cooking process the executive chef goes around the kitchen checking how each dish is being prepared (#develop).
- The product is finally delivered to customer to receive feedback (#deliver).
Tools for ATDD
#Discover – Writing user requirements and specifications in executable test style
In requirements workshop one of the key output is the specifications. A popular and effective way of writing specifications is by way of examples. With examples the specifications are easy to understand, concise and allows everyone to speak the same language.
The examples can be written in one of the following syntax to enable there conversion into executable tests.
Tabular – write example as Input and Output
|Use case||Userid||Password||Confirm password||Message||Description|
|password and confirm password dont match||ag||check123||check124||User not created||Password and Confirm password dont match.|
|password not minimum 6 characters length||ag||ch123||ch123||User not created||Password should be at least 6 characters long.|
|password should have 1 upper case character||ag||check123||check123||User not created||Password should have at least 1 upper case character.|
|all valid||ag||Check123||Check123||User created||User:ag|
2. Gherkin – write example as Given-When-Then
|password and confirm password dont match||userid:agoel|
|user created||error:User not created|
description: Password and Confirm password dont match.
Select 1 or 2 depending on your use case. Generally when there is a complex workflow involved then Gherkin syntax is preferred.
#Develop – Convert requirements into executable tests
Converting your requirements specifications, written in one of the above syntax, into executable tests ensures all user requirements are continuously and automatically validated. Furthermore the tests become living documentation of the software and it’s features.
The correct practice is to write a failing executable test, write your software code to make the executable test pass.
There are several open source tools available which help convert specifications in form of examples into executable tests. Below is an example of one such tool.
- An open source framework to write automated tests.
- Has several supporting keyword libraries for standard operations.
- Allows to write tests in natural language hence enables ease of collaboration between development and product management. And tests become living documentation of the software and its features.
#Deliver – Continuously validate
The executable tests that are developed should be executed against every build of your software in Continuous Integration. It ensures on every code change, tests are executed to ensure software is meeting the requirements and corresponding specifications.
There are several open source tools like Jenkins using which one can setup a Continuous Integration environment. The tools generally support a build to deliver pipeline like depicted below.
For more such exciting content and allowing us to be part of your career journey