Test Driven Development Slows Us Down?

I hear from teams and their managers that Test Driven Development (TDD) is taking them longer than their usual development practice. That’s not been my experience at all. But I can see where some may get the impression that TDD is slower.

Let’s say we’re writing some code for a new feature. And it takes X amount of time to write that code. When doing TDD we also incur the time cost of writing Y amount of unit test code. And quite often there is more unit test code than code for the new feature. When we compare that amount of time – unit tests and feature code – against just writing the feature code, then of course it appears slower.

However, in the Test Last case we’re not accounting for the time it takes to verify the feature is working. On one system I worked on here is what it took to verify the feature code I had written:

I need to build a system to test. Often that meant integrating others’ changes in order to build the complete thing.
I had to have an environment that I could deploy and test in. This could mean contention for limited environments, it usually involved other people, and frequently meant I had to wait for resources to be freed up.
The data in the environment had to match the scenarios I wanted to test. Which could require custom SQL scripts and data refreshes in order to test the different aspects of the feature.
Now that I’ve got an environment and data ready, I can launch the system. This could be starting services in a certain order, setting my logging levels so I can inspect what’s happening, launching my application, setting breakpoints, and manually navigating through the system to the precise area where I can test my feature.

Because of the overhead and steps involved in Test Last I found myself batching up changes so I could test many things at once. Which led to me being not as rigorous with the testing, and often messing things up because of the manual nature of so much of that process.

With Test Driven Development I can confirm my feature code on my own machine without involving all of those steps and delays. When my unit tests don’t behave as expected it’s in the context of code I am currently thinking about and not something I may have written hours or days before. I get into a very fast feedback cycle of how I expect the code to behave, via unit tests, and writing code that behaves that way.

And a nice side benefit is that over time I also end up with a suite of regression tests that can instantly alert me when new code breaks an older part of the system.

It’s obvious to me why I do TDD, so why haven’t all teams adopted it? Well, to start, not many developers have been taught to approach writing software this way. Our traditional education teaches us how to code first, then test after. Test Driven Development asks us to drive development by flipping this approach around, to write a test first, a test that fails, then write the code that gets that test to pass.

This TDD approach is like any new skill. It will take time to adopt and have it become a natural part of your development. Think back to when you learned to ride a bike or drive a car. How awkward it felt, the mistakes you made, until it started to click. And now you can drive or ride without a second thought and those vehicles propel you faster and farther than you can go on foot. Test Driven Development is that vehicle that makes me faster.

Paul Moore is a Technical Agile Coach with Rocket Nine Solutions.

Test Driven Development Slows Us Down?

Friday 5 PM Release Anxiety

Agile Strategy for Financial Services Projects

Certified Agile Leadership for Teams – CAL-T