I just found out why I’m not doing TDD5 min read
When you ask most people why they don’t do TDD or any other form of unit testing they tell you that they don’t have enough time. I understand why they say that, and I’ve been in situations like that, but what about side projects?
I had many ideas in the past, and they all start with “File -> New Project” in my IDE and they end up as an abandoned repo on Github. I’m definitely not the only developer who has an idea and abandons it before doing an MVP. Some of the ideas were good, and some were not, but the one thing they had in common were unit tests. That’s because I was already imagining before starting to write code that my app/library will be used by millions of people/developers and that’s why I don’t need bugs and my code has to look good, but in the end the code was far from my standards of “clean code” and unit tests were very few. Why is that? Because I got “in the zone“. That awesome sensation when you’re writing code very fast and each new line brings new functionality that can be seen as soon as you execute your code, and instead of writing tests for that line of code you’re more excited to work on another feature…and so on. In the end, you take a break, you look at what you’ve done and you’re proud that you could implement so many features in such a short amount of time, but when you look at the code you’re disappointed. I mean the code is good, basic clean code principles like SOLID are easy to implement and they should be natural after a few years of writing code, but you know you could’ve done better, and the disappointment mostly comes from looking at the test coverage. You realize that you only wrote a few tests in the beginning and as soon as you got in the zone you forgot about them. So what do you do now?
- Do you go back and write tests for the existing code?
- Well, it’s doable but those tests don’t have much value, they just confirm that the code works as you wrote it.
- Do you delete all that code and start doing TDD?
- This could be a good solution, but let’s be honest, how many of us would do that? It’s a side project after all, so it’s our free time that we invested…deleting that code means throwing those hours down the garbage.
- Leave it as it is and promise yourself that on the next project you’ll do TDD from the start.
- This is where I am unfortunately. I find all sorts of excuses for not writing tests, I even promise myself that this code is a PoC and I’ll start from scratch with unit tests when the PoC is done…but I never do that.
Now I started working on a new side project and I’m proud to say that so far I have been doing TDD, and it feels great(as always) even if I got in the zone, but now I try to keep it under control because I realized that this is my problem. I don’t know what will happen in the future but I know that by practicing TDD on real life projects it will get easier and it will start feeling natural, that’s my goal. Paid projects don’t help in my opinion because clients may specifically ask that they don’t want tests, or if you’re still learning to do TDD then indeed it will take more time to finish the project, so I’m doing this on my own time but not with Katas. I think they are great for practicing the rules and understanding them, but there’s a difference between TDD made on a string calculator and TDD for a mobile app. Katas are easy, you have a function and you keep writing tests for it, but on a real project it’s not that simple. If you test everything, like having >99% test coverage, then every little change will break your tests and that’s not what you want. Then you need about the architecture of the test project, how will you group your tests, etc.
Now how about paid projects? Is there a way to do TDD in them if your client is flexible regarding deadlines? Sure it is. I found out that I hate writing tests at the end of a task that took me a week to finish, and I also hate writing tests at the end of a task 🙂 What I mean is that you should do TDD, not writing tests after the production code, and the tasks should be small, one day max. That’s because for small tasks like one day long you may add only 1 hour of writing unit tests, and for 1 hour it’s worth it. But if your task takes a few days then maybe 1 day is for writing unit tests, and when the deadline is approaching you’ll sacrifice those unit tests for a good night sleep(until you find bugs right before the deadline and you wish that you would have written those tests).
It’s 2 AM now and I want to go to sleep, but I have this bad habit of reading and modifying my posts until I think they are not good enough so I discard them, but now I’m posting this as it is, even if it’s gibberish. Sorry if I wasn’t that clear, but what I tried to say in this blog post is that I’m trying to do TDD in my own projects and I found out it’s not time that’s stopping me, it’s “the zone”, and now that I know this I can try to keep it under control until doing TDD will feel as natural as walking, and doing it in real projects will not be an issue anymore. Wish me luck!