Services Practices

Pattern: Behavior/Test Driven Development (BDD)

By Michael posted 03-07-2019 10:19

  

Intent

Look at the accepted product, passed test, etc. first, before thinking about the product descriptions, requirements or design.

Also Known as

  • Test-Driven Development (TDD)
  • Behavior-Driven Development (BDD)
  • Acceptance Test-Driven Development (ATDD)

Motivation

All these "-Driven Development" approaches have one thing in common: You first define what it means to be successful, before defining what it actually is what you want to build. TDD has worked really well in software development, where developers wrote first the test (which would initially fail), to then write the implementation that would make the test pass. A nice side effect was a better software architecture and cleaner interfaces.
Behavior-Driven Development is also applied in software development, where the ideas of TDD have been taken "one level up". ATDD is this approach taken all the way up, where you define with the stakeholders first what it means to have an acceptable result.

Applicability

Use the pattern when:

  • Your stakeholders have a hard time to describe what they want ("I know it when I see it")
  • You are developing an innovative product that you can't quite base on an existing product

Structure

A key element for successful BDD/ATDD is the triangular relationship between test, requirement and design. See V-Model (Relationship Model). Work typically starts with the test, which drives the creation or modification of the system description. There are various frameworks for this approach, some more, some less formal. 
A key aspect of this approach is that you need to test relatively frequently, This aligns well with agile concepts, where work typically takes place in sprints. Using ATDD directly with the stakeholders provides structure to the sprint review.

Consequences

The pattern has the following benefits and liabilities:

  • Benefits:
    • Supports agile product development
    • Enables innovation
  • Liabilities:
    • High burden on testing, if not automated

Implementation

Your team needs the right mindset for this approach, which can be challenging in an established organization. Tool support is needed, but the main thing is that the tooling provides a data model that enables the quick reaction to change (e.g. by managing suspect relationships).
There are specialized tools that keep the test burden manageable.

Related Patterns

0 comments
8 views