Test-Driven Development (TDD) tells us to write a test first, but it doesn’t tell us which test to start with. Behaviour-Driven Development (BDD) uses the user-facing functionality as the starting point - for example, a browser test in a web application. When a BDD test for a feature passes, we have high confidence that the user can accomplish the task in our system.

Outside-in

The user interface can be thought of as the “outer” layer of our application, the one closest to the user. Making this test pass drives us “in” through the layers of the app - frontend, API, database etc. - writing more tests for the changes needed in those components along the way. When the tests for all the layers pass, then the BDD test will pass too (assuming everything is wired together correctly.)

User Stories

Because they test from a user perspective, BDD tests can be translated from the requirements in user stories. If the Acceptance Criteria are written using the Gherkin syntax of “Given; When; Then”, they map directly to the “Arrange; Act; Assert” phases of an automated test.

Given: Arrange - set up system starting state

When: Act - perform action under test

Then: Assert - check results

Definition of Done

If the acceptance criteria of the user story we’re working on have been translated into BDD tests, and they are now passing, then we have finished implementing our story - and built up a regression test suite that can be used to support refactoring and adding new features going forward.