Can BDD be combined with ATDD?

Despite both practices have been around for years now, there’s still a lot of confusion out there about Behavior Driven Development (BDD) and Acceptance Test Driven Development (ATDD).

They are distinctly different practices, each with its own different goals, yet many people see them as one and the same. Mostly, this is caused by the flawed perspective on BDD where people think that practicing BDD is all about the tools (SpecFlow or Cucumber, for example). However, BDD is much more than that.

Generally speaking, ATDD is all about driving the implementation of the software through acceptance tests that are created upfront, and is therefore a practice related mainly to the implementation phase of the software development lifecycle. BDD, on the other hand, is all about avoiding the risk of communication problems by creating a shared understanding *before* the implementation starts, and therefore spans a much larger part of the SDLC. In other words, ATDD can be applied only to a part of the entire BDD process, more specifically to the Automation phase of BDD.

Now that this confusion between ATDD and BDD is hopefully cleared up, I’d like to spend the remainder of this article exploring ways in which you can practice ATDD as part of the BDD process, and how tools like SpecFlow can help you do just that.

ATDD is very similar to Test Driven Development (TDD), in that it drives software design and implementation by creating the tests that express the desired behavior of the component or feature that is to be built before writing the actual production code. This is typically performed by repeating the red-green-refactor cycle until all requirements are met:

  • Red – write a failing test that expresses the smallest possible and sensible part of the desired behavior that has not yet been implemented
  • Green – write just enough production code to make the test from the previous step pass
  • Refactor – improve code structure for both application and test code, so that the next cycle builds on a solid foundation

The biggest difference between ATDD and TDD is the scope of the tests and as a result, of the length of a typical red-green-refactor iteration. TDD uses unit tests in the ‘red’ step and implements a very small part of the system behavior in the ‘green’ step, leading to iteration durations that can be as small as 1-2 minutes, or even smaller for experienced TDD practitioners. ATDD uses acceptance tests, and as a result, typically requires more production code to implement the desired behavior, which leads to longer iterations. Still, with ATDD, too, the shorter the iterations, the better.

But how can we tie practicing BDD and using SpecFlow into this? Well, that’s pretty straightforward: the scenarios that are the result of the Formulation phase of BDD are (input for) our acceptance tests. They express the desired behaviour for a feature or component that is yet to be built. To use these to practice ‘true’ ATDD, all we need to do is tie these scenarios to (existing or newly built) acceptance test code using SpecFlow and any libraries that are required to interact with our application under test (for example Selenium WebDriver for web UIs, Appium for mobile UIs or RestSharp for RESTful APIs) and we’re good to go on our ATDD journey:

  • Red – write or pick a new Gherkin scenario that expresses the smallest possible part of the desired behaviour that has not yet been implemented, and tie it to acceptance test code
  • Green – write just enough production code to make the scenario from the previous step pass
  • Refactor – improve code structure for both application and test code, so that the next cycle builds on a solid foundation

As you can see, this is very close to the description of ‘pure’ ATDD that we saw earlier in this article.

So, to summarize, while BDD is much broader than ATDD, and while the two are not interchangeable, they can definitely strengthen one another and shorten the feedback loop even within the development of a single feature or component.