Christian Kaula. Let the computer do it.

There seems to be a lot of discussion going on about TDD being dead these days. Here's my two cents concerning the matter.

The Source of Errors

In my first programming course my professor said something I still remember vividly:

Compile and run your code early and often. If you don't, you will have a tough time finding your errors.

This describes a very important truth about programing: As a human being you will make mistakes. (Note I am implying you are human here.)

Also you should never forget that we programmer people are standing on the shoulder of giants - very human (mostly not so giant) giants. Those 68 libs you import, written in that language you use, compiled by that compiler for that other language your language is written in, built on top of that OS, for that hardware your computer consists of. All created by loads of the same imperfect human beings as yourself.

Finding the Errors

What did the very first program you wrote do? Probably output "hello world" or something. How did you know it worked? Probably because it showed "hello world". Piece of cake.

I bet soon after that you wrote a program that took some kind of input. Perhaps it took a name and said "hello name". How did you know it worked? You put in your name and expected to see "hello chris". Okay, simple enough.

Perhaps you wrote a little calculator then. Just basic arithmetic. Might be you started with sums. Input "1 + 1" and it returned "2". Great. How about "1 + -1"? Probably had to fix your code for that. Did "1 + 1" still work? "1 − 12 + 3"? "1 − −3"? You probably typed a lot of numbers to check if you got it to work all at once.

At some point you might have asked yourself:

Man, how do those real programmer guys get anything done when they have to test all those possibilities?

Back to the here and now (where you are one of those real programmers, no doubt). How do you know your code works, today? Probably still inputting something and hoping to see something you expected. Today you got the experience and tools to narrow your search down from the get-go. But in the end it's still calling functions and looking at their return values until you found the function that misbehaves.

Be Lazy or Be Busy

To recap: You will produce errors. You will have to find these errors. To know where these errors are you will have to feed stuff into your code and compare output with expected output.

I see three options to deal with it all:

1. Automate your testing and let your computer do the tedious part. That's what computers were invented for.
2. Do loads and loads of manual testing: Check if your new code works as expected. Now check if your code works in combination with all other code it touches. Every time you change something. Anything. No skipping. Hey! I said no skipping!
3. Just don't care if your customers and/or coworkers utter the dreaded "This used to work already" and you have to fix the same error for the third time in five days.