5 Reasons to do Test Driven or Behavior Driven Development

I’ve had a few discussions with people under various circumstances regarding Test First or Test Driven Development (TDD). Some people swear by TDD, while other don’t see how it could possibly work because “I don’t know how my code works until I write it.” My answer to this is “That’s why you need to write the test first.”

My initial exposure to Test Driven Development was while working for a client at SolutionStream. The client insisted that all development be done Test First. At first, it was a painful process. The tests took a while to write, and I really just wanted to get into solving the problem. As time went on, however, I found that writing the tests first, did a few things that made coding much more pleasant.

1. TDD helped me define my code.

This is much more of a BDD (Behavior Driven Development) concept, but is extremely relevant to Test Driven Development. When I had it pointed out to me that you don’t know how your code works before you write it, it really occurred to me that it didn’t matter so much how the code works as much as what it does. For example, consider a method that converts an object into a JSON string. To write a test, you don’t need to know how it converts it, you just need to compare the output of your method to a string you generate on your own. In other words, the expected output or behavior can be written into a test before you write your code.

This exercise helps me familiarize myself not only with the expectations, but to generate the results on my own, it makes me go through the process I’m about to code.

2. TDD helped me determine what was important.

The project I was working on when I was doing TDD was a Ruby on Rails project. Writing tests for the entire page layout was too brittle to be of much use. One little change, would cause them to fail. It became clear very quickly that what I needed to do was check that the critical data was on the page and skip the rest. Because CSS can change positioning, testing the actual look of the page from Ruby was difficult at best and impossible under normal circumstances.

I’ve applied this to other projects where I receive a lot of output and really only care about certain attributes.

3. TDD makes it easy to break the functionality of your application apart.

As you work through writing the tests for your new method, you’ll find that you’re probably moving through a series of steps. Writing tests for each of these steps and breaking the functionality up into their own methods allows you to make sure that each stage of your functionality works as you expect. This is only really necessary for moderately to extremely complex methods.

4. TDD adds sanity to refactoring.

Have you ever tried adding a feature to a project only to find that you broke another section of your application in the process? It’s easy if you just made the change that broke the code. But, what if you made the change a while ago? Or, what if the code you broke is extremely complex? If you wrote tests before hand at each level of your application and broke the functionality up to make it easily testable, then it’s relatively simple to figure out which portion of your code is broken and what you need to do to fix it.

For debugging, when you don’t have a test that’s failing, but you can see that something is broken, you should debug Test First as well. Write a test that shows the problem in your application and then narrow it down by writing more and more specific tests. This keeps you from making blind changes to your code and exposes blind spots in your tests.

5. Tests are often better than documentation.

Have you ever read the documentation on some library or system you want to use and come away not knowing any better how to make it do what you want it to? For your application, if you write your code Test First, you have code samples for other developers who come along to maintain your application after you move on. Don’t get me wrong, documentation and comments are important, but actual working code samples are invaluable.

Tagged as: bdd, debugging, Developers, development, tdd, Test First, testers, testing, tests