Test Driven Development, or TDD, is a popular and powerful approach to software development. It is used around the world and has many fans. It is a powerful but tricky technique that is often misunderstood. This article will talk about TDD, explain its strengths and problems, and its relation to agile. So if you are wondering about test driven development vs agile, this will answer all your questions. So let’s get into it!
Test Driven Development is a special approach to software development. In TDD, developers devise and write tests before they write code. Every code change is accompanied by adding and running tests.
It is important to understand that TDD is more about design than development. It doesn’t just mean “write lots of tests”, or “unit tests are important”. In TDD, testing comes first.
Some people describe this as “Red Green Refactor“. That means, first you write some tests, and run them. They will obviously fail. You haven’t even written a single line of code yet! So that is “red” – tests failing.
Then, you write some code that will get the tests passing. So now you are at “Green”. Finally, you refactor. All you did was get the tests passing. It probably isn’t good code! So make it good. Refactor it, then run your tests again. Once all the tests are still passing, you’ve finished refactoring. Hence the “red – green – refactor” cycle.
Starting with tests has some major implications.
It means you are always thinking about tests and testability. The application will be built from the ground up with testing in mind. It means you will be thinking about separation of concerns (to minimise testing surfaces). You will be reducing side-effects (to make debugging and traceability easier).
This should lead to elegant applications. Where each component does one small thing well. And can be easily tested and debugged. And since it is being constantly refactored, the code quality should be high.
Since these tests are being run constantly, they will need to be automated. Nobody has time to manually run hundreds or thousands of tests every time they write a few lines of code! It would be madness.
Since you are always building up automated tests, this gives you a valuable suite of regression tests. That you can run anytime you want. Which in turn, enables things like continuous delivery.
You can also take a detour to other related practices, like behaviour driven development (BDD) or acceptance test driven development (ATDD). Which form part of acceptance testing and test driven requirements.
I’ll soon be publishing an article on test-driven development vs behaviour driven development, so watch this space.
Agile is a modern approach to software development. It is opposed to the traditional “plan-driven” or “Waterfall” approaches that were popular from the 1960s onwards.
It focuses on flexible scope, frequent delivery, and small cross-functional teams. Instead of focusing on plans and predictability, it prioritises customer value, flow and rapid feedback.
Agile is becomingly popular all around the world. In firms from small startups to large enterprises.
It was codified in the agile manifesto in 2001. Since it is a philosophy, people often use a framework like Scrum or a methodology like DSDM. Since those will prescribe some rules and roles to use (which the agile manifesto doesn’t).
You might be wondering about test driven development vs agile. Which is better, and what are the pros and cons.
Well I have some good news for you. You can do both! In fact, you definitely should.
Why you should combine test driven development and agile
In agile, we have small teams working in small quick cycles. They should be constantly building, testing and integrating their code. There is no big “system integration testing” phase at the end of a project. There are no phases at all!
So if you are frequently building and integrating, you will need tests. A lot of tests. A lot of automated tests!
It’s not possible to manually run all your tests. The progression (new tests) but especially the regression (old tests for things you’ve already built).
But if you’ve been doing test driven development, you will already have all those tests.
So not only are TDD and agile not enemies, they in fact go hand in hand!
If you know a bit about agile, you probably know a bit about Extreme Programming. Which is often shortened to XP.
Extreme Programming was created in the 1990s by Kent Beck and some of his colleagues. It focused on small iterations, frequent integration, lots of testing and merciless refactoring.
So test Driven Development is one of the core principles of Extreme Programming, one of the original agile frameworks.
XP turned out to be not nearly as popular as Scrum, but many consider it to be the true “O.G.” agile framework. That really captures the spirit of agile.
Many of the original agile gurus, like Kent Beck (who literally wrote the book on Extreme Programming) and Bob Martin, were advocates of Test Driven Development. So if you’re doing TDD, you know you’re in good company.
If you’re doing Extreme Programming, you are thus killing two birds with one stone. You are doing Test Driven Development, and you’re following agile. Since XP is one of oldest agile frameworks around.
I hope you can see that when you look at test driven development vs agile, there isn’t really a “versus” there. The two are friends, and complimentary. Some people even say if you are doing Scrum but not following XP practices, like TDD, you won’t get much benefit out of Scrum. Which I would agree with!
So get started with agile and TDD today.