On Thursday I came up with this cheese ball interpretation of Unit Testing.
So here’s the thing, Ninjas are freaking awesome. If you aren’t aware of how amazing they are, go read up so you’ll know just how amazing they are. Unit tests are like ninjas. They sneak around in the seedy underbelly of a large software project. When things aren’t working, the ninja leaps out of his Test Suite hiding place and slices the green bar into little tiny chunks, that bleed red everywhere.
The samurai are the faithful warriors that go do useful stuff. The samurai have a strict code of conduct, a complex balance of responsibilities and obligations. Perhaps this Is true of everyone, but I really like the title “Ninjas VS Samurai”, so that’s what I’m sticking with.
The point is, A program is like a samurai. It’s got to go do useful stuff. It’s got to protect people, ward off invading armies, pretty much whatever is demanded of it. But, there are these complex rules and obligations that the samurai must uphold. Breaking these rules will endanger all of society, the foreign armies will attack and everything will be lost. Lucky for the samurai, upholding their obligations protects them from the ninjas. The ninjas only attack the samurai who fail.
No samurai, no software. No ninjas, corrupt samurai, bad software. Samurai + Ninjas = great software.
There should be no space between the software and the unit tests. Like a tango, the tests push the software In the right direction. The software pushes the tests to define API’s and performance. Like playing poker. If you push too hard, you loose. If you don’t push hard enough, you loose. You must be in balance with the table, push as hard as you need to, but no harder. The tests must push the software as hard as they need to, but no harder.
Lots of people believe in unit tests, and lots don’t. I’ve drunk the kool-aid so I’m a believer. I think this is one of the areas where the art of programing definitely comes into play. Too many tests, or testing the wrong thing, and the tests become brittle. They begin to depend on a particular implementation. Not enough testing and the software is soft, and full of bugs.
Another great metaphor would be a sword. The metal must hold and edge therefore be hard, but still be soft, so it doesn’t shatter on impact. The trick of making a sword is like the trick of writing good tests. A hard edge for cutting out bugs, but still flexible enough not to become brittle.