4 reasons why TDD slows you down

TDD slows you down. I know it does. It was slowing me down too. Don’t you think that it is normal at the beginning of doing something new? The problem is, in case of TDD, the beginning lasts for a few months. So what exactly slows you down?


Not enough practice

The obvious reason. It is not sufficient to read Uncle Bob’s book and a few articles. You need to practice at work or while working on side projects. Practicing on toy examples is good on the first day, later it is just a waste of your time.

I know, you don’t have time. You are probably reading this blog post on your mobile phone while waiting for something or someone. If you need more time, make some time. There are millions of articles about time management. You can read one or two while standing in a line.

There is one good excuse. You can tell that you prefer to spend time with your children. That is awesome. Would you like to become their role model? Now you can not only nag them to read a book or do their homework, but also show them that you do it: “Learning is important, even adults learn every day!”

Short attention span

You start implementing something and think that it is a good opportunity to practice TDD. You think about the first test. Then you write your first failing test. Write a little bit of code, run the test, see that it passes. After that you refactor something and… what should you do now?

Do you even remember? Now you have to switch back and forth between your code, tests, and task description. Do you know which test you should write right now? No?

Make a list of all the tests you need before you start writing. Yes, you are actually going to plan something. You can even thing about design. Yes, it is allowed.

You can paste the list of necessary tests into you code as a comment. Please remember about removing it after you finish. If you think you need an additional test, add it to the list. Just keep everything in one place.

You misunderstood the word “unit”

Every time we speak about TDD someone mentions unit tests. If you think that an unit test is a tests which verifies one method or a function, do not even start test driven development. it will slow you down.

When you write tests for every function/method you probably stub/mock every dependency. What is going to happen when you want to refactor your code? You need to change many tests! It will take a lot of time and you will scream about tests slowing you down!

Let me make a bold statement: every time you stub/mock code which is not used to communicate with an external dependency (database, REST service, file system, etc.) you are doing something wrong.

Your tests should test the observable behavior, the expected result, the fact that something has been stored in the database or a message has been sent.

It is not fun

You know what is not fun? Receiving the same bug report four times. Spending three hours debugging 43 if-else statements in a very, very long file (a true and utterly sad story).

Sometimes failure is part of the fun. You try something, fail, try again, fail, learn something new, try a dozen of times. Occasionally, I can enjoy failure, but at the end of the day I don’t want to be depressed because I haven’t finished any of my tasks.

In fact, when you are proficient in TDD it becomes fun. It is like checking off items on your TODO list, one test at a time. You feel extremely motivated.


I know, now you are thinking about a bunch of work-related excuses. There must be an external factor which doesn’t allow you to practice TDD.

My boss won’t let me do it

If your boss doesn’t want to give you enough time to do your job properly and he/she is outraged when someone finds a bug in your software, then I feel sorry for you. Unfortunately, I cannot help you.

On the other hand it is possible that the boss doesn’t allow you to “waste” time on TDD and also doesn’t care about quality of your work. If it is the case, feel free to continue whatever you are doing. I hope I don’t use your products.

I work with legacy code

There is a great book about it: Working Effectively with Legacy Code (referral program link)
Read it. Right now.


Practicing TDD is like learning to read. It will take a lot of time. At the beginning you will be terrible at doing it.

You need to practice until you no longer think about TDD rules while writing your code. When it finally happens, you should continue practicing. It never ends. If you don’t feel comfortable with constant learning, maybe you should look for a different job.

If you start today, it will take x months to learn TDD. If you wait a week, it will take the same x months + one week. So why don’t you launch an IDE and practice?

Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you watch programming live streams, check out my YouTube channel.
You can also follow me on Twitter: @mikulskibartosz

If you want to hire me, send me a message on LinkedIn or Twitter.

Bartosz Mikulski
Bartosz Mikulski * data/machine learning engineer * conference speaker * co-founder of Software Craftsmanship Poznan & Poznan Scala User Group