I just read this blog entry, from one of my favorite authors:
TDD- It's Not About Testing... Except When It Is
That pretty much sums it up.
What kind of self-referential crap is that? Check your pipe for residue....
No, really. Here is the anecdote.
I was heavily refactoring some "serial port" code, and I was paying close attention to the section of code responsible for filling the input buffer and watching for the "line terminator" character, which signals a complete "message".
I immediately got concerned about off-by-one and buffer-overrun situations, e.g. what if my input buffer was shorter than my longest possible incoming packet? Did things fail properly?
You and your fail correctly crap....
As I say, anyone can code for success; it takes skill to code correctly for failure.
The astute reader knows exactly what happened next, but for the sake of the rest of you, I will continue the story.
First, the buffer length was refactored such that it could be configured. Next, a test case was established that set the buffer size to less than the size of the expected message. Next, run the test and adjust expectations accordingly.
How utterly boring and predictable. Were you able to adjust?
Certainly. Needless to say, fears were confirmed; some minor tweaking was necessary to cover the smaller-than and equal-to cases.
I can sleep easily now.
No comments:
Post a Comment