Test-Driven Development (TDD) aims to test small bits of code using the Red-Green-Refactor pattern. First, write a test that fails (Red), then write the most straightforward test that passes (Green), finally refactoring until the code is as clean as possible.
Behavior-Driven Development (BDD) inherits the spirit of TDD while using artifacts provided by project stakeholders, such as user stories. BDD uses plain-text scenarios to bridge the gap between technical teams and regular teams.
Using a tool like Cucumber, developers create tests that match these plain-text scenarios written in a simple domain language called Gherkin.
Scenario: [a scenario starting with "should"]
Given [some preconditions]
When [an action happens]
Then [a result]
Running Cucumber on these scenarios returns a red/green result for each step, and the Red-Green-Refactor framework continues.
BDD moves the thought process of TDD from “testing after the fact” to creating the behavior before writing the code.
Another benefit to BDD is developing a ubiquitous language shared by both the business and technical teams.
Finally, the BDD specification disconnects the “what” from the “how”. Describing the business need, not the implementation, gives the team confidence in the solution.
Sources: