TDD vs BDD vs ATTD: key differences and benefits

There are 3 development methods that integrate quality into software development. 

Acceptance test-driven development.

Test-driven development.

And behavior-driven development. 

Software projects fail left and right in the unforgiving market due to running out of budget.

That can happen because they didn’t test often, and they didn’t test early.

The software development methods we’ll talk about here will remedy that by making sure quality assurance starts when development starts.

Although all 3 of them are similar, there are many key differences.

Here we’ll talk about their importance, how to do them and what separates them.

Let’s dive in!

What is shift left testing?

We can’t speak about TDD, ATTD, or BDD without mentioning shift left testing.

It’s a movement in agile software development that advocates introducing testing from the very beginning.

As you can see from the image, traditional testing starts late in development.

Shift left testing, however, starts right at the beginning, even before early design starts.

That means quality assurance is integrated into the project from day 1.

Not only that but it also means you’re constantly catching bugs and problems early. Leading to:

• Time-saving
• Higher quality
• Money saving

That last point can be best illustrated by the below graph.

Let’s unpack that.

Most defects in software development are introduced when coding starts.

Those defects start being discovered around the time unit testing starts.

Now here’s the most important part.

The cost to repair defects rises exponentially as development draws to a close.

When unit tests start it already costs 4 times more than it would if the problem was caught during coding.

By functional testing it’s 10 times.

By system testing it’s 40 times.

By release, it’s 640 times. That’s not 64. It’s 640.

Let’s say you have a problem that would initially cost you $100 to fix.

By release, it’s $64,000. That kind of money runs you out of business.

That’s why shift left testing is so important and that’s why development methods that adhere to it are valuable.

Now let’s take a look at them.

What is Acceptance test-driven development (ATTD)?

The first method I’ll discuss is ATDD or acceptance test-driven development.

Acceptance tests are written from the perspective of an external user, such as a client.

These tests are business facing and they support programming.

Source: GeeksForGeeks

Acceptance testing comes right after system testing before making the product available for use.

They are a great tool when written before the code and the user’s executable specifications. 

But acceptance tests need acceptance criteria in order to be done right.

Acceptance criteria are basically a list of priorities for development.

For example: Documentation can be put as one of the acceptance criteria which means acceptance tests will take that into consideration before they can be passed.

All that being said let’s take a look at how ATTD looks in practice.

ATTD steps

I call them the 4 D’s:

• Discuss
• Distill
• Develop 
• Demonstrate

Let’s get into each of those steps.

Source: Quinta group

Discuss – During this phase, you discuss the user story. That means you discuss what the customer needs from the product at the end of development.

Distill – Here we agree on the acceptance test and automation criteria. We also consider different scenarios and how the system will behave during those scenarios. 

Develop – Now, actual development happens. You develop a feature following the Test First Development approach until it’s passable.

Demo – Here, you demonstrate the prototype model to the business stakeholders and start iterating. 

Pros and cons of ATTD

Let’s look at what the benefits and flaws of acceptance test-driven development are.

With ATTD out of the way, time to turn to TDD.

What is Test-driven development (TDD)?

During test-driven development, we test every single change.

Tests are built to check for errors before we start development. We use those tests to guide code creation.

If a test spots a problem, we stop development and start working on a fix. This sort of development makes the whole process extremely efficient.

It’s a process in which test cases are made first and code is used to validate them. It depends on the repetition of a very short development cycle.

Test-driven development is a technique in which automated Unit tests are used to drive the design and free decoupling of dependencies.

We generally follow the below steps.

TDD steps

It’s a simple process but not an easy one.

Source: TestDriven

Let’s dive into those steps.

1. Add a test
2. Run all test cases
3. Write the code
4. Run the test case
5. Refactor code
6. Repeat 

Add a test – Write a test case that describes a specific function. In order to make the test cases the developer must understand the features and requirements using user stories and use cases.

Run all test cases –  When you run all test cases you want to make sure they all fail.

Write the code – Here you write the code that passes the test case.

Run the test case – Now the test case should pass.

Refactor code – We do this in order to remove code duplication or redundancies.

Repeat – The steps are repeated again and again.

With steps out of the way let’s look at the pros and cons of this development approach.

Pros and cons of TDD

Test-driven development is great, but it does have some pitfalls.

Having finished with TDD we move on to the final approach.

What is Behavior-driven development (BDD)?

It’s an approach that supports joint efforts among designers, developers, QA, marketing, and other non-tech members (PM/PO).

Behavior-Driven Development is an Agile software development process heavily influenced by TDD and DDD (Domain-driven development).

It permits the QA to develop test cases in simple, readable language.

Conversations and examples explained in understandable language are at the core of this development method, bringing a better understanding of the system’s behavior.

Automated testing especially thrives during BDD because it’s more focused on system behavior, rather than code implementation.

Basically, it makes sure every new feature is in accordance with desired system behavior.

BDD steps

Behavior-driven development can be broken into 3 phases:

• Discovery phase
• Formulation phase
• Automation phase

Source: Cucumber

Discovery phase – Here we hold conversations and product discovery workshops to research and determine acceptance criteria.

They’re chosen by considering a few factors:

• Core features
• Market
• Target persona
• Product type

The product manager is heavily involved during this phase, along with the project manager, QA engineer, and developers.

Formulation phase – After finishing the discovery phase it’s time for implementation. This phase ensures that acceptance criteria are applied before development begins. That’s done using acceptance tests.

Automation phase – Here we automate acceptance tests. The goal of this phase is to have acceptance tests run constantly to make sure criteria are met and that new behaviors fit the system.

Pros and cons of BDD

As with the previous 2, let’s take a look at good and bad aspects of this development method.

Now that we’ve described all three development methods let’s take a look at how they compare.

ATTD vs TDD vs BDD: key differences

To better understand each development method and to see which suits you, here’s a table comparing them.

TDD vs ATTD vs BDD: the verdict

Have you decided yet on which development method best suits you?

No?

Well, that’s because each of these methods has its merits.

TDD is extremely focused, allowing no unnecessary code to be written. If you’re on a tight budget that’s the way to go.

ATTD builds on TDD, adding business stakeholders into the equation. If you’re more customer oriented, you should use this method.

BDD is all about making features comply with the desired system behavior and it does so through straightforward language. So if you want the best collaboration between developers, testers, and your product team, choose BDD.

Alternatively, we’re here to worry about all that. Our software development experts will choose the right development method for your project and execute it to perfection. 

Feel free to contact us.