37
Why you might not want to use TDD?
I’m a big fan of Test Driven Development. I’ve used it when preparing educational materials, but also in commercial projects. Not only that, but I believe that this technique changes the way we think about tests. Really! Even if you don’t use it daily, once learned, it will influence all your future tests. It doesn’t mean it’s seamless or easy to start with. There are plenty of challenges on your way when you start. That is why I want to address some of them and share a few tips that will make your programmer’s life easier.
First of all, TDD is hard to start. Many people get lost, because they don’t really know what to do. The process is fairly simple. Just three steps: write a test, write the simplest possible code, and refactor both. Simple. However, when it comes to details, lots of engineers get lost. Which test should I write first? What does a simple solution mean? Should I refactor a big chunk already? Things that are simple are not always easy to work with. There might be lots of confusion and question marks in your head at the beginning.
And these red tests… Programmers usually don’t write tests to check anything. We write them to prove that our code works. Quite a difference! Our goal is not to break the code, but to show that we did a great job. Green color is the best proof. Red lines usually mean that something is wrong, something doesn’t compile, or we just broke it. It doesn't feel good. During the Test Driven Development cycle, we see red all the time, and we get used to it with time. What’s more, we realize that red tests are the most helpful ones. We get suspicious when a test is always green.
I have some really bad news for experienced devs. It’s harder for you than for less experienced folks. I’m sorry, but that’s how it works for many other skills as well. The more experience you have, the more difficult TDD is at the beginning, because you have acquired different habits. It doesn’t matter if you’ve written tests before or not. Starting with a test, when you’ve always jumped straight into a solution, is damn hard.
My advice here is to watch some live coding sessions. Even if you’ve read the best books and checked out some tutorials. Live coding gives you an opportunity to see the thinking process. You witness how decisions are made and what is the flow. You may want to follow the same steps or disagree at some points. But you have something to start with, some initial thesis to be verified. Otherwise, it’s easy to get stuck.
Test Driven Development gives you simple building blocks to help you create some nice and well-tested pieces of code. They are so simple that it’s tempting to skip them or modify them. Especially, if you feel like something seems odd you might want to change the process slightly, just to suit your needs. The more you do it, the less TDD it is.
I know that TDD might seem counterintuitive at times, but it IS well-designed. It was created by people who had written thousands of lines of code, and it was tested by thousands of engineers around the world. If you don’t “feel it”, it might be because you’re still in the process of mastering it. I remember one time we were organizing TDD live coding with my friend, and he suggested that we should prepare some code before. I said that it was a tutorial for people who were just starting, writing the code beforehand seemed like breaking the rules from the very beginning. He didn’t seem convinced, but he agreed. We ended up with a much better code that he thought we could have written. This story showed me that TDD has more power than we think.
One of the main problems with mastering TDD is that you don’t see all the benefits instantly. When I started with Machine Learning, I had had a working script differentiating cats from dogs done in two hours. Back in school, when I wrote my first lines of code in Logo, it took me a couple of minutes to see the turtle moving around. When I started using TDD, it took me days to see how it improves my programming style. And it was only because I had taken part in an intense workshop. If I had practiced an hour every day, it would probably have taken me weeks.
The recommendation for TDD beginners is just to follow the process without judging. In IT we love judging everything from the first minutes. We tend to look at things as if they were black or white. There is no grayscale. If something doesn’t work for us right now, it’s probably a piece of crap. That’s why, we tend to give up so easily when learning new tools or new skills. If you trust the TDD process and follow it without judging, it will lead you to the code you’d not have written otherwise.
When you start working with TDD, you first start with Katas. These are fairly simple problems that have limited business logic and requirements that don’t change. It’s not a coincidence. When you learn a new skill, you should focus on this skill only. It’s like an exercise at the gym. Before you move to CrossFit exercises, you need to learn how to warm up and work out each group of muscles. Our neural system needs to get used to doing exercises before muscle memory is created.
Moving from Kata to business problems can be tricky as well. In projects, we don’t always have all the requirements from the start. There is a possibility that these requirements will change on the way. There are lots of other challenges, like working with clients, continuous integration process, monitoring, bug fixing etc. We cannot focus only on the code and tests. This might make TDD more complex and require a more flexible approach. However, TDD is a very agile process, and because of that it’s perfect for changing circumstances. We just need to prepare before moving onto the “battlefield”.
Holding one’s horses might be hard in this situation. Especially when you start noticing the benefits of a well-tested code created using the Test Driven Development process. I observe this when my students do their first steps using the TDD. Most of them instantly fall in love with the process and want to use it in their project after trying with just one Kata. This is very promising, but might be overwhelming for them. I usually ask them to try one or two more Katas, usually more complex ones.
Real projects are multidimensional. Tools, requirements, processes, and sometimes even people, are constantly changing. We need to learn many things on a daily basis. When we try to use a new skill too early, we can end up disappointed. I’ve heard many stories about TDD working well only for simple problems. I know it’s not true, because I have been using it for business logic, and I also know lots of other engineers who are using it as well. But I totally get this. People move to real projects too early, before they are ready. So they just become overwhelmed, and they give up.
The best way to succeed in using TDD is to practice. Practice, practice, practice, and then move to “real life” problems. Try a couple of simple Katas, then try solving them using pair programming, then organise coding dojo or mob programming in your team. You will probably hit the wall a couple of times, but within a sandbox environment, it will be easy to overcome these challenges.
Test Driven Development is a great technique, and it can totally change the way you code. However, it’s not easy to start, it might feel counterintuitive at the beginning and many people easily give up before they see the real benefits in their projects. It’s worth the time to prepare before you try using TDD in your projects. You should invest some time and watch a few live coding sessions, especially if it’s possible to ask questions. This will help you understand the decision-making process. No matter how silly the process might seem at times, you should follow it without judging. The more humble you are at the beginning of the learning process, the faster you will see positive results. Move to the business logic of your project only when you’ve already practiced for some time using different forms of exercise and feel confident in doing complex Katas. I believe you can do it!
Of course, you might ignore all these pieces of advice, but then don’t blame the TDD process that it didn’t work for you.
If you enjoyed this article, you can check out my presentation on this topic during The First International TDD Conference HERE
37