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 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.
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.
Practicing TDD is like learning to read. It will take a lot of time. In the beginning, you will be terrible at doing it.
You need to practice until you
Did you enjoy reading this article?
Would you like to learn more about software craft in data engineering and MLOps?
Subscribe to the newsletter or add this blog to your RSS reader (does anyone still use them?) to get a notification when I publish a new essay!
You may also like
- Data/MLOps engineer by day
- DevRel/copywriter by night
- Python and data engineering trainer
- Conference speaker
- Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
- Twitter: @mikulskibartosz