Test Driven Development (TDD) and Behaviour Driven Development (BDD) are the most widely used technical practices in agile software development. These practices are not complete alternative to each other and the way these drive development is different. Depending on the development scenarios, either one of these or both might be useful. A clear understanding of the appropriate context of these practices will be useful for setting up the right development process.

To understand the fundamental differences between these practices let’s think of a user story with required acceptance criteria. The acceptance criteria for a user story are written with the customers that define the expected behaviours of the feature.

In TDD, when this 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 a number of 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 the tests are written 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, similar to TDD, a number of 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 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 that does the magic by converting the behaviour specifications into automation code. Obviously, 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. Similar to 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 improve the quality of a product 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 the customers understand.