Defending The Case for Test Driven Development

Have you ever heard of Test Driven Development? You probably have. You have also probably seen people advocate for it and against it. I believe it has come the time for us to own it as a technique that enables us to make better software. Just remember not to go too dogmatic on it, to introduce some key performance indicators (a.k.a. code coverage), and to turn it into a bottleneck and an impediment to your progress. After all, we have to use the right tool and technique for each job, so don’t go on the radical side.

Introduction

Before defining what Test Driven Development is, I believe I should provide some context on how I came to know it.

I was first introduced to the concept of Test Driven Development back in 2001, practically a year after becoming a professional software developer. At that time, I did not write any single test for the software I developed: I simply ran it to see if it worked. That approach worked just fine when I was at the university. After all, you just have to solve the problem and move on; you do not have to maintain the solution.

When I started fixing the first customer bugs, I started to feel the pain of maintaining the software. Not only that, I had to maintain the version on the field while developing the next version. It was a fun learning experience, something that was not taught at the university at that time, and, last time I checked, it is still not part of the university. That is strange because that is one skill that people will need when working professionally. In fact, even for an open-source project, you still need to maintain and develop it. Why this is not taught still baffles me, but back to the subject at hand.

When I started correcting bugs, it got to the point where things got a little tricky. I felt like I was playing the whack a mole game: I fixed a bug here just to cause another there. The problem was that the tests were manual. In fact, we had a large test specification, but who would run all those manual tests on every release? And no amount of test specification software, where you would answer if the test passed or not, made the process any simpler or agreeable.

I do not know when I first heard about Test Driven Development. I gained the habit of following some news and blogs about software development, actually following people who wrote on the internet. It was probably one of those articles that led me to Test Driven Development. When I first saw it, it appealed to me. The idea of having tests where you clicked a button, and they would tell you if your code was OK or not was very appealing. I started to read more and more about it, and then I finally got the courage to try it out.

What is Test Driven Development

I do not want to copy Kent Beck and define Test Driven Development. You can check the Cannon if you want a detailed description, or read the book. What I want to do is shared what I believe is the main mentality behind Test Driven Development.

The main concept behind Test Driven Development is in its name: development should be driven by tests. For me, this does not mean that I should write unit tests; that is just a detail. For me, it means that when I am developing software, I should focus on how I will be testing it. This means not only the tests, but also the environment where the tests are executed. Will the system have a database? An external system it depends upon? Should these be simulated for the tests, or should we use real ones? These and a lot of other questions arise when you start thinking about how to test your code, instead of just focusing on a small piece of code.

Do not get me wrong: I believe that this approach should be applied when you are developing top to bottom (London style), or bottom to top (Chicago style). We should have a notion of how we will be deploying the system so that we can have a notion of what tests make sense. But this does not mean a big upfront design. I believe in a more iterative approach, of using a good architecture that allows us to delay our options for as long as we can. A sound architecture and design allow us to add features easily, test easily and deploy easily, but this talk about architecture is a subject for another post.

Trying is only the first step

When you first try Test Driven Development you are going to make a lot of mistakes. I did a lot of them — probably all of them. The tests get too dependent on the structure of the code; they get brittle, and they get hard to change. You will be learning a lot the first time you actually do TDD.

The truth is, you probably need a mentor. You need someone who has done this before to lead you and guide you so that you avoid most of the mistakes. You will still make mistakes. Making mistakes is part of the learning process; you need to make mistakes to learn. Having a mentor ask questions helps you learn faster. It will help you avoid going down the wrong path for too long, because it will cost you to correct the path.

I did not have that luck back then. TDD was not known as it is today. I did not have a mentor where I worked. In fact, I was ordered not to do TDD, because doing TDD would require more work and make me slower. I ended up learning by myself, reading blogs and books. When I got confident enough to try it, I did it against orders from my boss. I took that risk.

The fact is that when things were done, my boss started giving me praise for finishing faster than expected and that it was a good thing I followed the advice of not doing TDD. After all was said, I showed the tests to my boss. I showed how everything was done using TDD, and that I believed that TDD made me faster, although I couldn’t explain it at the time.

Growing The Skill

Test Driven Development is a skill; it needs to be developed and grown. When you start, it seems simple, but then you will hit some roadblocks. The tests will become too dependent on the code; they will become hard to change. Things that used to be easy start to look hard or impossible. But the fact is that, if you practice the design part of Test Driven Development, things will get easier and more modular. Problems will split more naturally and be easier to solve.

This is something that will take some time. It will take years to develop and improve. But who knows all the techniques right out of the university, or codecamp? You need to read and try it, to learn the patterns, the solutions and when to use them. This is done over time, by practicing your katas and making mistakes. You can’t simply read a book and expect to be proficient the next day.

Advice For The Next Generation

When I started doing Test Driven Development, it was still in its infancy. Its first incarnation, under the test-first concept of Extreme Programming, started back in 1999. The first book was released in 2000, but blog posts on the subject appeared before. Today, you have the possibility of learning the techniques sooner rather than later. You can ask for guidance from more senior developers as you practice it. Keep an open mind: if most of us seniors preach about it, it means that it must be good for something. If most open-source projects use it, it means it must be good for something.

Don’t just discard it because you read a blog post from someone who has never really done it. Don’t fall for the measurement trap of working for code coverage. Practice it, see its benefits, and keep it close to you, in your tool belt 😊