Response to “BDD: TDD done right”

The author of BDD: TDD done right gives an excellent overview of Behaviour Driven Development and a clear motivation why BDD can be seen as the logical continuation and indeed the better way to do Test Driven Development.

Furthermore, the author gives an interesting topic for discussion, drawing a parallel between BDD and Expert Systems.

In this response I would like to extend the discussion and clarify certain aspects about BDD, as well as challenge the author’s claim that Behaviour Driven Development is, in its core, the same as Test Driven Development.

Benefits of using BDD

Behaviour Driven Design really comes into place when the traditional model of splitting development tasks into independent features is exchanged for the implementing of user stories. This model is particularly common in the field of mobile and web application development, where a developer takes ownership of a flow of business logic and implements that throughout the entire stack (by modifying database models, controller logic and views).

This approach makes good sense, since it encourages organic growth of the entire system (i.e. it is impossible to end up in a situation where the back-end API has expanded immensely, while none of its services are available via the front-end). Furthermore, by enforcing a complete user interaction as the smallest development chunk in a project, it is easier to prioritise feature requests and adjust milestones based on user feedback.

All of that ties together with the idea that BDD does not rely on specific tooling, it is rather a practice that could be adopted in legacy projects by altering the naming conventions of unit tests and the minimum requirements for a pull request. And while this flexibility can clearly improve the development workflow, there are some subtle difficulties that need be addressed before jumping on the BDD bandwagon.

Dangers of using BDD 

In his introduction to BDD, Dan North stated that the idea behind the practice was to address recurring issues in the Test Driven Development teaching. However, the successful implementation of BDD would require knowledge of a greater domain than TDD does. Thorough understanding of the business implications of a given feature, knowledge of the system architecture from front-end to back-end and the potential need to deal with numerous programming languages and interfacing components are just a few of the added overheads when development is driven by behaviour.

All of these make it difficult to recommend BDD to novice programmers that are not familiar with a wide range of TDD topics.

BDD viewed as an Expert System

Apart from being a development practice better suited for expert software developers, BDD may share some common characteristics with Expert Systems as discussed by the author of BDD: TDD done right.

While there are some fundamental differences between a Knowledge-based System (the overarching domain for Expert Systems) and a BDD framework, both encourage the principle of “Five Whys” when reasoning about a design solution or inspecting the output of a complex logical inference. The Five Whys technique is fundamental to BDD as described in the Agile Alliance Description, but furthermore it could be viewed as a pragmatic approach to nesting rules and reasoning about inferences in a Knowledge-based System of higher complexity.


Clearly BDD builds on the foundations of TDD and can be viewed as its logical extension in the correct project setting. However, BDD is rather a set of recommendations and good practices, than a solid approach complete with its tooling, that could be handed to a novice developer.