I recently had an e-piphiny.
See the post title.
In reality, I’ve little experience with test-driven development. But I recently had a tryst with it which swayed me.
For the non-technical audience, what a unit test does is simple: it provides a mechanism to test previously written computer code for correctness. For example, lets say that a programmer writes some code to perform addition multiplication (yes, this is horribly simplified).
(Edit 1/14/08: Wow. i r smrt at maths)
This opens up the program for all sorts of havoc. As an example, imagine if the multiplication action was written incorrectly. That means that any part of the program that relies on being able to use that multiplication function will, in turn, fail, causing the whole program to fail.
Obviously bad.
The phenomenon of unit testing provides a way for programmers to test their code beforehand by creating small “tests” of the functions. In the example given, one could provide the numbers “2” and “3” to the function, and if the function did not provide “6” as an answer, the test would fail, and save the developer tons of time trying to track down the source of the error.
I bring this up because, that is precisely what happened to me a few days ago.
Picture it: a cubicle in corporate America, 2007.
A young developer, bored, for corporate America cannot provide enough mental stimulation, sets out to understand the unit test.
I’ve been interested in how unit testing worked, mainly because I heard of it’s benefits long before I understood the concept. I’ve recently had “free time,” (another blog entry for another time) that allowed me to explore this topic by applying it to code I was myself, writing.Thus, I created an unit test to verify a functionality that I was adding. Just to see how it would work.
During the addition, I added in some computer instructions to help me understand how the code was working. While it was helpful in the writing process, it broke all ability for the function to work in a universal fashion. It was only meant to be temporary, but, of course, I forgot to remove it.
Oops.
The unit test suddenly said, “No. No! We do that outside!”
I was confused and sad.
But it lead me directly to the problem: I left code behind that needed to be removed.
I failed.
However, I suddenly realized that, having this test saved me at least two hours worth of time trying to track down the exact source of the problem. In fact, it was able to tell me exactly where the problem existed.
Suddenly I was made of win.
Considering it took me twentyish minutes to write the test that saved me two hours of sleuthing time, I called shenanigans on old development techniques on the order of of one hour and forty minutes of saved time.
Now, consider that most software contains hundreds, if not thousands of these functions that could fail.
Imagine saving one thousand occurences of one hour and forty minutes of debugging time.
Imagine all the people, living life in pea…eiii~iihe~eeace.
Sadly, it won’t go into my vacation time account.
At least not directly.
…
I wonder if I can write a unit test for that…