I have learned about the practice of TDD about two years ago, and I have to say – it didn’t sound that good. I didn’t understand what all the fuss was about, and I already wrote tests, so I didn’t see any real value in TDD.
Two years later, I’m here to say that I was wrong, and share with you just how TDD really helped me.
This post is would not be technical, and won’t explain the in’s and out’s of TDD, I’m sure that if you’re reading this you already heard about TDD and how it works. What the post will tell you is just what you’ll benefit from practicing TDD.
As I said, I already wrote tests before I practiced TDD, but there were times that time was short and the pressure was high (as it’s usually is!) and I was told to get things done fast – and who got time to write tests, right?
I got the time to write tests
It’s not that I didn’t believe in tests, but almost always near the end of the sprint, it seemed that there was no time left.
TDD solved this problem for me – there is simply no way of advancing in writing functional code without also writing tests. A developer that practice TDD doesn’t give separate estimations like – 2 days coding, 1 day testing, he gives one estimate – 3 days total.
What if I was asked to shorten the times? I would reply that this is the time that takes to code that functionality, and I suggested to reduce scope.
Let’s talk about that for a second, in each project, there are four major parameters: Cost, time, scope and quality. All are interlinked. If we want to cut on time, what can you do? the simplest two solutions are to cut down on quality (no tests, less refactoring, documentation etc’) and to cut down on the scope.
A friendly tip – cut down on scope, never on quality. Cutting on the quality will always result in slowing you down later down the road. I’ll phrase this as a question, have you ever been slowed down by poorly written code? guess what that other developer chose to cut down on.
Moreover, I have almost never had the time or energy to go to ‘old’ code and pay the technical debt – there was always something new to do.
TDD saves me a lot of energy, deciding up front, I will not cut on quality.
Why is deciding up front matters so much?
Imagine you’re on a diet, and you’re trying to eat healthily and you’re committed to that goal. Now say that you’re at the store and you see a cookie, and you’re facing two options: Option A is not buying the cookie. Option B is buying the cookie, but promising to yourself you would only eat some of it, or save it to when you’d really want it. In which option it would be easier to stay committed to your goal ? not buying the cookie in the first place is so much easier than to resist the constant temptation of having it near you and having the option to eat it.
I became reliable
Reliability is a desired property in a developer, it means that you can make promises, and someone can make plans based on your promises. When you can give your word and it means something, that you know you are reliable.
Did it ever happen to you that you thought you finished something, only later to learn that there was a small problem that needed a quick (even a one liner) fix? That used to happen to me a lot. Nothing big, but I gave my code away and had it turned back to me.
Let’s make a metaphor: say you are sitting at a restaurant and you order a few dishes. You really enjoy the food the restaurant atmosphere, but then you find out that one dish was not made well and needs to go back to the kitchen.
What do you think about the chef at that restaurant? poor work, even if it’s just some of the time, is a sign that you’re not working with a true professional.
I already mentioned in the first part of this post that TDD made sure that I don’t release code without having extensive tests, this made sure that I rarely release defective code – releasing working quality code made me look (and be) a professional.
Others on the team enjoyed working on my code
From time to time, others on the team had to change some code that I wrote, since new features came or that there was a change in requirement.
At first (before I got the reputation I have), I saw that people were afraid of stepping into code they don’t know. But there was always a pleasant surprise waiting – all code has tests, it was refactored and clean.
After a few months, members of the team knew that my code was code that they want to work on.
I view TDD as a method of becoming proactive in being the professional I wanted to become.
I strongly encourage you to try it out for a couple of months and see just how much of an impact it makes.
I’d love to hear your experiences and opinions, or any questions that you may have. I encourage you to write them in the comments below.