Picture two kids in the south of the US.  One of them urges the other to commit some sort of dangerous and cool crime, like, say, getting to the top of the barn and jumping into that big pile of hay down on the ground.  The other demurs, “I’m not gonna do that!”.  The one must now invoke the potent magical energy of a double-dog dare:

“I dare ya.”

“Nawwww.”

“I double dare ya.”

“Nope.”

“I double dog dare ya.”

“Welllllll, alright.”

See, I travel around coaching teams in transition, which means I am ever and always ‘the new codeslinger in town’.  Extreme programming has a number of practices that are specifically aimed at the act of coding, which means it’s up to me to work with developers while they get the basics.  A lot of what I do is just code along with them, showing how the XP way of working is more pleasant and productive than theirs.

And here’s the rub: no geek wants to invest in the new codeslinger until it’s been proven that she’s not a bullsh snake oil salesman.  Oh, come on.  I know you’ve done it.  Some so-called expert shows up, and the first thing you have to do is decide whether she knows as much as you.

So what happens? I’ll be working with a bunch of developers, and getting no traction at all. Everyone just nods politely at me, then goes about doing whatever they would normally do.  Then, all of a sudden, everybody hangs on my every word.  What changed? Easy.  I did something technical that they thought qualified me as good enough at geeking to show them something.

Now, my motto is “Fool me once, shame on you. Fool me 387 consecutive times, shame on me.” Which is to say, I gradually realized that I was going to have to demonstrate a gift for geekery for every team, every time.  Once I started looking for it, sure enough, the double dawg dare was obvious at every site.  Some sites have some very advanced standards, others have embarrassingly low standards, but they all have some standard.  I finally just started walking in and saying: “Please take me to the worst class in the system that actually does real work.“  I wanted to get the double-dawg out of my way.

So anyway, I bring this all up for a reason:  I’ve decided I want to offer you a preemptive double-dawg-dare reverse challenge.

Got a java class that is

1. unbearable, and
2. untested, and
3. legal to show the world (anonymously if need be)?

Because that’s what I want. I will wrestle with it, in public, until I have brought it under microtest.

Remember, for this one I’m specifically asking for java only.  (I’m a sucker for Eclipse, and of course, it’s at its best with Java.)  After I get a few entries, I’ll choose one and get started.  Note: I do not need its dependencies, just the source code of the class itself.

I double-dawg dare you to send me a double-dawg dare java file.

(Or are you just a big sissy?)

My rationale for this suggestion is straightforward. Unit test already has a meaning out there in the development world, and that meaning doesn’t match the agile/XP meaning.  There are several aspects of an ordinary microtest that can be entirely absent from a normal unit test.  Traveling around as I do, I get to work with an enormous number of teams, and I can tell you from extensive experience, teaching people about XP style testing is notably easier when we don’t have to repurpose a word that’s already in play.

A microtest has the following properties:

• It is short, typically under a dozen lines of code.
• It is always automated.
• It does not test the object inside the running app, but instead in a purpose-built testing application.
• It invokes only a tiny portion of the code, most usually a single branch of a single function.
• It is written gray-box, i.e. it reads as if it were black-box, but sometimes takes advantage of white-box knowledge.  (Typically a critical factor in avoiding combinatoric issues.)
• It is coded to the same standard as shipping code, i.e. the team’s best current understanding of coding excellence. 
  
• It is vault-committed source, with a lifetime co-terminous with the functionality it tests.
• In combination with all other microtests of an app, it serves as a ‘gateway-to-commit’.  That is, a developer is encouraged to commit anytime all microtests run green, and discouraged (strongly, even nastily) to commit otherwise.
• It takes complete control of the object-under-test and is therefore self-contained, i.e. running with no dependencies on anything other than the testing code and its dependency graph.
• It runs in an extremely short time, milliseconds per test.
  
• It provides precise feedback on any errors that it encounters.
• It usually (not always) runs entirely inside a single computer.
• It usually (not always) runs entirely inside a single process, i.e. with few extra-process runtime dependencies.
• It is part of a collection all or any subset of which is invokable with a single programmer gesture.
• It is written before the code-change it is meant to test.
• It avoids most or all usage of ‘awkward’ collaborators via a variety of slip-and-fake techniques.
• It rarely involves construction of more than a few classes of object, often one or two, usually under five.

Over the years I’ve had some pretty comedic conversations with people.  One fellow was quite irate and insisted that the list above was just the definition of a good unit test.  Maybe microtest just means good unit test.