Test Driven Development (TDD)

Intermediate

difficulty

Stage 3

Agile IQ® Level

Backlog Items

Practices

Agile

Framework

Introduction

Agile software delivery encourages a focus on quality; working software is more important than comprehensive documentation. [1] One of the key changes in the past 20 years has been the approach to testing software. The basis of these techniques can be borrowed in other domains.

What is TDD?

TDD, or Test-Driven Development, refers to a style of programming in which three activities are tightly interwoven: coding, testing and design. [2] It can be succinctly described by the following set of rules:

Write a single (unit) test describing the aspect of the program
Run the test; it should fail because the program lacks that feature
Write “just enough” code so that the test passes
“Refactor” the code

This approach seeks to ensure quality by emphasising and requiring testing to drive the development process.

What is BDD?

BDD, or Behaviour-Driven Development is a synthesis and refinement of TDD and Acceptance Test Driven Development (ATDD). [3] BDD focuses on the expected behaviour to a change in a system.

The “Given, When, Then” notation is often used to document intended behaviour. It is a style of representing test cases specifying a system’s behaviour using examples for system specification. [4]

Example:
Given I have 100 shares of Microsoft stock
And the time is before the close of trading
When I ask to sell 20 shares of Microsoft
Then I should have 80 shares of Microsoft
And a sell order for 20 shares of Microsoft stock should have been executed

Benefits of Given, When, Then

Some of the benefits of using this approach:

Natural language is easier for a broader range of stakeholders to understand
Increases communication amongst team members
You define behaviours rather than tests
Provides visible results
Forces separation of pre-conditions and post-conditions
Tests focus on one scenario so troubleshooting is easier
Opportunities to automate code directly from BDD test definitions

When dealing with software development, many programming tools such as Cucumber and JBehave provide test features that accommodate tests defined in the Given-When-Then format. Though this is the case, the approach to testing business requirements is not limited to software products.

What to Watch Out For

Be careful not to write overly-complicated test statements. It may be better to split out into multiple tests or even split out the Backlog item by sections of TDD criteria.
Don’t start adding Given-When-Then format after teams start working on Product Backlog Items. The TDD should form part of the acceptance criteria of the Backlog item.

Actions to Try

Update your requirements template to capture requirements in the Given-When-Then format.
Add acceptance criteria in GIVEN/WHEN/THEN format.

References

1. Manifesto for Agile Software Development. https://agilemanifesto.org

2. TDD. https://www.agilealliance.org/glossary/tdd/

3. Behaviour Driven Development (BDD). https://www.agilealliance.org/glossary/bdd/

4. Fowler, M. (2013) Given When Then. https://martinfowler.com/bliki/GivenWhenThen.html

All fields are required.