Test-Driven Specifications: BDD, TDD, ATDD

Key Points

This article provides an introduction to specification methods through testing, including BDD, TDD, and ATDD.

TESTING AS A SPECIFICATION TOOL, WHY?

In a traditional approach, the analysis of a need is handled by different actors (project owner, developer, tester, ergonomist, etc.) who work separately.

The Agile Testing approach and its tools propose to process analysis in a cooperative and progressive way and in a natural language that can be used by all.

Multidisciplinary, non-siloed, and involved teams will be able to improve the quality of tests thanks to tools and methods such as ATDD, BDD, TDD, etc.

The degree of divergence varies across a team, but probably exists on any large and complex project.

This divergence is exacerbated by modes of operation that promote an exchange of documents rather than actual communication and can lead to a loss of sight of end-user satisfaction.

Vocabulary

BDD: Behavioral-Driven Development

TDD: Test-Driven Development

ATDD: Acceptance Test-Driven Development

We propose to increase exchanges and promote communication between the key players of the product (we sometimes talk about the “
3 amigos :)”
):

A Business Analyst
A Dev
A Quality Analyst

HOW TO SPECIFY THROUGH TESTING

TESTING AS A COMMUNICATION TOOL

The test has the advantages of being accurate, unambiguous, deterministic, reproducible and directly actionable.
Specifying by testing is the same as specifying by example.
The design of test cases is no longer limited to a specific person, each member can submit new cases to the team.

SPECIFICATION THROUGH TESTING

Source: Specification by Example by Gojko Adzic

Deriving scope from goals

Aligning visions improves the definition of a solution that will meet user goals. The team works with users to determine the solution. Users focus on the value they expect from the output.

Specifying collaboratively

Collaborative specification allows us to leverage the knowledge and experience of the entire team. It also creates collective ownership of specifications, making everyone more engaged in the delivery process.

Specification with examples

Instead of waiting for specifications to be expressed accurately for the first time in a programming language during implementation, teams illustrate specifications using examples. This ensures that everyone involved has a shared understanding of what needs to be delivered, avoiding misinterpretations.

Executable specification

At the beginning of the feature implementation, the test based on this specification fails because it is not yet automated and the code is not yet produced. Once the test is implemented, the specification becomes executable.

Living documentation

All specifications for all implemented features are validated frequently, through an automated build process. This helps avoid functional regression issues while ensuring that specifications remain up-to-date.

A CLEAR SPECIFICATION IN THE FORM OF AN EXAMPLE

Natural language understandable by everyone
- Using DSL: GIVEN – WHEN – THEN
- Enables automation with tools (
  Cucumber
  )
Clear and unambiguous rules.
Focus on the functional and not the solution.
Lock-in functionality upstream.

Example of a User Story : As a private user, I want to activate my online account in order to access the services of the Cortex portal
Example of acceptance test:

THE ACCEPTANCE TEST-DRIVEN DEVELOPMENT (ATDD) APPROACH

ATDD, or Acceptance Test-Driven Development, works by writing acceptance tests before coding.

The examples are written before the start of the development (of the Sprint) and are part of the definition of the Done. They help to understand the need and ensure that developers meet the acceptance criteria.

Here’s how it works:

Team discussion : Developers, testers, and business leaders work together to define the acceptance criteria for features to be created.
Test writing : Acceptance tests are written in plain language for everyone. These tests serve as executable specifications.
Write the code: Developers create the code needed to pass acceptance tests.
Automatic test execution : Acceptance tests are automatically initiated whenever changes are made to the code. This ensures that the code always meets the acceptance criteria.
Reflection and continuous improvement : The team meets regularly to discuss test results, troubleshoot issues, and ensure acceptance criteria remain relevant.

In short, the ATDD encourages collaboration by ensuring a common understanding of needs. Acceptance testing is a living, automated specification, ensuring continuous validation of code against business expectations. This leads to higher quality development and a reduction in misunderstanding errors.