Behavior Driven Development (BDD) combines ideas and techniques from TDD with those of the domain-driven design approach. As such, it can be considered as an evolution of TDD.
The main focus of the BDD methodology is to improve the collaboration and communication between software developers, quality assurance teams, and analysts and business users. To do so, BDD pushes the idea of describing stories composed of scenarios, understood by all stakeholders.
Those stories and scenarios become the specifications of the system and can be written along with the tests and validated by them, as part of your code base. When you do so, then those scenarios and stories become executable specifications. By executing BDD tests, you effectively validate that your system complies with its specifications.
By applying the BDD approach and writing BDD test specifications, you actually create a close relationship between the specifications and implementation. This is very beneficial as the specifications then become an integral part of the application's code base, versioned with the rest of the code. This is much more powerful and maintainable than having long Word documents, stored somewhere, that your code is supposed to comply and stay in sync with. By having the specifications within the code base, both live side by side and evolve together instead of separately.
BDD tests help to focus on the system's behavior and expected outcomes rather than on implementation details.
BDD scenarios usually have the following structure:
- Given: Initial state
- When: Some event occurs
- Then: Expected outcome
Here's an example:
Story: Grant access to the system to a new user As a system administrator In order to grant access to the system to a new user I want to create a new user account Scenario 1: The username is not used yet Given that the chosen username that is not taken already And that the username is not too long When the account has been created Then I should be able to find it back in the list of users Scenario 2: The username is already taken Given that the chosen username is already in use When the account is being created Then I should get an error telling me that the username is already in use
BDD scenarios aim to be readable by everyone (not only software developers). To reach that goal, BDD tests use a domain-specific language (that is, the language and terms of the domain experts). This is a concept taken from Domain-Driven Design (DDD) (that is, the ubiquitous language idea). The goal is to limit the vocabulary in order to limit communication issues and to use that vocabulary at all levels, from specifications to code.
The domain-specific language is defined project per project and tools can be used to detect the usage of specific words or sentences in the BDD stories and scenarios. For example, Gherkin (https://docs.cucumber.io/gherkin/reference) is a specification that is used by the Cucumber library (https://cucumber.io) and that defines a set of keywords (for example, Feature, Example, Given, When, Then, And, and so on) that can be extended by project-specific keywords.