What IS the difference between BDD and ATDD?

The difference

One of the common misconceptions around behaviour driven development is that it’s purely about automation. New adopters of BDD may dive into the tooling in the belief that BDD is all about creating a series of acceptance tests using the Gherkin syntax, and then automating them for regression testing purposes. Though, of course, this may depend on the source of their introduction to BDD in the first place.

However, this belief is misguided and has been the root of headaches for teams, who have ended up with:

• Slow, brittle automation

• Time-consuming maintenance of tests

• Substitution bias when interpreting the output of automated tests

All of this occurs, whilst the issue of incorrect delivery of requirements and the cost of rework caused by this are not addressed.

This mistake is common because BDD often gets confused with ATDD or acceptance test driven development. The confusion stems from definitions of BDD that use the terms BDD, ATDD and test-driven development interchangeably. New adopters read these definitions that fail to clearly define the purpose or value of BDD and fall into the trap of seeing it as an automation approach. It’s no wonder why many teams starting out in BDD fall into anti-patterns so quickly when the BDD approach has been misinterpreted from day one.

Clarifying BDD

So what is behaviour driven development? At its core, BDD is about having conversations to help teams overcome misinterpreted requirements and delivery issues. Have you ever worked on a project where the team has delivered a feature that didn’t match what the product owner wanted, and heard them say “that’s not what I wanted”? In a nutshell, the purpose of applying BDD methodology is to address that issue; it’s about promoting a shared understanding between team members as early as possible in a user stories lifecycle.

By encouraging conversations across disciplines (the various stakeholders in the project) we can ensure our agile development teams have a shared understanding of what is required, which helps the team to work towards a common goal. During these conversations, ideas and concepts are shared by discussing concrete, real-life examples of expected requirements and product behaviour, to make it explicit what needs to be delivered.

This is the essence of the BDD approach - having conversations. Everything else that follows the conversations is optional.

Once the collaborative sessions are flowing a team may choose to capture examples from those conversations using the Gherkin syntax, and then use the captured examples with automated tools to help guide what developers deliver, in what is known as outside in development. Outside in development can be an extremely useful technique for developers but sadly, this is where the confusion begins. As we begin to talk about automated tools and approaches the waters begin to muddy.

Outside in Development with ATDD

Outside in development can best be described with this model:

Outside in development combines the principles of test driven development and acceptance driven development into one approach.

It starts with a developer taking a Gherkin example and connecting it to failing automation code that is failing because it is attempting to interact with production code that doesn’t exist yet. With the failing example in place a developer could then write all the production code to make the test pass, and then refactor (whilst ensuring the test stays green). This is known as the "outer circle" of outside in development.

This activity is similar to the approach that acceptance test driven development advocates: Automate a series of failing acceptance tests (not examples) before creating production code to make them pass.

The differences between the ATDD approach and outside in development are:

• In outside in development the source of the ‘acceptance tests’ come from captured examples from a conversation and not recorded expectations from a single source such as a business analyst or developer.

• Rather than jump straight in and create production code, the developer will move into the inner circle and adopt a test driven development approach to create tests for each unit of the code production code required to make the outer circle go green.

The value of the outside in development approach is that the developer is guided towards delivering the right thing as their focus is to make the example pass.

The differences between ATDD and BDD

So to summarise, ATDD is a process in which high-level acceptance tests are automated to fail and then developed against to create enough production code to make the acceptance test pass.

BDD leverages this technique along with other techniques around conversations, collaboration and automation to ensure that a team delivers what the business wants this first time around.

Conversations over automation

Finally, when adopting BDD it’s important to focus on solving the problems of delivering the right thing and not on the automation techniques. ATDD is one technique to help developers deliver the right thing, but if what informed your acceptance tests or examples is based on assumptions and biases, then your developers are at risk of using a technique that is guiding them towards delivering the wrong thing. Shared understanding when creating the Gherkin examples is where the value comes from by having conversations and ensuring the team has a shared understanding of what is required.

So focus on the conversations first before the tooling: