Test First Programming – It is kind of like Martial Arts…

November 21, 2012

Test-Driven-Development/Design (TDD) has been a hot topic of conversation in our office recently (lots of external and internal training about TDD).

I think the biggest* “ah, ha”* for me, throughout these conversations, was that TDD is nothing more than a tool.  A very powerful tool that has numerous benefits.
TDD is not, however, some silver bullet that makes me write perfect code.

But that’s not really what this post is about.  This post is about Test First Programming…and martial arts.

(Spoiler, it’s not really about martial arts.)

There are many ways to practice Test First programming – Test-Driven-Development, Read-Eval-Print-Loop (REPL), Type-First-Development, and more.

But even within those categories of Test First programming, there are sub categories.  Much like there are numerous types and styles of martial arts.
For example, I am happy to say that I practice TDD.

But that is a lot like saying that I practice Karate.  There are many flavors of Karate…is it Japanese, American, Okinawan, or some other derived version of karate that is similar to (but not the same as) “Karate” proper.

Further, each approach to practicing Test First programming has its own strengths and weaknesses.  So, if I said that TDD > REPL > Type-First…that would be like me saying that Jiu-Jitsu > Fencing > Drunken-Boxing.

It just don’t make no sense, man.

In martial arts, you pick your style based on your strengths/weaknesses, your opponents strengths/weaknesses, and your current objective/goal (self defense, submission, offense, etc.).
The same is true for the tool that you choose to use in order to take a Test First approach to your programming.

Like the different styles of martial arts, the different approaches to Test First (and even the different flavors of TDD) are there so that you can cater your practices to your context, language, or your environment that you are currently living in.
For example, some of the low-level approaches that I’m taking within my embedded-C TDD adventure, wouldn’t make sense when I’m coding up my next iOS application. (I don’t think Unity/Cmock and Storyboards will play nicely together.)

At the end of the day, it is important that you remember to pick the tool(s) that best suits you and your current adventure.
Just as important, though, is that you also understand that your peers may find different tools more useful given their current adventure.

I want to end this post (and/or rant) with a quote that my good friend Brian Ball shared with me once upon a time:

“You should not have any special fondness for a particular weapon, or anything else, for that matter. Too much is the same as not enough. Without imitating anyone else, you should have as much weaponry as suits you.”
― Miyamoto MusashiThe Book Of Five Rings