Skip to content
avatar

Twelve Benefits of Writing Unit Tests First

Twelve Benefits of Writing Unit Tests First:

How do you solve a software problem? How do they teach you to handle it in school? What’s the first thing you do? You think about how to solve it. You ask, “What code will I write to generate a solution?” But that’s backward. The first thing you should be doing— In fact, this is what they say in school, too, though in my experience it’s paid more lip-service than actual service— The first thing you ask is not “What code will I write?” The first thing you ask is “How will I know that I’ve solved the problem?”

(Via Coding Horror.)

I’ve written a lot of code. And recently, I’ve been trying this whole test-first thing out, and I’m really happy with the results. Everything they say in the article is true, and it makes a lot of sense, but I think the real benefit is far simpler:

Writing tests for code that doesn’t exist yet means that you come at the design from the point of view of a user with a specific problem, instead of the normal point of view of a coder trying to make his Brilliant New Solution™ that is both a dessert topping and a floor wax.

This plays into one of the other ideas XP expounds: Do the Simplest Thing That Could Possibly Work. Instead of trying to solve all the problems you might ever have, you tackle the problem at hand right now by writing a test that is the problem at hand right now, and deal with the rest later. Sometimes later is in a few minutes, sometimes it’s in a few days, and sometimes it’s never, but Test-First Programming lets you split those tasks down into more manageable chunks, and that’s huge.

Back when I worked at ParaSoft and was peddling Unit Test software, one of the biggest problems we found was this huge string of dependancies most code has built into it. In order to test class X, you need to create an instance of class Y to pass into the constructor. And Y, of course, needs a Z. But you can’t make a Z without an A and a B, which requires this environment property set just so. This seems insane because it is insane: no one sets out to write like this but every company I visited had code that looked exactly like this.

And it’s because they were trying to bolt unit tests on at the last minute. If they had tested first, they would have thought “This is insane. We didn’t set out to write like this” and they’d be right, and they’d fix it, and (key point) their architecture would benefit because they had to think it through before writing the code and “unit testing” with the compiler.

That’s the power of test-first: it makes you see the code from the vantage of the programming who’ll have to make use of it instead of the one creating it, and that’s the seat you’ll be occupying for most of the class’ lifetime, anyway.

{ 2 } Comments

  1. avatar Tim King | 2006-08-15 at 7:42 am | Permalink
    … from the point of view of a user with a specific problem, instead of the normal point of view of a coder trying to make his Brilliant New Solution™ that is both a dessert topping and a floor wax.

    This is a great way of putting it! I wonder how many developers reject test-first and, more broadly, XP because they like designing kewl code that never gets executed for features that never get used. It may sound nuts, but I run into it all the time. They write code, code, and more code, “just in case.” None of that code is tested. Much of it can’t be, because there’s no way even to invoke it. For example, I just refactored a function that checked for and returned errors that could never happen. That is, there was no combination of inputs that could invoke the error condition. The code that called this function also checked for error codes that the function never returned. Of course, sifting through that was the easy part, because most of the code was so discombobulated, I would just sit there and shake my head, thinking, How could anyone write this? They seem to be the same people who comment out obsolete code, rather than deleting it.

    -TimK

  2. avatar TALlama | 2006-08-27 at 12:10 am | Permalink

    I often find myself exploring the Brilliant New Solution path, and then catching myself and deciding better of it. “Do the Simplest Thing That Could Possibly Work” I tell myself, and I do for a while, but I always end up with grandiose plans again.