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.
