Musings in real time

Tags - Categories : All | Art | Books | Family | Hacks | Java | JavaRanch | Linux | Philosophy

Do you ever write Coyote tests? It doesn't happen to me that often, but when it does, it can be painful.

In the old cartoons, Wile E. Coyote never did catch that Road Runner. Every episode, he'd build a series of increasingly complicated traps, and every trap would fail, usually blowing up in his face, launching him off a cliff, crushing him under an anvil, or otherwise sending him to the ER (where perhaps Noah Wyle would treat him.)

The funniest vignettes for me were the ones where the trap wouldn't "spring", so Mr. Coyote would climb onto (say) the grass mat covering the pit of Gila monsters and jump up and down until, predictably, it collapsed and he ended up with a nasty case of Salmonellosis. This is a "Coyote Test" -- a test that can't pass without exposing you to painful lizard bites.

You can do this in software, too. Mostly these happen when you're not thinking clearly -- just as the Coyote jumps on the trap in the heat of the moment, you, as a developer, are sometimes so wrapped up in what you're doing that you forget all about the Gila Monsters in the pit.

Here's a great way to do a Coyote Test: When writing unit tests, you may feel you need to add "test probe" methods to your classes, to grant access that a test needs, but other classes shouldn't touch. You might feel guilty enough about exposing private details that you put an assertion into the method that it should only be invoked during a test run. Then you can define an environment variable like TESTING, and your check can throw an exception if TESTING isn't true.

This turns out to be a great Coyote Test! If you use a test probe method from non-test code, then the application will blow up in the user's face, but work fine during tests!

Here's another one: this is one I wrote myself a few days ago. Say you need your Java software to run on JDK version 1.4 and up, and exit politely on earlier versions. Java provides a system property (similar to an environment variable) that tells you the Java specification version. It generally starts with a JDK version number (1.1, 1.3, 1.5) but can contain other stuff ("1.3 RC2 Blackdown" is one example I've seen.) Since we need to run only under Java 1.4 and up, we can use a regular expression, right? So we match against "^1\\.[4-9]" to run under 1.4 and the next few releases. If we don't get a match, then we exit nicely. This works fine under 1.4 and 1.5, but what happens under 1.3?

That's right -- it's a Coyote Test! Under JDK 1.3, there is no java.util.regexp package, so we crash with a ClassNotFoundException, and don't get a chance to explain why. Of course you can catch the exception and report a failure, but then it's not a Coyote Test anymore, is it -- that would spoil the fun!

Zachary at 22 months is terribly excited about everything. He's thrilled to be able to ask for things by name. He's thrilled to be able to run like the wind. He's thrilled to be able to throw balls and have them go where he wants. And this week, he's been thrilled by bubbles. "Bubbles, bubbles" he says, so we we take down the bottle of soap bubbles and we blow bubbles together for a while.

At bath time tonight, I thought I'd give him a special treat, something he's never seen before. "Bubble bath!" I told him. "Bath bubble!" he said. "Bath bubble! Bath bubble!" So we put the bubble bath into the bathtub. As the foam rises, he watches from outside the tub and says "No, nooooo!" When I put him into the tub, he won't sit down. He's very unhappy that his toys can't be seen underneath the foam. "Animals, animals!" he cries, plaintively. He usually loves his bath but tonight he couldn't get out fast enough.

So I learned something I didn't know about the Zacharean philosophy. Whereas soap bubbles you blow yourself are righteous and true, bubble-bath bubbles are Beelzebubbles, the work of Satan himself!