TEST DESIGNQuick Guide to Test-Driven Development (TDD) vs. BDD vs. ATDD

Avatar Guest ContributorMay 31, 20189 min

Demystifying Industry Buzzwords: Test-Driven Development (TDD) vs. BDD vs. ATDD

Test-Driven Development (TDD) is just one of many buzzwords in the industry right now. And so it’s understandable that people can get confused.

  • Test-Driven Development (TDD)
  • Behavior-Driven Development (BDD)
  • Acceptance Test–Driven Development (ATDD)
  • DevOps
  • DevSecOps
  • Continuous Testing
  • Model-Based Testing (MBT)

The list goes on.

However, make no mistake. These practices and methodologies seek to answer a straightforward question. How can we develop “better” software?

In this blog post, I will clear any confusion about Test-Driven Development (TDD), Behavior Driven-Development (BDD), and Acceptance Test-Driven Development (ATDD). What are they? How do they work? Moreover, what are their effects on the development/testing process?

Test-Driven Development: “Is the code correct?”

Test-Driven Development (TDD) focuses on the “inside-out” perspective, meaning we create tests from a developer’s perspective. “Is this code correct?” That is the driving question behind Test-Driven Development (TDD).

The methodology focuses specifically on “unit tests.” The developer takes a requirement and then converts it into a specific test case. Then the developer writes the code to pass those particular test cases only. This practice is intended to prevent unnecessary updates that do not address the requirements. Test-Driven Development (TDD) forces developers to focus on product requirements before writing code, a fundamental difference from traditional programming where developers write unit tests after the writing the code.

Test-Driven Development (TDD) is a simple process that follows six steps as outlined in the “Test Driven Development: By Example.”Let’s use streaming a specific album from the Spotify catalog as an example.

Step 1: Add a test

The first step is to take a requirement and turn it into a test that is clear so that the developer can fully understand the feature specifications.

Let’s say that we work for Spotify and want to create a feature where a subscriber can search for a specific and album and stream it. The test would be to check if a user is a paid subscriber and if the specific album is both in the Spotify catalog and licensed by the artist. If all conditions are met, then stream the album.

Step 2: Run all tests and see if the new test fails

Next step is to run the test to make sure that it fails. If the new test passes, that means that the required behavior already exists and new code is not needed or that the new test is flawed and needs to be modified.

Now we need to run the test to make sure that it fails. The user should not be able to search for and stream a specific album.

Step 3: Write the code

Third, the developer writes code that would make the test pass. Code quality is not as important at this stage; the developer’s goal is to write code that will make the test pass.

In our example, the developer would write the code necessary to allow Spotify subscribers to search for and stream a specific album.

Step 4: Run Tests

The fourth step is to run all the tests. If all tests pass, we are satisfied that the code meets the requirements and that it did not affect existing features. If not all tests pass, the developer must continue to adjust.

Following our example, the tester should be able to search for an album, let’s say “Because The Internet” by Childish Gambino, and stream it.

Step 5: Refactor code

Now that we passed all the tests, the new code must be cleaned up to meet the hygiene standards.

Step 5: Repeat

“Repeat” is not necessarily a next step but a reminder that the developer needs to repeat the process if there are new requirements or wants to improve the functionality of the software.

Typically, teams that implement Test-Driven Development find significant reductions in defects rates despite an increase in initial development costs. Additionally, Test-Driven Development results in improved quality of code that is more modularized, flexible and extensible.

Behavior Driven-Development (BDD) – “Is this what we should be testing?”

Behavior Driven-Development (BDD) focuses on the “outside-in” perspective, meaning we test behaviors which are related to business outcomes. The process is very similar to TDD. However, you are applying the “Five Why’s” principleto each user story to ensure that a business outcome connects with the purpose. BDD requires guidance from developers, testers, and users to ensure answers to the “whys” behind a user story. All of this leads to the driving question behind BDD which is “is this what we should be testing?”

BDD is largely an extension of the TDD methodology. The developer defines a test case, tests code to verify that the test case will fail. Next, the developer writes the code necessary to pass the test case and then tests the code to ensure compliance. Where BDD differs from TDD is how the test case is specified. BDD tests cases exist in a way that specifies the desired behavior.  The clear language of BDD test cases makes it simple for all stakeholders in a development project to understand. The following is an example of a  BDD test case for a user attempting to stream a specific album on Spotify.

Story: Stream specific album on Spotify – description of a user story

As a Spotify subscriber – “who”:  primary stakeholder of a user story

In order to play my favorite album – “what”: effect of a user story on primary stakeholder

I want to search and stream my favorite album from the Spotify catalog – “why”: value to primary stakeholder

Scenario 1:

Given that Childish Gambino has licensed – condition

And the user is a subscriber of the Spotify service – condition

When Spotify subscriber selects “Because The Internet” album by Childish Gambino from the Spotify Catalog – when the event is triggered

Then Spotify service will stream “Because THE Internet” album by Childish Gambino from the beginning for the user – Expected outcome

BDD provides several key benefits to practitioners. The methodology provides a solid structure and format to make it easy for developers, testers, and users to collaborate. Simple language and specification involved in writing BDD test cases make it easy for people all skill levels to adopt. Finally, the methodology ensures that user stories are focused on business outcomes.

Acceptance Test-Driven Development (ATDD) –  “Is the code doing what it is supposed to do?”

Acceptance Test-Driven Development (ATDD) aims to encourage collaboration among the user, developer, and tester to ensure that acceptance tests exist before writing any code. The acceptance test is written from the users perspective and function as a requirement for how the software should function. “Is the code doing what it is intended to do?” That is driving question behind ATDD.

Given Album is licensed to Spotify catalog – setup, specified state

And User is a paid subscriber – setup continued

When User selects album for Spotify catalog – trigger, an action  or event occurs

Then Album is streamed for the user – verification; output is produced, or state has changed

The main benefit of ATDD is that applications become easier to unit test by design.

Test-Driven Development (TDD) vs. BDD vs. ATDD

The “vs.” is intended to discuss how these methodologies differ. They can be complementary.

Test-Driven Development (TDD) -BDD-ATDD

TDD is a developer-focused methodology that aims to encourage well-written units of code that meet requirements while ATDD is a methodology designed to promote collaboration among customers, development, and QA to ensure well-designed requirements. BDD extends the process of TDD. However, the tests describe behavior.

How does CA’s Agile Requirements Designer help?

In these testing methodologies, clear and unambiguous requirements from the beginning of the design cycle are essential to clean and focused code. With CA Agile Requirements Designer, users can create clear and unambiguous requirements from the beginning using a visual designer and automatically generate test cases from the model. ARD can help simplify a lot of the tasks involved with practicing TDD, BDD, or ATDD.

This blog posts clarifies confusions around TDD, BDD, and ATDD. Whatever your testing methodology may be, CA Agile Requirements Designer can help

Join our upcoming web seminar to learn more about these test-driven development practices, coupled with in-sprint test automation technology that can help you:

  • Shift testing all the way to the left—to your business requirements design phase
  • Automatically generate test automation scripts for both open source and commercial frameworks
  • Achieve maximum coverage with the smallest set of test cases, directly from clearly modeled requirements

Start your Free Trialof CA Agile Requirements Designer today and fast track your Test-Driven Development (TDD), BDD or ATDD practices.

Written by: Vinai Amble, Continuous Testing Consultant at CA Technologies

Get Started with Agile Requirements Designer

Automatically create test cases right from your business requirements phase – Free Trial

Related Posts