Behavior-Driven Development

Dan North began talking about Behaviour-Driven Development (BDD) in 2006 to clear up misunderstandings about Test-Driven Development:

“Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.”

– Introducing BDD by Dan North

He realised that it was clearer if he told them to test behaviours rather than functions. More specifically:

  • Think of changes to the system as changes in behaviour. Deciding which test or series of tests to write next is easier if you think in terms of behaviours. What is the next most important behaviour? Write tests for that.

  • Name your test functions after the expected behaviour, even if this makes the test names sound almost like sentences. This makes it clear what is wrong if the test fails. It also makes it clear which aspects you should be checking in the test. If a test can fail for a reason that does not match the name of the test, it should be a different test.

  • Formulating or reformulating requirements as Given-When-Then (GWT) makes it easier to write tests.

Given-When-Then and Arrange-Act-Assert actually mean the same thing, but GWT fits better with the behaviour-oriented mindset. Furthermore, acceptance tests can be created very easily from requirements written as Given-When-Then.

BDD thus facilitates agile collaboration between development, quality assurance and the product owner on a software project. In Selling BDD to the Business, Dan North explores this process in more detail:

“BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

Gherkin

The structured acceptance criteria, which were written in plain language rather than code, were further formalised using the Gherkin description language so that they could be parsed automatically.

Scenario: Add a task to the database
  Given an empty database
   When a task with a summary is added
   Then the number of tasks should be 1
    and the queried task from the db should correspond to the added object.

Each scenario is intended to serve as an example illustrating a specific aspect of the application’s behaviour.

In Python, both behave and pytest-bdd can parse Gherkin.