How TDD and BDD complement each other?

Test Driven Development (TDD) and Behaviour Driven Development (BDD) are the most widely used technical practices in agile software development. These two automated testing approaches are not alternative to each other but complement each other by addressing software quality from a different angle.

To understand the unique strengths of these two practices, let’s think of the journey a user story that is ready for development and has the required acceptance criteria. The acceptance criteria of a story tells about the expected behaviours from customers’ perspective.

In TDD, when a story is picked up for development, tests are written at first before writing the actual code, which obviously fail, then some code is written to pass those tests, then more tests/cases are added and finally the code is refactored. This fail-pass-refactor cycle is continued until all possible scenarios for the corresponding story are implemented and the desired technical standards are met.  The end-result of a done story is associated with several passing tests in the CI/nightly build suit. These tests may directly or indirectly relate to the acceptance criteria, however, not understandable by the customers. In general, if tests are written only at unit level, the context and number of these tests don’t match the acceptance criteria.  With TDD, it may happen that a completed user story with passing tests may fail to meet the acceptance criteria due to misinterpretation by the development team.  Even if there is no misinterpretation, it’s hard to capture and automate the acceptance criteria in TDD. And this is where BDD emerges.

In BDD, like TDD, several automated tests are written. However, in BDD, these tests map directly to the acceptance criteria defined in the user story. The essential idea of BDD is to avoid the trap that TDD can fall into upfront by following acceptance test-driven development (ATDD).  Technically, three essential pieces work together in BDD. First, the business behaviour specifications or the acceptance criteria are written in an easy-to-understand form that customers can understand by following a set of rules in terms of features, scenarios, and steps. The second part is technical which does the magic by converting the behaviour specifications into automation code. This part is written using a programming language and uses various automation libraries (e.g., browser automation etc.). And the last and third part is the application code. Like TDD, actual code is written after the initial failing tests when the application code doesn’t exist. Eventually, when the story is done, the acceptance criteria are already passing.

In summary, TDD and BDD are not alternatives to each other. Both plays key roles in delivering high quality feature by addressing quality from different perspectives. TDD helps in building the thing right in terms of simple design and correctness of logic at unit level. On the other hand, BDD helps in building the right thing by conforming to the acceptance criteria that customers understand.