Three Agile Testing Methods – TDD, ATDD and BDD

In the word of agile, there are three common testing techniques that can be used to improve our testing practices and to assist with enabling automated testing.

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

TDD, ATDD and BDD are software development techniques that can be used in any methodology, although aspects of all three are often part of a team’s agile testing approach.

Test Driven Development (TDD)

TDD ensures that the product, system or process is being built correctly. It tests independent small units or objects to make sure each works as intended.

TDD is a software development approach where a developer writes a test before writing any code. The test is then used to create and refactor code unto the code passes the tests. Once the code passes the test, it can then be refactored to an acceptable standard (i.e. code layout, notation, performance)

TDD focus is “does the code do what it is required to do?”

Acceptance Test Driven Development (ATDD)

Acceptance Test Driven Development is also referred to as Story Test Driven Development (STDD)

ATDD ensures the product, system or process being built meets the expectation set by the Product Owner and meet the needs of the end users and relevant stakeholders. It’s a mechanism to facilitate the conversation between developers and product owners about the requirements and validate the expected business value is met.

It is a collaborative practice where users, product owner and developers define acceptance criteria. ATDD helps to ensure that all team members understand precisely what needs to be done and implemented. In Scrum these tests are the Acceptance Criteria for each User Story.

ATDD focus is “does the solution do what it is required to do”?

Behavior Driven Development (BDD)

BDD is often referred to as Specification by Example

BDD ensures the correct product, system or process is being built by writing specifications or examples that describe the behavior expected.

BDD tests are written in an english-like language. Topic experts use their native language in combination with the language of Domain Driven Design to describe the purpose and benefit of the code.

A team using BDD should be able to provide a significant portion of “functional documentation” in the form of executable scenarios or examples. BDD is usually done in very English-like language helps the topic experts to understand the implementation rather than exposing the code level tests. It’s usually defined in the format of: GIVEN WHEN AND THEN.

BDD focus is “do the features and the data behave like they are required to do”?

Keep making data simply magical