Acceptance Test Driven Development (ATDD) is a practice where teams drive their design and implementation using fine granular specification scenarios, which are called acceptance tests. These are specified in collaboration of all parties involved in the software development process or prior development of the feature (developer, tester, subject matter expert, etc.) .
ATDD follows a three step cycle: Red – Green – Refactor:
1. Red: When teams implement a new feature using ATDD, they start byautomating the new specification scenario, which should fail initially. The scenario is “red”.
2. Green: Once the system has been extended to fulfill the new requirement, the scenario will pass and become “green” (hence the name “Gherkin” – as cucumbers are green).
3. Refactor: Before the team moves on to implementing the next specification scenario, they improve the design of the existing code without further changing the system behavior. This refactoring step helps keep the system maintainable and is guarded by the existing automated acceptance tests (and additional unit tests).
Whenever a green scenario fails again, it turns red and informs the team that the system no longer fulfills the expected behavior. This happens when the team made a change that contradicts a previous requirement or caused unwanted side-effects. In any case, the team has to fix this mismatch to make all scenarios green again. Following that practice, Gherkin documentation grows with the system, providing an always up-to-date specification of its behavior. This is why automated Gherkin is also called “Living Documentation”.