Feed on
Posts
Comments
(This series starts here.)

Take a look at this sweet little snippet:

public void longFunction(int index)
{
	int currentMaxIndex;
	// ... some tricky preparation stuff before we
	//     can even de-ref index
	//     among other things, setting currentMaxIndex to a 
	//     positive integer.
	if(index < 0 && index > currentMaxIndex)
	{
		// ... log the condition
		// ... undo all the prep
		// ... get outta here
		return;
	}
	// ... otherwise do cool things with the
	//     de-reffed index
}

That There, Kids, Is A Bug. They’re Good Eatin’

But we can say a little more than just that:

It’s not a typo: the majority of typos are caught by a compiler because they’re mis-spellings, but this one creates a legal word. In fact, it’s a legal word even in this very narrow context.

It’s not a misunderstood requirement: I think we can say with some confidence that the product owner has not told the developer to implement “an un-enterable state of computation”.

It’s not a noob issue: by the time one gets around to learning &&, one has pretty much also learned ||. They kinda go together.

It’s not a brilliant bug caused by the staggering complexity of this high-performance multi-threaded rocket-science domain: which is what my victim teams always claim are the only kind of bugs they get, so microtests won’t help them. (Sorry, do I sound bitter?)

Code/Coder Mismatches

That bug is a simple code/coder mismatch. I call these babies ‘mismatches’ for short:

The coder thought the typing said one thing,

but the code thought the typing said another.

The code is trivially wrong. That’s actually a requirement for mismatches. If it’s not obviously the wrong thing, then we’re moving into the rocket science excuse. (After all, there are no defects that aren’t caused by the code and the programmer disagreeing about what the code does.)

The overwhelming majority of fielded defects are mismatches like these. Off-by-one errors, inverted logic, wrong order of parameters, forgotten conditionals, and so on.

Driven Code Can’t Mismatch

In the TDD world, huge swathes of mismatches are caught instantly, before they even approach QA, let alone the actual field.

The only reason the branch displayed above exists at all, in TDD terms, is because some microtest forced it to be created.

See, it is interesting to us if some chunk of code has behavior that’s different in one combination of parameters than it is in another. In this case, the complexity of the failure case lends even more interest to us.

And what would that microtest do? It would pass a -1 index. The branch would not get exercised, and the assertions in the microtest would fail.

A Part Of TDD’s Magic Is That

TDD Sidesteps Mismatch Bugs

Leave a Reply

AWSOM Powered