I don't understand the differences between the following terms:
How do these terms work in the agile methodology? What's the difference from the waterfall approach?
I've seen TDD/BDD/ATDD used interchangeably with Scrum/Kanban/Agile, so the confusion is understandable. Here's my take on the differences:
The difference between Waterfall methodology and an iterative methodology (agile, Scrum, etc.) is that Waterfall requires each step of a defined process be performed to completion in a particular sequence. In an iterative methodology you complete small slices of the problem at a time by gathering just a few requirements and coding each one to completion, then seeking feedback from your users.
The Waterfall
In Waterfall you follow a rigid pattern. You gather all the requirements you can, then you analyze them, then you design a solution, then you code a solution, then you test the solution, then you deploy the solution. This originated in the engineering processes of the physical world long ago, and was carried over to the software world because it's a process that is well understood.
The problems with Waterfall
The main problem with Waterfall is that if it's not perfectly done up front, costs or quality will suffer. If the tester finds a bug, they report it to the coders. The coders look at it and may say "well that's a flaw in the design", and hand it up to the designers. The designers say "well, this is what's in the requirements." So they go back to the analysts, and so on, and so on. They fix the requirements, pass the fixed requirements to the designer, who modifies the design, who gives it to the coders, etc. Every mistake is extremely expensive to fix. To avoid this cost Waterfall requires intense attention to every detail at every step. The requirements must be reviewed by designers, testers, and the stakeholders. The designs must be reviewed, the code must be reviewed, etc.
And this is where Waterfall can lead to poor quality. If the tester passes a bug to the coders, the coders may look at it and say "this will take a big design change to fix correctly, or we can just put a patch here." Management will almost always say "do the patch, because it's faster than fixing the entire design and we have a deadline to meet." And it doesn't take a lot of patches to turn a flexible design into a brittle product.
The other problem with Waterfall is the lack of continual feedback from the users. The Waterfall process can take months or years. By the time their product is fully delivered, the team may have interpreted the requirements differently, and developed something completely different from what was intended or desired. Or the market for the product may have changed, and the product is no longer needed. All that work becomes a sunk cost that never delivered a dime of value.
Iterative product management
In an iterative approach that uses Behavior Driven Development and Test Driven Development the cycle of product development is dramatically shortened. In some methodologies such as Scrum, iterations can be defined in terms of weeks; in others, iterations can be done in days, hours, or even minutes. With BDD requirements are gathered, and then specifications are written in the form of functional tests. One common complaint of developers is that requirements are poor; in BDD a poor requirement is immediately identified because it's impossible to write a test for it. So the requirements are fixed almost as soon as they're being written. This reduces many problems.
These functional (behavioral) tests obviously fail, because there is no code written yet to pass them. The developers then write just enough code to pass the tests (they do this in short TDD cycles, building up the feature by creating a quick skeleton first, then adding bits of the feature one piece at a time.) During this activity, the developers may discover flaws or omissions in the specifications; fixing them is often as cheap as asking the stakeholder a clarifying question, fixing the test, then fixing that code module. The key is the faster the feedback, the cheaper it is to course correct.
Test Driven Development then builds code through a three step process: red, green, refactor. When they start development, they write a test that fails (failing tests show up as red). By the act of writing the test first, the developer must think about the interface to the module they're writing, and how to make it easily testable. Stateless logic is easier to test than stateful logic, so they have incentive to write stateless code, dividing their code into service objects and value objects. Code that is easy to test is code that is modular and easy to use. This provides the first step in good design. They then write enough code to pass the test (it's green.) Now they can refactor the code with confidence. They refactor the code they've just written in order to eliminate duplication, and to adhere to the SOLID design principles. The act of refactoring imparts good qualities associated with modularity: tight cohesion and loose coupling, which make the code module easy to use and easy to reuse. And the tests serve as continual proof to the developers that their changes are not harmful.
The Waterfall is inverted
TDD turns the Waterfall model upside down: you test the requirements first, then you test your code, then you write your code, and then you finally impart good design to the code. Because the team is producing tiny slivers of functionality that are always fully tested, quality starts high and stays high. Because the design principles are followed during refactoring, the code is modular, flexible, and reusable. And because the stakeholders are continuously involved in reviewing and using each little sliver of functionality, they can make changes at any time without incurring huge costs.
Iterating works because it's continually answering two questions: "are we building the product right?" and "are we building the right product?"
The problems with iterative
And this is where iterative approaches have limits: meeting deadlines with a specific list of features. A product owner needs to see that the team is heading to a goal, and they can even get a measure of the pace of progress, but the actual features available on date X can't be perfectly predicted very far in advance.
This also becomes a problem when an iterative team has to interface with external teams. If both teams are agile, they'll understand each others' issues; but if one team is a hardware team or service organization, their flexibility is often out of their control. This can lead to friction and such interactions must be carefully managed.
How to choose between Waterfall and Iterative
There are long debates on whether Waterfall is the best choice to develop a product, or iterative. The arguments in favor of Waterfall are that it has been successfully used for a very long time. Some people are really good at Waterfall. Managers and executives have to work with budgets and deadlines, and the Waterfall steps are easy to understand.
It's not intuitive that iterative approaches produce higher quality products; it's also uncomfortable to be told "we'll have some kind of product for you on January first, we can assure you that it'll work perfectly, but it may not be the product you're thinking of today." These debates go on and on, but don't help answer the question of which methodology to choose. It turns out the debates are focusing on the wrong things. There is an easy test to determine whether a product should be built with waterfall or iterative, and that is to measure the cost of deployment.
The cost of deployment
Consider a web site. You can deploy a new version of the web site by clicking a mouse - that's as cheap as it gets. Consider a smartphone app that can be deployed by sending a new version to the app store - also fairly cheap. Even a traditional computer program can have updates delivered to clients via the web.
Now consider a tough-to-deploy client, such as the software that runs an alarm clock. You can iterate all you want in the comfort of your office, but once you send those clock orders to an offshore factory, and 10,000 clocks are sitting in a shipping container on the dock or have been delivered to the store shelves, it's far too late to be updating their software. The production and installation of hardware makes iteration of those steps too expensive.
And then there are the impossible to iterate products. Anything that impacts health or safety has certain standards of design and testing that are mandated by government or industry agencies; and the current standards do not allow for iterative approaches to design. You can't deliver 5% of an air traffic control system and expect planes to keep safely flying.
Mixing Waterfall with Iterative
Back to the alarm clock example, it's tempting to use iterative development on the software or firmware portions of the product in order to guarantee high quality, and to use Waterfall to effectively manage the production of the hardware. Such a mix has to be done carefully. Iterative approaches cannot guarantee deadlines will be met, but factories, component orders, installers, and freight shipping is usually scheduled months in advance and can't be delayed without significant costs. In these cases you may have to look at custom approaches. Perhaps the hardware can be designed to be flexible - a dummy blank button on version 1.0 of the product could hide the missing SuperWakeyAlarm feature that gets delivered with version 2.0. Perhaps the boxes get printed without the missing feature, but when it's delivered to the factory, the boxes get a "New! Improved!" sticker that touts the new feature.
Conclusion
In general, iterative approaches deliver higher quality software faster and cheaper than Waterfall; but not every project is suitable for iterative product management.
Kate's answer is great, but I want to throw in my 2 cents for differentiating TDD/BDD/ATDD.
TDD is writing tests first and letting those tests drive the development of your application. This introduces the idea of Red/Green/Refactor. The basic process is to:
Note that TDD is a high level concept and can be applied at any level of testing in the pyramid (unit, integration, acceptance).
BDD is a technique for doing TDD. You frame your tests so that they test application behavior and NOT specific scenarios. That may seem a bit nuanced, and it is. And it is the reason that BDD is so interchangeably used with TDD and ATDD. Consider this test:
describe Calculator do
it "returns 2 when I add 1 and 1" do
expect(Calculator.add 1, 1).to eq 2
end
end
What does this test? Well, we've framed it so that it ONLY tests that 1 + 1 == 2. We're not testing a behavior, but instead, a specific data set. We're not proving that 2 + 1 == 3. Or 99 + 1 = 100.
But what if we framed our test like this?
describe Calculator do
context "when adding 1 to a number" do
it "returns the next sequential number" do
expect(Calculator.add 1, 1).to eq 1.next
end
end
end
This seems super trivial (and my example definitely is), but this test proves that 1 + 1 == 2 and 6 + 1 == 7 and 1500 + 1 == 1501.
That's BDD in a nutshell.
BDD is a high level concept too and can be applied to any level of the testing pyramid. A declarative approach to acceptance testing is kind of inherently BDD. But you can do imperative acceptance testing that is more tied to specifics and generally less BDD in nature.
Unit testing should be BDD in my opinion. I find that it often is, though it's not often framed that way.
ATDD is testing from the business' perspective. We're not concerned with the HOW but the WHAT.
Where a unit or integration test concerns itself with the implementation (the API returns the correct status code), an acceptance test concerns itself with the result (the user can log in).
ATDD is taking this tenet of acceptance testing, automating it, and letting those tests drive the development of the application. Thus you can see how the TDD fits into ATDD.
Of course, all of these terms have been mixed, picked apart, and redefined too many times. When I'm discussing their implementation with a coworker, I think it's helpful to define them to set a common foundation. My BDD is not always the same BDD that my coworker is referring to. The same goes for ATDD and (to a lesser extent) TDD.
EDIT
Changed a bit about BDD to clear up my thoughts.
TDD is a process. BDD and ATDD are techniques for doing TDD. Writing a unit test, then coding to make that unit test pass is also TDD.
But TDD has become synonymous with that last example, and I think this is where a lot of the confusion comes from.
TDD == unit testing is where a lot of the confusion comes from, IMO.
Kanban and Scrum are Agile process frameworks and therefor have short iterative development cycles as compared to the longer separate phases of waterfall projects. Agile projects focus on getting a working product in short iterations, each iteration should deliver a piece of deploy-able product.
BDD, TDD and ATDD are not development methodologies and can be used in waterfall projects. They are techniques to design requirements and test-cases which can be automated. Often they are used in Agile software development, because they give a fast feedback cycle for requirements and code under development.
Because Agile development does not have a separate testing phase its important that most if not all testing is automated. Applying BDD or TDD makes sure each new development has automated test coverage and the behavior is safe guarded iteration after iteration. This is why these practices are more important in Agile development than in Waterfall.
I would read the Art of Agile book, although it describes another Agile flavor eXtreme Programming. It clearly describes technique's like TDD how and why they are used. Another good read is Agile Testing.
