The Problem with Test Driven Development

Unit testing fanatics might find the content of this post disturbing. I’m going to point out a fundamental problem with the TDD approach, and I’m not one to just point out problems, so I also offer a solution.

TDD fanatics often wonder aloud why the weary masses have not thrown off the shackles of hack and slash coding, why they have not come running to the glow of green lights and the feeling of confidence the lights imbue. The merits of TDD are so obvious, the fanatics think, that any software developer should instantly evolve into an enlightened one – a test driven developer. Yet, many are left unconverted.

The adoption of TDD is hampered by a glaring problem. The problem begins in the opening description of the methodology, which typically sounds like the following.

The first step is to quickly add a test, basically just enough code to fail.

Do you see the problem?

Let’s take another example. Here is a shot of the NUnit status bar after test execution.

There is the problem again – do you see it yet?

The problem is no ambitious person will wake up in the morning, walk into the shower, and plan ahead for a day of failure. If they did, they wouldn’t be getting into the shower. People who think that way stay lying in bed, daydreaming about the beach and seeing other people in their wet cotton swimwear. Nobody wants to start with a failure.

The word fail is a dirty, dirty word.

You know what we do with dirty, dirty words, don’t you?

We shun dirty, dirty words. We replace them. We turn them into gentle, obfuscated phrases.

Euphemisms In Software Development

As software developers, we are familiar with many euphemisms. For example, instead of saying software has “defects”, we say software has “issues”. Nowadays, no self respecting company will wait until V 1.0 to release a product. A beta release is as good as gold - it just has a some “issues” is all.  

Likewise, AJAX is a new euphemism for “I wish this wasn’t a browser based application”. The A in AJAX stands for asynchronous. Asychronicity sells - not that asynchronicity is a real word, but it sounds sexy and could be the title of a hip dance song.

I could go on and on with these examples, but I hope you, as the reader, have seen the solution I am driving towards.

Failure Is Not An Option

At this time I’m going to borrow an idea from the British education system – the idea of “deferred success”. Instead of saying that a child has “failed” a class, British schoolteachers want to say the child has merely “deferred success”. The word “fail” could scare a child away from future education. A brilliant idea from you bloody Brits.

Let’s apply the concept of deferred success to test driven development.

The first step is to quickly add a test, basically just enough code to defer success.

Doesn’t that statement make you feel success is just around the corner? Why, the word success even appears at the end of the sentence! No nasty f*** words are jumping off the screen, filling developers with a sense of fear and foreboding.

Even NUnit looks better after two changes to StatusBar.cs and a recompile. I need to get in touch with the PM for Team System unit testing ASAP.

Now the choice is up to the test driven development community. They can continue to force failure after failure on software developers, or they can choose the kindler, gentler path to test driven development.

I hope my posting will not defer it’s success in convincing them to make the right choice.