When Not To Use TDD?

Some time ago we talked about 7 reasons to start using Test Driven Development. As soon as you learn it and start practicing it on a daily basis, it might be tempting to always be TDDing. However, TDD is not always a good fit. There are some cases when it might not be worth using TDD. Let’s explore them today ?

Prototypes

You may consider not doing TDD with prototypes. By prototype, I mean an app that will most probably be thrown away or completely changed very soon. It may be created when you are experimenting with some technology/framework or are just asked to conduct research on something.

TDD gives you a high code/flow coverage, which may need to be changed in case of prototype projects. If you are in such situation, consider resigning from TDD at this stage.

Short living apps

Similarly to prototypes, short living solutions might be the ones where TDD is not the best fit. It applies to one-time-use apps or scripts which are supposed to do one thing well and quickly.

Short living apps are the ones where you may consider not using Test Driven Development. I’d even argue whether you need any kind of tests for such programs. Testing such apps or even scripts may be art for art’s sake. If something is supposed to realize a given task without fireworks (like reusability, maintenance etc.), I wouldn’t bother with testing it. It’s better to focus on solving your current, short-lived problem than on practicing the profound TDD idea ?

Unclear requirements

One of the reasons not to use TDD might be unclear requirements. The idea of writing tests in Test Driven Development is to define the expected outcomes for predefined incomes. As we said in the previous article, Test Driven Development can help spot the edge cases and make the business requirements more close to the code. However, if you don’t have these requirements defined, TDD might be a waste of time (at this stage). If the requirements actually arrive or are completely changed, your significant set of tests will need to be changed or even removed.

MVP

If you’re creating an MVP, with very short time and budget, TDD might not be worth the struggle. It’s probably better to resign from using TDD in that case. You should rather focus on your product and the business value it needs to deliver. TDD might slow down the delivery time, which, in case of MVPs, can be critical. It’s better to deliver the minimum viable product without TDD than to not deliver it with TDD ?

However, remember to add some tests, even post-factum. MVPs have a high chance of survival, so you’d want your final product to be tested and testable. You need to find a good balance here, not to make your solution completely untestable when it’s ready for production use.

Tests writing beginner

If you are a total beginner in writing tests in general, Test Driven Development might not be the best approach to start with. You may consider not to use TDD at the beginning of your testing journey.

To make Test Driven Development effective, you should be able to write tests quickly and efficiently. Starting to learn software testing with Test Driven Development may make you feel overwhelmed and discouraged. If you’re a beginner, I suggest to first write some unit tests, get familiar with that and then try to learn Test Driven Development.

It would be great if you can find some smaller and well-defined task to start with TDD. If you don’t have such tasks, try solving one of the programming katas (e.g. this one) with TDD.