4 reasons why TDD slows you down
Software engineering TDD

4 reasons why TDD slows you down

It is easy to announce that TDD slows you down, but have you ever wondered why it happens? Is there anything you can do better?
Bartosz Mikulski
Bartosz Mikulski – 4 min read

Table of Contents

  1. Not enough experience
  2. Short attention span
  3. You misunderstood the word “unit”
  4. It is not fun
  5. Excuses
    1. My boss won’t let me do it
    2. I work with legacy code
  6. Learning

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 the case of TDD, the beginning lasts for a few months. It takes a lot of time before we get used to test-driven development.

Why test-driven development slows us down? There are four reasons: not enough experience of the programmers, short attention span, misunderstanding of the “unit” word, and lack of fun.

Not enough experience

The obvious reason. It is not sufficient to read a 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? 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 an excellent 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 the code. 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 think about design. Yes, it is allowed.

You can paste the list of necessary tests into your 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 a unit test is a test that 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 long file.

Sometimes failure is part of the fun. You try something, fail, try again, fail, learn something new, and try a dozen times more. 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 incredibly motivated.

Excuses

I know, now you are thinking about a bunch of work-related excuses. There must be an external factor that 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 correctly 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, your boss may forbid you to “waste” time on TDD and also doesn’t care about the 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” by Michael Feathers. Read it. Right now.

Learning

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

Older post

Always stop unused Akka actors

Akka actors do not magically disappear when you no longer need them.

Newer post

Perpetually dysfunctional software

What happens when we release another beta version? Are users happy or angry? What if the reality is different than we think?

Related Posts

TDD Python

Test-Driven Development in Python with Pytest

How to setup and use Pytest to test Python code
Published on: 10 Nov 2022

Software Craft TDD

Why should you practice TDD?

What are the benefits of TDD for programmers and companies that hire them?
Published on: 30 Sep 2022

TDD Data Engineering

Testing legacy data pipelines

Do you struggle with maintaining your legacy data pipelines? Check out our article on how to add tests and refactor your code while working with legacy data pipelines.
Published on: 21 Jan 2022

Are you looking for an experienced AI consultant? Do you need assistance with your RAG or Agentic Workflow?
Schedule a call, send me a message on LinkedIn. Schedule a call or send me a message on LinkedIn

>