I’ve seen TDD/BDD/ATDD used interchangeably with Scrum/Kanban/Agile, so the confusion is understandable. Here’s my take on the differences:
- Waterfall is a software development methodology where each kind of development activity happens in a separate phase (requirements gathering, design, development, testing…). Typically, waterfall projects work best where the problem the software is intended to solve is fully knowable and clearly defined. Not many software projects meet that criteria – it’s the unknown unknowns that cause problems.
- Agile is a software development philosophy that aims to focus more on short cycles with all development activities happening simultaneously (although not on the same parts of the project at the same time – as new requirements are discovered, the team builds them into their design while working on developing and testing areas they designed in previous cycles). There are a number of Agile methodologies including:
- Scrum, which focuses on constant communication between team members via frequent short ceremonies. I’ve often seen Scrum used as the framework for an agile process, with a Kanban board used as the primary tool to communicate progress to people outside the team.
- Kanban, which focuses around the Kanban board (at least in my experience). The board holds the tasks agreed on for an iteration, and team members choose tasks move them to the different state columns as they work.
- There are other agile methodologies, but the Scrum/Kanban combination is one of the more common varieties.
- TDD/BDD/ATDD are software development techniques that can be used in any methodology although aspects of all three are often part of a team’s agile approach.
- TDD is Test-Driven Development: the idea is that unit tests are written first, then enough code is written to make the tests pass. The pure TDD cycle is to write one failing unit test, then enough code to pass the test. Then a second failing unit test, then enough new code to pass both tests. And so forth.
- BDD is Behavior-Driven Development: this technique operates at a slightly higher level than TDD while still following the basic principle of writing the test, then coding to pass the test. BDD is usually the lowest level that will use the Given-When-Then pattern to describe the test (e.g. “Given that I have logged in, When I click the My Orders link Then I will be directed to the Order List page”). It can be difficult to distinguish between BDD and ATDD – the difference here is subtle.
- ATDD – is Acceptance-Test-Driven Development: this and BDD are often, in my experience, used interchangeably, particularly if the acceptance test is expressed in the Given-When-Then pattern (such as: “Given that I am a logged in user, When I go to My Orders Then I will see a list of all the orders I have made in the system, ordered from the most recent to the oldest.”)
- It’s not uncommon to see blends of all three techniques used:
- User requirements are written as one or more user acceptance tests (that fail)
- Each acceptance test is decomposed into one or more behavior tests (that fail).
- Each behavior test is decomposed into one or more unit tests (that fail).
- At this point coding begins and each level iterates until all the user acceptance tests are passing.