Please, Just Test Something, Okay?
At my job we encourage people to use Test Driven Development (TDD). The short explanation of that is that before you write a line of program code, write a test for what it is supposed to do. I confess I don’t always adhere to this. For me the rule would be more like, test early and test often. Testing is a skill and it can be hard. Testing first is also a skill. Like any skill it takes time to learn (and I’m getting better at it all the time!).
For years now, though, I’ve found that even my sloppy and less-than-perfectly skilled approach to testing seems to be too much effort for some people. At a previous job I routinely heard other people complaining that some system/server/software was broken when, in fact, their own code (or configuration or approach or whatever) was really broken. My colleagues and I would say something like, “Did you try it from a different computer?” And, as often as not, when tried on a different computer it worked fine. Reboot and try again. Don’t place blame before you’ve gathered the relevant information. Thank you kindly, call again soon.
See? It’s not just programming. Programming is just an environment where testing is measurable and has well developed tools.
There’s another idea behind testing that shows clearly when you write automated (therefore repeatable) tests for your code. It forces you to figure out your assumptions ahead of time. Often, you quickly realize you should consider other possibilities. What if the incoming number is 0 (zero, null, nothing, empty set) instead of what you expect? Dividing by it would be bad. That’s the fun thing about tests (at least if you have a mind like mine); I often write 3 or 4 tests for a function – 1 or 2 for the way it’s supposed to work, and a couple more to see if I can break it. You see, end users rarely understand the difference between good data and bad data. And even if they do, sometimes a cat walks on the keyboard (go away Kilroy! – that’s my cat) and inputs something you didn’t intend. So you have to anticipate these things.
But, as I said, testing applies to a lot more than just programming, as my “reboot” example above should show. I’ve been known to bring the philosophy of testing everything to areas that have nothing to do with computers. Think about it: You hear about a new TV show (let’s call it Dollplace just as a hypothetical example). You know the history of some of the people involved and you believe it will probably be a good show. But do you immediately start a fan club? No! You watch the show for a while first (and see an okay but dull pilot followed by a better episode that hints at improvements but still isn’t up to the level you want to see from such talented people).
In other words, you test the show.
Rumors are something people rarely test and should. Heard a rumor that your old friend (hypothetically) Eliza has been in training to be a ninja? Well, she has done martial arts before. It’s plausible. But there’s no need to decide right away if you believe it or not. Why not call her on the phone and ask? You might find out that it’s just for a (so far, mediocre) TV show and has nothing to do with actually being a ninja.
I also believe in testing whether the dog will like a particular brand of food, whether the car will get better mileage with a new kind of gas and even whether or not a politician supports policies he says he supports, even if he sounds sincere when he says it (Voting records are much more reliable indicators of belief than talking points). And all sorts of other things. Maybe that’s why I took to TDD in the first place. The logic seems a natural fit to me.
Testing is how we know, as opposed to just thinking we do. When someone tells you the network is down, you don’t instantly rush off and call Al Gore to complain. There are many possible points of failure for an internet connection. It could be your computer’s network card. It could be your router. It could be your computer isn’t even turned on. It could be a bad cable. So first, you run a test. Go to a different computer and see if you can get to the Internet. Can’t? Check your router. And so on. TEST possible causes before making a decision.
We don’t know how to test everything. If I suspect I have some rare tropical disease (apparently one that causes its victims to type maniacally), I call the doctor. And the doctor runs tests. Why would he do that when the web site raretropicaldiseasesyoumighthave.com says I have it? Because he wants to know, not just accept a rumor. Is that such a hard concept?
There were several things that inspired today’s testing rant. One was a workplace discussion with someone who is incredibly smart but who isn’t an extremely experienced programmer. I was singing the virtues of Test Driven Development – even if I’m not the greatest at it, promoting it is part of my job – and she was resisting. Basically, to someone who does not have the habit of thinking in terms of tests, the idea of testing code before it’s even written seemed silly. Like many programmers (not just beginners), she believed that running the code once in a while to see what it turned out would be test enough.
Maybe she doesn’t own a cat. I’ll have to ask.
(Note: She was not against using automated tests and I was able to get her to see that you should test small blocks of code as you write them, so as to catch errors before they get hidden in miles of spaghetti. It was the test FIRST thing she never quite got. I take progress where I can get it. My own testing has a way to go too.)
Another one of today’s inspirations was this video: Luke Francl Explains Why Testing Is Overrated.
He says, in essence, testing is only part of the equation and we shouldn’t rely too heavily on it, especially not to the exclusion of other important tools for ensuring code quality. He even concedes that there may be more than one way to write good code, so his views should not be taken as gospel (for more on his views, check out his blog post on the subject here: Maybe there’s more than one way to develop good software?). Every word is completely true. But I get the feeling that it’s been a long time since he’s had to convince someone that testing at all would be a great improvement. Note that in that last sentence by “testing” I mean writing test code that you can run repeatedly and, if the code still works, always get the same result. I don’t mean opening a web page up in your browser and saying, “Yup. Looks good to me.”
“Looks good to me” worked great for the developer of the Edsel, didn’t it? I mean the car. I’m not talking about some program that used that for its name (Because there probably is one. All the good names get recycled. )
Another part of the inspiration for ranting about testing was that I was working on my wife’s website (I do that once in a while, really I do) and needed a little information about a minor point of syntax. So I googled for it and quickly found what I needed. But here’s the thing: Out of maybe a half dozen blog posts I looked at that claimed to be tutorials NOT ONE showed how to test the technique being taught. I’ve found that’s the norm. Sometimes there’s a little blurb that says something like, “Of course in real production code, you would have tests, too.”
How would you like to see that in a tutorial on driving a car, or gardening? “Of course, in a production garden you would use water.” Really? How much? How often? Does it matter if it’s a little bit yellow?
How about doing your taxes? “In a real tax form you would also fill out schedule C for your home business.” Thanks. That’s good to know. Now how do I do it? And does it matter if I leave it out because there were no instructions? I’m sure the IRS will understand. It’s not like the numbers need to add up or anything.
How about a hydroelectric dam? In a real dam, you would use strength numbers from the actual materials used and calculate stresses for a range of volumes of water since, you know, it might rain someday. But explaining how to do that is beyond the scope of this blog post.
Testing. I’d say it’s not just for programmers – if I could get more programmers to do it.
Never mind me. I’m just ranting.
LinkedIn
Technorati Favorites