The agile methodologies have transformed the way we create software. Terms and acronyms introduced by agile now permeate our vocabulary. Agile techniques, such as pair programming, went from being fringe and weird to being ordinary. Another property of the agile methodologies that have transformed the world of software—for the best—is the major role given to automated testing. In this post, we'll cover a development approach in which automated testing is front and center: acceptance test–driven development, or ATDD.

This post isn't a tutorial, but rather a guide to the concept of ATDD. We'll start with the fundamentals: defining ATDD, explaining why teams and organizations use it, and walking you through its process. After that, we'll cover the main benefits of this practice, as well as its main challenges. We'll then cover the differences—and similarities—between ATDD and two other related approaches: BDD (behavior-driven development) and TDD (test-driven development). And then we'll part ways by sharing some final thoughts. Let's get started.

Acceptance Test–Driven Development 101

Let's start with the what-why-how of acceptance test–driven development. You'll learn what this approach is all about, why people use it, and how they use it.

Defining ATDD

ATDD, as you've already learned, stands for acceptance test–driven development. Despite the name, ATDD isn't a testing technique. Instead, it's a software development methodology like its "sibling" TDD.

So, what is ATTD? It's a software development methodology in which tests—in this case, automated acceptance tests—are used to drive the development of an application.

If you're familiar with TDD, you might be thinking that this sounds suspiciously like it. That's not a coincidence: TDD and ATDD (and also BDD) are related approaches. They borrow from each other, and there's certainly some overlap between these approaches. We'll talk more about how these approaches relate to each other soon. But for now, suffice it to say that ATDD tests are higher level and focused on the application's functionality from the user's perspective. TDD, on the other hand, is more developer-centric and focused on lower-level tests.

Why Should You Care About ATDD?

Why do people use ATDD? Isn't TDD enough? No, because they're different approaches that serve different needs. As mentioned, TDD is a development technique. It's developer-centric by nature, focused on technical details about the code. And there's absolutely nothing wrong with that.

However, an approach like ATDD means to bridge the gap between developers and nontechnical members of an organization. The ATDD process is meant to foster collaboration between testers, developers, business analysts, and so on. By using ATDD, you can bring everyone into the fold, create comprehensive executable specifications for the application, and create conversations about the system using a shared language everyone can understand.

How Is ATDD Done?

In ATDD, as in TDD, the process starts by writing a failing automated test. You write the test before writing the production code, and that's why the test fails. The difference between the two approaches, at this stage, is that TDD focuses on low-level unit tests written, reviewed, and read by developers. TDD, as a process belongs 100% to the developers. In ATDD, the tests aren't unit tests but acceptance tests, which describe the acceptance criteria of the feature that is to be developed. Those are written by a collaboration of developers, QA professionals, and business people.

Here's an example of acceptance criteria:

Given a user visits Amazon.com When the user searches for "ATDD" And select the category "Books" Then the user should see as a result books with ATDD in the title

For the next step, the developer writes the feature to satisfy the failing acceptance test. The code is then refactored if there's a need for that.

Acceptance Test–Driven Development: The Main Benefits

If you were already familiar with TDD before reading this post, you might be thinking that ATDD is essentially TDD, but with acceptance tests in place of unit tests and made with the help of nontechnical people. I'd say that's an accurate assessment.

So, what are the main benefits of ATDD? Why use this approach? Well, since ATDD might be considered a form of TDD, some of the benefits are the same. However, ATDD brings some benefits of its own:

  • Quality. With the help of ATDD, teams can ensure that they're delivering the features in a way that matches the users' expectations.
  • Collaboration. ATDD fosters communication and collaboration between technical and nontechnical people inside the organization.
  • Regression suite. The ATDD process results in a comprehensive suite of acceptance tests that can detect whether changes to the codebase result in regressions—that is to say, defects coming back or older features no longer working.

Not All a Bed of Roses: Some Challenges You May Face When Doing ATDD

Despite its benefits, ATDD isn't a perfect approach. There are some important challenges you might encounter when trying to adopt this process.

  • Lack of buy-in from the business. ATDD is meant to foster collaboration, but you need some support from the business to start the process in the first place.
  • Reluctance of developers. The developers themselves might feel hesitant to adopt yet another practice into their work routines.
  • Confusing with similar approaches. ATDD is often mistaken for TDD or BDD. Such confusion might overwhelm developers and discourage them from adopting the technique.

Similarities and Differences With TDD and BDD

What are the main similarities and differences between ATDD and its related approaches, TDD and BDD?

ATDD vs. TDD

Let's start with the low-hanging fruit, which is TDD. As mentioned earlier, the main difference between the two approaches is that TDD is developer-centric. Developers own the whole TDD process. ATDD, on the other hand, is meant to include QA professionals, business analysts, and so on. It's a process aimed at automating the acceptance criteria for the user requirements.

Another key difference between the two approaches is that ATDD acceptance tests are business-facing, while TDD unit tests are not. TDD tests help programmers ensure they're building the thing right. ATDD helps the team ensure it's delivering the right features.

ATDD vs. BDD? They're the Same!

When it comes to BDD, the lines are blurrier. BDD (behavior-driven development) helps foster collaboration between the different actors involved in software development. By using a shared language, developers and nontechnical people alike can collaborate in creating detailed, executable specifications that describe the intended behavior of the software.

My take on this—which I admit might be a contrarian view—is that BDD and ATDD are essentially the same practice, with different vocabulary. Both ATDD and BDD are TDD but with test-driving features instead of individual units.

Acceptance Test–Driven Development: Yet Another Agile Revolution

Practices from the agile methodologies have been transforming the software industry. Among all of those, we can safely say that the emphasis on automated testing has really changed the landscape of software development. In this post, we've covered acceptance test–driven development. This, like TDD and BDD, is a software development methodology in which tests play a vital role.

You now have a more solid understanding of this approach, including how it relates to similar techniques. You've also learned about some of the challenges you might encounter when trying to implement ATDD.

Speaking of challenges, there's one that many organizations are facing right now: a sudden and extreme switch to remote work. Since the agile manifesto itself singles out face-to-face collaboration as essential, it's no surprise that many organizations are struggling with having to deal with remote work.

However, it is possible to have a productive and efficient team that can apply agile techniques in a remote, distributed work environment. If you want to know more, take a look at our guide about distributed agile teams. Thanks for reading.

This post was written by Carlos Schults. Carlos is a consultant and software engineer with experience in desktop, web, and mobile development. Though his primary language is C#, he has experience with a number of languages and platforms. His main interests include automated testing, version control, and code quality.