People have pretty strong opinions on TDD (Test Driven Development). Some think that it is a pretty big waste of time while others think it is the only way to go. Off the bat, I will state that I lean more towards the latter camp, that TDD is a great tool for both writing code quickly and improving the resulting code.

The biggest complaint that I hear from people about TDD is that they think it slows them down or that it duplicates work. “If I already know how to implement a method then why do I need to write a test for it.” or “Am I seriously supposed to write a test then implement the code for that one test, one at a time for every test?“

My answer is NO. You don’t have to be super dogmatic about TDD or to do it in the exactly right way. There is plenty of benefit to Test Drive Development just in itself.

The way I see it, the big plus of test driven development is that it sharpens your thinking before you start writing actual code. You can take your ideas (or the requirements) and write them down as a series of pending tests. Then you can tick them off, one by one, in whatever order you want.

TDD is really just a series of steps to increase clarity on what you are doing. That is test driven development for me, a self verifying TODO list that goes from:

1. An idea – a pending test that describes what you want a specific method or object to do.
2. Specific requirement – a failing test that has expectations on the data returned of the behavior performed that is being tested.
3. Tested code – a passing test with implemented code that meets the previous expectation

That easy flow is what makes TDD valuable to me.

Also, to be clear, not all testing is test driven development. Sometimes a test is written to prevent bug regression or to make sure a critical path through the view works. Those are often useful and important tests but they aren’t really TDD to me.

The best place for TDD in Rails in my estimation is on Models and sometimes Controllers. In the View the development can be driven by what you see, while at the model level things are more abstract which is what makes TDD more valuable there.

Since there are so many ways to turn your thoughts into actual code at the Model level I think this is where TDD shines because it helps you clarify what code you are actually trying to write before you write it.

You can write down what you want from your code as pending tests to get your thoughts out of your head and into a more specific, written form. Then you change the pending tests into failing tests to get more specific about the actual data and behavior you want to get back from the model. Then finally into green tests (working code) when you figure out the implementation of the data and behavior that will be returned.

Writing code in this manner lets you go from very vague formulations of a problem to specific code in a series of easy steps and just happens to be Test Driven Development.