Test Driven Development: The Benefits

This is the first part of a series of post regarding TDD (Test Driven Development), how it works, why YOU should use it, how to do it and how not to do it.

How I got started

As part of my final year of University, I've started working on a Ruby port an executable specification framework called GreenPepper.

My team and I decided to develop the entire thing while sticking religiously to the TDD methodology. Two months into the project we have over 98% code coverage.

TDD Simply Put

Very simply put, here are the 3 easy steps of TDD.

1. Write a test that fails
   
2. Write code to make it pass
3. Refactor

Those three steps are essential, they must all be done and in that precise order. In a future post, I'll give a more concrete example of how to apply these three steps. But for now, understand that if you're doing TDD, you cannot write code unless a test is failing.

The Benefits

The benefits of TDD are all tied to those three easy steps. The obvious benefits is that by following all those steps, the near entirety of your code is covered by your tests.

Also, by writing the tests first, you're forcing yourself to write code with easy and simple APIs. Lets face it, you're gonna be the one calling your code, might as well make it easy to use.

Another key benefits of writing test is that you are in fact writting an example of how to use your code. In a project where everything is properly tested, if you wish to learn how to use a class, you simply need to locate the tests for this class and you'll have a very complete example.

Now, the biggest advantage of unit testing is easy refactoring. When working of code that is not automatically tested, developpers are understandably frighten of huge refactorings. I myself worked in projects where features were abandon because it was too likely implementing it would break something. If everything is tested, you can change whatever you want without worrying about regressions.

A Real World Example

A testimony to easy refacoring with TDD is my last change to GreenPepper Ruby. We were using the standard Ruby XML library REXML for all our DOM parsing. This turned out to be a bad decision for several reason. REXML is sloooow, poorly documented and the API is simply awful. A much better choice was libxml. We didn't originally go with libxml because the OS X version was broken at the time. Recently the libxml team released the 1.0 version that fixed OS X. I decided it would be a good time to jump ship before the cost of changing library was even greater.

So I went in and change every class that used REXML. GreenPepper uses DOM extensively, so it was a huge change, several class had to be heavilly modified. It took me less than 5 hours to completly replace the parser.

I am 100% confident I did not break anything in the code. Why? Because EVERYTHING is tested and every test still passes!

There is no way in hell I would have dare change that parser if it wasn't for TDD.

The Bottom Line

TDD makes you more confident your software works at any given time. You can refactor without fear, thus creating much better code. If you plan on writing software that will be maintainable, you absolutely need unit testing and the best way to achieve that is thought TDD.

You should do TDD.

First Post!

Hi folks!

I guess the first thing I should say is welcome to my blog! As the very unimaginative title says, this is the first post of my blog (actually, my first post ever). So basically, my plan is to explain a bit about who I am, where I am from and where I think am going. Read on!

About Me

My name is Simon Mathieu, I was born in Quebec, Canada and still reside there for the moment. French is my native language, but I decided to blog in English for various reasons that I might explain in a future post.

I currently attend University of Sherbrooke as a computer engineering student and loving every moment of it (almost :p). I should graduate next December.

I'll save you the long enumeration of stuff I like and don't like, if you read this blog for long enough, you'll find out about them.

Why start a blog?

I've been thinking of starting my own blog for quite some time and I finally decided to do it. As a programmer, I admire several bloggers who have technical blogs. But in some kind of conspiracy to start me blogging, they all decided to blog about why I should start a blog.

Here's a snippet from Steve Yegge's blog:

This is certainly the most important thing I'll ever say in my blogs: YOU should write blogs.

Also Jeff Attwood said something similar during the talk he gave at CUSEC 2008 and when I attended CUSEC 2009, every speaker there agreed that I should start a blog!

As you can see, with this conspiracy of bloggers directed at me, I was forced to join their ranks in the blogosphere.

Another more serious reason why I started blogging, is to improve my writing skills. If you haven't notice yet, they suck, they always have. Since I consider this a major flaw in my professional training, I would need to come up with another lame excuse not remedy this right away. Now, with the Internet watching, I hope to get some extra pressure to practice.

Another important reason why I want to blog is because I'm starting an open source project. The project is called GreenPepper Ruby and will be discussed thoroughly in future posts. Since I'm learning Ruby for this project, I'll also share my discoveries of cool Ruby hacks and other implementation details with you guys.

What's next?

I spent two days thinking of a good blog name that wasn't taken and failed miserably. So I'm hoping for stoke of creative genius in the next few weeks so I can rename this blog to something better than "Simon's Blog". I'm open to suggestions!

I'll keep try to post often enough about various things like GreenPepper, books I'm reading, editorial comments on news or other blogs and whatever else I feel like writing about.

So thanks for reading et à la prochaine fois!