The Spec
The Language
The Practice
The Books

The New Joy of Programming

Writing software is actually quite easy. Writing software that does something valuable is a bit more difficult. Writing software that keeps doing something of value over time is even more difficult, and writing software that keeps doing something of value over time that can be changed at any time is even harder. I feel happiest when my code does all of these things and this, I found early in my career, was difficult to accompish.

There are a couple of things that used to bother me as a programmer that no longer do. I remember when I used to be afraid when someone asked me to change my code. Especially when the change seemed easy to the user. I knew that I would probably have to attempt to explain why that particular part of the code is hard to change even though the behavior that they were requesting was quite simple. I no longer have that problem, though. I also remember worrying about whether or not the change that I just made had broken a part of my system somewhere that I didn't remember. I don't have that feeling anymore either. In fact, those feelings have been replaced by some good ones.

Now, whenever I get to program, I go home satisfied that I actually produced something that works. That's a feeling I used to get only once-in-a-while in the past. Something changed in my career about five years ago now.

I stopped writing code without first writing a test program.

Why does it work this way? Well, to be quite honest, I don't know exactly, even though I've been trying to figure it out for years. But I do have some conclusions I am willing to make at this point.

First, I now know exactly what the goal is. The goal is only one of two things: either figure out what I'm going to test for, or make the test that I have already made pass. This seems to split my thinking into two distinct parts: discovery and invention.

When I write a test, I have to figure out what the program is supposed to be doing. This usually requires some kind of discovery process. I must either investigate the technology that I am using or ask my user, customer, or manager how the product is supposed to behave. This research is a discovery process and sometimes takes quite a while. Forcing myself to write a test for a particular feature of the product being developed forces me to really think about the product first and what it is that I am developing. Doing this first separates this kind of thinking from the kind of thinking required to actually make the program work. This seems to really help me.

After I write a test program and I watch it fail, it is very obvious what I must do next. I must make the thing pass. I no longer have to think about what I am supposed to be doing, now all of my thinking is directed toward figuring out a way to make the product work. This is really an invention process. This is what I thought programming would be when I first wanted to be a programmer. I know exactly when I am finished; when the test passes.

Then I start over again. I uncover a new test, and then make it work and so on. At the end of the day, I have objective proof that I have completed something. Anyone can come and see my tests pass. The tests show exactly what I did that day, and because the tests are there, I can rest assured that tomorrow (or next week) when I add more code, or change something, that all I have to do is run the tests again to see if everything else still works.

There is another reason why I am happier. When my code is protected by a set of automated tests, I can make major structural changes to "clean up" the code. I can take out code that I suspect doesn't do anything anymore and I can make new subroutines. These structural changes are commonly called refactoring today. Without tests, refactoring can be a less-than-happy experience. The freedom to refactor definitely makes me happier.

If you want to try Test-Driven development with JavaScript right now you can do so in your browser using the Test-Driven JavaScript Writer. This site also has a simple example that you can work through.

Troy Taft is the Principal Consultant and founder of Troy Taft Consulting, a firm specializing in high value software development. He also authors a free monthly newsletter called Software Matters.

Copyright 2007 Troy Taft All rights reserved, you may print this article for your personal use.