Test Suites as Quality Diodes

Larry O'Brien recently wrote a a post about relative sizes of tests vs. the code they exercise wherein he mentions an interesting concept: tests as quality diodes. For those of you who've forgotten how diodes worked, or never learned in the first place (lucky you), here's a decent introduction to diodes.

The immediate point of the metaphor was obvious - code that passes tests is quality, code that fails tests is not. But once upon a time, I was expected to know about the inner workings of diodes (thanks, ECE 3040), so I've taken the metaphor and run with it. To start with, I'll be comparing entire test suites to a single diode.

Warning: The following paragraphs contain scenes of graphic metaphor-stretching. A metaphor may have been harmed in the writing of this post.

One of the distinguishing characteristics of diodes is known as peak inverse voltage. If the voltage across a diode is going the wrong direction (a situation called reverse bias) and exceeds the diode's peak inverse voltage, then you get an unpleasant effect known as avalanching. This is pretty similar to what happens when you try to slap a test suite on a lot of traditional applications. Test suites are traditionally expected to be passing most of the time, and the code they exercise is supposed to be more good than bad (or it wouldn't be passing the tests most of the time). If instead you have more bad code than good, you've reverse-biased your quality diode. If there is pressure to get this dev-task done and get back to work—after all, it's not like you're adding a feature to the product—then you may have just exceeded your test suite's peak inverse voltage. The resulting avalanching tends to gut your test suite, either because you stop running it (you already know it will have failures) or because you throw it out entirely (why maintain code that isn't doing anything for us).

What should we do about a situation like this? In the world of electronics, one solution is the Zener diode. Instead of avalanching, it breaks down in a more controlled fashion, though it usually does so at much lower inverse voltages. We'd like our test suite to exhibit this same resistance to avalanching—a Zener test suite, so to speak.

One way to build a Zener test suite would be to reduce your test coverage. Sure, the first casualty will likely be the code that needs the most help, but some test coverage is better than none, and none is what you wind up with if your test suite starts avalanching. Once you have your Zener test suite in place, you can work on transforming it into a more traditional test suite by slowly increasing the coverage. That's not entirely accurate, though: if you do it right, your test suite will grow to have the benefits of the classic test suite while retaining the resistance to avalanching of the Zener test suite, and that's our real goal.

Back to flipping out...

CSV from Oracle

Ever wanted to dump data out of Oracle and into a CSV? Perhaps you needed to export some info to QA or create a chart. Have no fear, there's a surprisingly straightforward way to do it. I know: Oracle and straightforward don't appear in the same sentence often, but in this case it really is simple. Just use set colsep , and you're in business.

Back to flipping out...

Sneak Attack: Ninja Patching—Because Monkeys Just Aren't Stealthy Enough

Back to flipping out...

How do you counter an Acid(3 test)? With a Base(3 test)

Lately, the WebKit and Opera devs have been racing to see who can make their browser pass the Acid3 test first, or at least be the first to get 100/100 (for more details on why this is not the same thing, please visit the earlier Wikipedia link). Notably absent from this entertaining contest was Firefox. If you're saying "Hold on! They're probably just trying to get Firefox 3 out the door," you're right... sort of. While that is supposedly the main argument put forward by shaver in his recent blog post on Acid3, it takes less than 2 paragraphs to completely exhaust that idea and 7 (mostly massive) paragraphs to bag on the Acid3 test for focusing on the wrong things. Meanwhile, Rob Sayre dismisses the test in his blog post on the subject without even offering the excuse (which I believe is totally valid) that Firefox 3 is the top priority. So, since it seems to be the consensus among Firefox devs that Acid3 focused on the wrong things, why don't they publish a test that they think focuses on the right things? Dan_Farina over at the programming subreddit suggested this "Base3" test and I think he's right.

Back to flipping out...

Sneak Attack: More Performance Tips from YAHOO!

Back to flipping out...

C/C++ Programmers

Thanks for suffering so I don't have to. - paulzork said it on the programming subreddit about C/C++ programmers, and I don't think I've ever seen a better summary of my feelings for C programmers.

Back to flipping out...

JavaScript Idioms - Copying an array

Ever see a block of JavaScript that looks like this?

var myArray = [];
for (var i = 0; i < source.length; i++) {
    myArray[i] = source[i];
}

That's the popular way to copy the elements of one array (note the lack of capitalization) into a new Array (note the capitalization - we'll get to this in a minute). I wasn't really a fan, at first, but it's almost as pervasive as

while(*dst++ = *src++);

in C, so eventually I decided to stop worrying and love the bomb. Basically, JavaScript will automatically grow your Array for you, so you can dispense with all the sizing you might expect when using something called an Array.

Now for the notes you took on capitalization. Not everything that acts like an array in JavaScript is actually an Array. One example is the arguments property available to Functions. If you happen to need the stuff in arguments as an actual Array (because you want to use it as a key for a map/dictionary/hash, let's say), you will find yourself writing some code like that above. Just remember that sometimes stuff is "Array-like" without actually being an Array, because it can really bite you if you're not careful.

Back to flipping out...