原创 How I write software (Part 3)

[Continued from How I write software (Part 2)]

Test, test, test

Now we get to what I consider to be the foundation of my programming style. I test. I test everything, A lot.

The reason may sound odd: I test because I hate testing. Most programmers do, but in my case it's personal. I hate testing because I hate the notion that I wasn't perfect to begin with. So I hate testing. But if I hate testing, I hate testing later even worse. I test every line I write, right after I write it, so I won't have to come back in shame, later, to put it right.

In the best tradition of programmed programming, I don't want to wait until days or weeks later, to find out something's wrong. I sure don't want to wait until the entire program is complete, like as those poor saps on the Unix system had to do. I want to keep that instant gratification going. I want to preserve the expectation of success.

That's why I test as I write. Add a few lines of code (three or four), then test.

A few consequences fall out of this approach. First, the term "code and unit test" implies that you've got a test driver for every unit. And indeed I do. No matter how small the unit under test (UUT), it gets its own test driver. And yes, I absolutely did test iscomma (hey, it didn't take too long. There are only two outcomes, after all).

I'm also a big believer in single-stepping through my code. My pal Jim Adams disagrees with me on this. He says that if you're going to use single-stepping at all, you should only do it once. After all, he argues, the instruction is going to do the same thing each time.

Maybe so, but I do it anyway. Consider it part of the programmed programming paradigm. I never turn down an opportunity to get warm fuzzies. Single-stepping reminds me in no uncertain terms that my processes—mental and computer-wise—are still working.

Finally, there's an implicit assumption that you have a fast IDE that can give you test results in a hurry. I've been spoiled on this point ever since I fell in love with Turbo Pascal. The idea that I could get a compile as fast as I could get my finger off the 'R' button, blew me away. And spoiled me for life.

This wasn't a problem for the Unix team. The reason the managers imposed that ridiculous "no compiling" rule was, the compiler was slow, taking some four hours per build. The team should have—and could have—figured out a way to compile and unit-test the individual modules, but they didn't. For one reason, their code was not modular; everything depended on everything else. So you couldn't just lift out one function for unit testing, you had to do the whole megillah. The programmers didn't mind though. They could launch a build, then spend the next four hours playing Unix computer games.

I once worked on an assembly-language program, an embedded program. After I'd given the team leader some software, I told him I needed to make a change to it. He said, "Well, you can't do that now. You'll have to wait for the next time we do a build." I asked when that would be. He said, "Two or three weeks."

I go, "Three weeks? Are you kidding me? I'm used to getting new builds in three seconds!" Then and there, I resolved to do my unit testing on my own test drivers and save integration until the very last thing. The idea worked like a charm. During integration, we found only one error, requiring a change in one single byte.

Expect success, I say. Get warm fuzzies often. And don't forget to test.