Quoting myself, “Then, as I do the work for real, it gives me an acid test to know if I’m on the right track. In other words, does the software now work as advertised? A side benefit of this end-first exercise is that it often reveals latent issues and questions for which I have no answers. It also helps me to enumerate any assumptions that I’ve been making, which perhaps ought to be validated.”

This is a very much akin to Test-First Development (a.k.a. Test-Driven Development, or TDD for short), of which I am a huge proponent. I’d almost say that what I described above is a poor man’s version of TDD, except that there is no cost to doing TDD. Unit testing tools are free for the asking.

TDD has become as automatic for me as breathing. It’s a beautiful thing when you get to start a new project from scratch and can write every line of code test-first. These days, however, I’m working on a legacy app with very little in the way of unit tests, and it feels as if I’m working at 5,000 meters above sea level and struggling for every breath of rarefied atmosphere.

So I can only imagine how it seems to the rest of my team, for whom automated unit testing is a new concept. The level of drudgery involved in retrofitting a legacy app with a test harness rivals the chore of waxing Mr. Miyagi’s deck. All I can tell my teammates is that it’s good practice. Soon, writing unit tests becomes a habit, and then, eventually, it becomes pure instinct. Attack from the right? Wax On! Attack from the left? Wax Off! Add a new feature? HTTP-Unit! Change a business rule? JUnit! Keep it up, and that black belt will arrive in no time.