Author: Luís Sousa


BDD (Behaviour Driven Development) is a technique of agile development that combines a few ideas from Domain Driven Design (DDD) with techniques and principles used on Test Driven Development (TDD), driving software development accordingly its behaviour, thus solving some of the constraints identified on the usage of this latter technique.

BDD arose from the need to fulfil some of the gaps detected when using TDD. These gaps result from the lack of experience of who uses TDD, causing that sometimes users don’t understand the actual potential of this technique. Frequently developers complain about not knowing what should or should not be tested, what name should be given to tests, to what extent tests should be applied or that the learning curve is somewhat long, let alone resistance shown by some developers who state that it is a complete waste of time to "code" tests when these could be implementing app features. The problem isn’t TDD itself but rather in the way people use this technique, focusing too much on tests and sometimes neglecting the wanted behaviour for the app.

The changed propose by BBD 

BDD helped to change the way that we can approach software development, highlighting behaviours that start to guide the app development instead of the tests. However, tests should not be considered unimportant. It is really useful to have automated tests that run every time a change is made in the app, making sure that the new features are well implemented and assuring also that the existing code has not been broken. BDD helps to remove the excessive focus that many TDD users wrongly give to testing, directing that same focus to the wanted/expected behaviour of the app.

For BDD a clear definition of the requirements is a key point. In order to get that, an ubiquitous language is used, present in DDD, which is understandable by all participants (developers, analysts, business users, and so on) that helps prioritising and validating the behaviours the app shall have. The language, oriented to the business, uses a very specific and form restricted vocabulary to minimise wrong interpretation and miscommunications among the several participants in software development.

Tests are made of two parts, basically: the definition of the feature to deploy and the case scenario (test cases) that will help to validate that feature. Thus, it becomes clear and understandable to all users the advantage that a new feature will bring to the system. The case scenarios (test cases) that go along with features are a critical part that allows validating the expected behaviour of the new feature. The very same way how features and case scenarios are written also allow that any participant understand what the issue is, making it easier to detect flaws/mistakes in the tests themselves. 

The relationship between BDD and Test Driven Development

BDD brought a strong contribution to TDD, changing the software development focus to the system behavioural aspects instead of tests, helping to direct developers to the actual value they can get from TDD, reducing learning time and allowing that new agile development teams work faster using these techniques.

Using an ubiquitous language, BDD can also shorten the gap dividing the several participants in software development process (developers, analysts, non-technical staff and business users, and so on), thus minimising some obstacles found before on the stages of specification, drawing, deployment and validation of a system behaviour.