Most organizations offering certification in frameworks tend to endorse learning ATDD after learning their frameworks. This is almost always a mistake that bogs down the adoption of Agile at the team. ATDD can be started in phases (see How to Start with ATDD using BDD).

The benefits of ATDD using BDD

BDD and ATDD share much in common and may even be considered mostly equivalent, only differing by nuance. Both specify behavior by involving technical and non-technical people, require effective collaboration, and use either Given/When/Then or a method that is equivalent to it.

BDD starts with requirements and produces the specification of a desired behavior.

ATDD takes the outcome of BDD and turns it into an executable specification (a “test”). This is true whether or not the ATDD execution process is automated.

ATDD makes BDD executable and therefore verifiable immediately and in the future as the system changes. When teams learn to do BDD properly, they can also do ATDD effectively without increasing effort. Thus, we always teach BDD and ATDD together to maximize the benefit for students.

Seven ways ATDD using BDD improves communication

Acceptance Test-Driven Development using Behavior-Driven Development helps improve clear requirements from the Business and seeing them realized across the value stream in seven interrelated ways.

Improved collaboration

Improving collaboration is a goal of Agile which is especially critical in working on requirements. ATDD using BDD encourages the collaboration of all parties involved. By having a direct conversation with people who are responsible for the specification and validation of the behavior, any misunderstandings are discovered and resolved quickly. While how to implement the requirement is not a factor in the discussion, having developers involved in the requirements provides them with insights

Clear acceptance criteria

Clarity requires discovering ambiguities which often lie in the area of “what you don’t know what you don’t know.” While there are no guarantees even with ATDD using BDD, the interactions between the different roles and the disciplined approach that ATDD using BDD provides goes a long way towards creating clarity.

Prepared for automated testing

While BDD does not require automation, it makes it easier by defining acceptance criteria in a form that can be easily automated. Once developers realize the time spent is on defining the tests and not automating them they are very often open to going all the way with automation.

Improved Developer / Tester communication

By getting developers and testers on the same page, it is usually possible for testers to begin writing tests at the same time the developers start writing their code.

Reduced time for feedback

BDD enables virtually no delay in feedback. By discussing acceptance criteria together with requirements, misunderstandings are often found immediately. This is critical for improving flow of value and reducing delays.

Agreement on requirements

Requirements are an ongoing discussion. ATDD using BDD provides the framework within which to have the conversation. Instead of a set document, the agreement is to discover what’s needed throughout the lifespan of the product.

Improved code quality

One of the most important design skills is “consider your tests before writing your code.” This consistent with the first mantra of Design Patterns : “Design to the behavior of your classes before considering how to implement them.” To learn more about this type of thinking, see the chapter Design Tests Up- Front in the online book, Essential Skills for the Agile Developer: A Guide to Better Programming and Design.