Acceptance Test Driven Development – ATDD

Acceptance Test Driven Development, ATDD agile development, Acceptance Test Driven Development test format, three amigos, ATDD cycle

Acceptance Test Driven Development – ATDD – is a development method based on communication between the customer, developer and tester to ensure that the requirements are well-defined before implementation. ATDD encompasses acceptance testing, but highlights writing acceptance criteria and acceptance tests in collaboration with the stakeholders, before developers begin coding.

The three amigos in ATDD

The collaborative discussions that occur to generate the acceptance tests are often referred to as “the three amigos”, representing the three perspectives:

  • customer – what problem are we trying to solve?
  • development – how might we solve this problem?
  • testing – what about that scenario?

Acceptance Test Driven Development tests

Acceptance tests are written from the user’s point of view, focusing on the effects visible externally and created after analyzing the requirements and before building the code. Failing acceptance tests provide quick feedback when the related requirements are not being met. These acceptance tests act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended.

ATDD solves the problem of the development team implementing features that don’t solve the customer’s needs. An essential component of ATDD is automation, therefore the specifications created from the discussions are turned into executable tests that ensure software engineers implement the features according to the requirements.

Acceptance test format

  • Given – setup – specific state of a system
  • When – trigger – an action or event occurs
  • Then – verification – the state of the system has changed or an output was produced

Acceptance Test-Driven Development cycle

  • Discuss – developers discuss with the stakeholders and Product Owner at planning, clarify misunderstandings in the requirements and extract as much information as possible from them to end up with acceptance tests in the form of plain English phrases that can be understood by everyone
  • Distill – convert the tests produced in the previous step to a format compatible with the acceptance testing tool used, like tables, wiki pages or even code in a domain-specific language
  • Develop – wire up distilled acceptance tests to actual test code that will exercise application code, then the tests will fail since the features they’re testing do not yet exist and only then the developers implement the feature according to the specifications gathered in the “discuss” phase and that were converted into tests in the “distill” phase
  • Demo – demo the newly implemented feature to stakeholders in a meeting at the end of each cycle in which the team discusses the product and how to improve the process itself, potentially perform some manual exploratory testing that can find defects and room for improvements which can then be turned into further stories

Agile development practices