Bogdan Bujdea

Windows Platform Developer

Why TDD makes me a happy developer

In the last few months I started to learn TDD(Test Driven Development), and I think it was the best decision I could make regarding my developer career.

For those of you who don’t know, TDD is a software development process that has three simple rules:

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

Now I could just take a few articles that talk about the advantages of doing TDD and create this article, but I wanted to share my opinion. I give you the 4 reasons that make me happy for practicing TDD:

1. Clean code

I have to tell you that I have the ugliest handwriting a person can have, but I can’t say the same thing about my code. I’m proud of my code, I like to keep it clean no matter what, and TDD makes it a lot easier for me to do this. If you’re a developer, then clean code should be the #1 priority for you.

Up until a year ago, I thought that my code was pretty clean and easy to understand. I just started an internship at Thinslices, and during that time I started to learn about test first development from a Pluralsight tutorial. Because practice is the best way to learn something, I thought that I should take an existing app that I made earlier for Windows 8 and write some unit tests for that code. You can imagine how surprised I was when I saw that most of my code was not testable. I wasn’t using dependency injection, my functions did more than they were supposed to do, I had all sorts of manager and utils classes and the list could go on. That was the moment I realized that tests are the best way to ensure that your code is clean. If you can’t test something, then it’s not clean code.

2. Refactoring

You don’t love TDD until you see how easy it makes to refactor your code. In November 2012, Microsoft organized a worldwide hackathon where I made a shopping list app for Windows 8. After the hackathon finished, I decided to do some refactoring before publishing it, so I made a final commit to my existing code, and started to change the code.

I thought it will take me 1-2 hours, but I ended up trying to refactor for more than 5 hours, and in the end, I came to the conclusion that it wasn’t doable. So I deleted my changes from git and just published it as it was. I don’t know if you saw this somewhere else, but this is what happened to me:

99 little bugs in the code

99 little bugs in the code

Take one down, patch it around

117 little bugs in the code

I wasted those hours for nothing, because each change I made in the code made me realize that something else had to be changed, and the bugs kept pilling up. Probably the fact that I wrote the app during a hackathon had a role in this, but still, you shouldn’t be afraid of making changes in your code.

With TDD, it’s a huge difference, I’m no longer afraid of changing my code. If something isn’t working, I see it immediately when I run the tests. Wouldn’t you like to have a magic button that when it’s pressed, it would analyze your code and tell you if there are any problems? That button is not the Compile/Run/Build button, it’s the button that runs all your tests, because if you do TDD, then you should have at least 90% coverage on your code, so errors are very easy to spot.

3. No debugging

I used to be one of those developers that are proud of their debugging skills. I thought that was a good think, but now I know that it’s the opposite. Good programmers spend their time writing good code, not debugging it. Here’s how my Codealike activity looks like:

My debugging time is around 10%, which is still pretty high, but most of that time is spent on debugging animations and API requests. My application logic is covered by the tests, so if I have an error, I just have to run the tests and I see the bug in a matter of seconds.

4. Career

Recently I read an article that states that:

By 2022 it will be not be possible to get a professional programming job if you do not practice TDD routinely.

I don’t know about the year, but I’m pretty certain that TDD will be required for a job as OOP is required in these days. In my last two interviews I was asked if I write unit tests for my code and one of the interviewers actually asked me to write a small project with TDD to prove my skills.

Software development must become an industry for professionals, and professionals are people that like to stay in touch with the newest technologies and they want their work to be flawless. You don’t see a doctor making a surgery with some outdated technique just because he doesn’t like to keep up. If a programmer makes an error and your website has a downtime of couple of minutes, most likely he will just be warned or not even that, but a doctor may lose his medical license if he does an error during a surgery. You need to take responsibility for your actions, and how are you going to be sure that your code works if you don’t know that each part of your code is covered by tests?

It takes some time to learn TDD, but trust me when I say that it pays off. Bob Martin has some nice videos about TDD which I’m sure it will convince you if I haven’t:

Clean Coders: TDD, Part 1

Clean Coders: TDD, Part 2