Tests Are An Implementation Detail

May 28, 2014 Matthew Parker

I want to go fast forever.

Let me back up. My client wants a new feature for their software. I’ve been doing this long enough to know that there’s a good chance they’ll want to change what they see, once they see it. So I want to show them something as quickly as possible – before I waste time building the wrong thing.

But sometimes I can’t show them something quickly.

Sometimes the code is just plain indecipherable. It takes me a long time to understand it, because the writer did not think about someone ever reading it. And that slows me down.

Sometimes it’s downright tedious. Sometimes lots of parts of the system have to stay in sync, because they all know something – and when that “something” changes, they all have to change with it. And that slows me down.

Sometimes it’s frustrating. When I make one change, ten other things break, for reasons I don’t understand. This slows me down. I have to build a vast mental model of the software in order to keep track of everything. That takes a long time, and it’s exhausting. And that slows me down.

I want to go fast forever.

But I can’t. I can’t because my code isn’t clean. I need to clean it.

How do I keep code clean? I change it. Every new feature of the system changes my understanding of the system, and of the problem domain. And my code needs to reflect that. I need to make the code the clearest, cleanest, simplest, and most obvious expression of the problem domain as I currently understand it. Every time I add new behaviors to the system, I need to update the code, refactor it. Every time.

But fear keeps me from changing it. What will I break when I change this code? When I don’t change my code, it rots. And I go slower, and slower, and slower.

I lack confidence. How can I feel confident that my changes haven’t broken any of the expected behaviors of the system? I need a magic button that I can press at any time that will instantly tell me if I’ve broken something.

I haven’t found a magic button. So what do I do instead? I write tests. And those tests, if written well, will quickly tell me if I’ve broken something. Depending on how I write them, they might also tell me other things about the design of the system. But that’s a different story.

Tests are an implementation detail for a feature of your team: the ability to go fast forever. They don’t come for free. They’re hard work. They’re not an end unto themselves. They’re a means to an end. There are other ways to implement this same feature. But from what I’ve seen, they’re more expensive, slower, and less reliable. If I find a cheaper way to implement this feature, I’ll gladly try it. I still want that magic button. Till then.

About the Author

Matthew Parker

Matt Parker is Head of Engineering for Pivotal Labs

More Content by Matthew Parker
Previous
Be Evil
Be Evil

In the fourth “Is TDD Dead?” debate, DHH, Martin Fowler, and Kent Beck discuss the cost of tests. DHH point...

Next
Deploy and Update Your Google Compute Engine VMs Using Cloud Foundry BOSH
Deploy and Update Your Google Compute Engine VMs Using Cloud Foundry BOSH

Do you want to to deploy a full Hadoop Cluster on Google Compute Engine in under 3 minutes? Would you like ...

How do you measure digital transformation?

Take the Benchmark