Because then, when you step away from it, you’ll find, “Well now. I did never consider that this would be something in the cookie on the user’s machine” or this or that or some other factor that comes into play that you might not have thought of.
Ed: Since you are one of the pioneers and leading proponents of Agile software development practices, let’s talk a bit about test-driven development. Specifically, how do you deal with bugs in the tests and the time it takes to debug the bugs in the tests? Some of the Agile detractors will point that out and say the test code is just as likely to be buggy as the production code.
Andy: Yeah, there are folks [who] say that. I don’t really buy that as an argument. Certainly from a philosophical point of view, that’s true.
You know, code is code, and you can write bugs in test code just as easily as you can write bugs in normal code. However, test code by nature tends to be pretty simple stuff. You’re setting up some parameters and you’re calling something, and it’s not rocket science. I can make a typo in “hello world.” I’m not throwing stones here. I can certainly introduce bugs in the simplest of circumstances, as can everyone. But on the whole, properly written test code is not some big monstrous morass that’s hard to figure out. It’s very simple, small methods, four or five lines of code each. Pretty easy to take a look at and say, “Yes, this is reasonable,” or, “Yeah, it’s a little bit suspicious.” On the one hand, I don’t buy [their argument], but on the other hand, you’ve got a nice validation mechanism. If you are suspicious of your test code, it’s pretty easy to go in and deliberately introduce bugs into the real code and make sure that the test code catches them.
I don’t really buy their argument. The parallel argument is, “It takes a lot of time to write the test code.” [Is equally specious.] No [it doesn’t]. It’s like an investment strategy. You’re spending an incremental amount of time to write test code, but if you get nailed with a hard bug, it may be exponential time to solve it.
It’s really kind of a false argument. They only say that because it’s easier to measure the amount of time that you’re spending on test code.
Ed: Is it ever appropriate to not write tests?
Andy: It depends. There have been lots of times where I’ve done test-driven design, test-first design, and it’s saved my bacon. I’ve had some times where that’s been less appropriate, where it’s something more exploratory and I’ll go more bottom-up. You know, develop something first, kind of play with it, and then quantify the unit test and work from there. As with most things, the real danger is dogmatism where “this is my hammer and everything looks like a nail.”