Why I Do TDD Even For Throwaway Prototypes

TDD is all about speeding up the development of software apps

It always seems like an uphill battle whenever I get hired to instruct software development teams to adopt the Test Driven Development practice (TDD). People usually dig their heels in and work real hard to find all kinds of reasons why they should not try TDD. I get it, people hate change. Especially if they don’t see any reason for improving.

However, every now and then I luck out and manage to not only lead the horse to the water, but also make it drink. Those are precious victories, that deservedly need to be celebrated. Still, I often find that even teams who manage to make the transition from hand-cranking code to doing it by following the TDD practice, still for some reason insist that TDD is only needed when crafting production worthy code. What do they mean by that? Well, oftentimes we are asked to cobble up a quick prototype, a trial balloon that will help stakeholders kick the tires, drive the new app around the proverbial block to see if it makes sense to continue in the envisioned direction.

Nothing wrong with that, of course. Why foolishly jump head first into committing to all kinds of expenses associated with crafting a well designed, well engineered product, if it may turn out that the product is a blind alley?

So, with that in mind, we eagerly jump into cobbling up our quick-and-dirty prototype, or trial balloon. And because we know that regardless of whether that prototype is going to be deemed a success or something to be abandoned, it will inevitably be thrown out, which is why we do everything without writing any tests. Now, because we’re working on something that is by its very nature disposable, we naturally feel that there is no need to invest any effort into making it properly crafted/properly tested. And because we’ve learned that the best way to properly craft software is to develop it the TDD way, we jump to the conclusion that in this case, we should skip TDD.

But that’s a big mistake! I never skip TDD, even if I’m cobbling up some quick-and-dirty throwaway app. What is my reason for sticking with TDD?

I do it because one of the best features of TDD is that it speeds up the development. And because a quick-and-dirty throwaway app should be done in the fastest possible way, what other reason should one need for doing it the TDD way?

Some people act surprised when I say that TDD is speeding up the development of software. They think that because when doing TDD we are writing tests IN ADDITION to also writing the code, that additional effort means we are spending more time than necessary. Ergo, TDD is slowing us down.

But that’s false math. Let’s look at how much is TDD process saving time:

By writing a failing test first, I enable my development process to avoid any manual chores. Instead of manually compiling, building, running the app, then logging in, navigating to the place where I need to manually type some test data, I simply automate the development process to run the tests each time I make a change. The tests will automatically and instantly tell me if my change behaves as expected, or not. If we factor in how much time is wasted on the above manual chores, we will see that the time spent on writing a test is probably merely one hundredth (if not one thousandth) of time it takes, on average, to verify that the app behaves we expect it to behave after we made a change.

So, knowing that, does it now make sense to stick to TDD even when writing quick-and-dirty throwaway apps? Hit me up in the comments with your counter-arguments. I know many of you are eager to show how TDD is a hoax hoisted upon innocent development community, so now’s your chance to prove me wrong!