Beautiful Pixel

Over the past few years I have known Test Driven Development was the way to go, but my execution of that has been far from consistent.

Sometimes I think my project is too small to worry about it. But projects always get bigger than you think they will. A small bit of code with no tests isn’t really a big deal. But there is a certain project complexity threshold, where you can no longer keep the entire codebase in your head, when tests become an absolute necessity. As large bits of code become connected in an increasing number of ways, you need tests to ensure that unexpected things don’t break. And writing tests first ensure allows you to focus on just what your implementing without getting lost in the large and complicated guts of your app. The trouble is that when you start a project you don’t always know if it will reach that threshold.

Sometimes I think that I can just write tests later. After following this pattern many times, I can assure you, it is at least twice as slow as writing tests first, and your test coverage is far worse. The problem is that you have to root through your code and figure out what to test and how to test it. Coverage suffers because you are sure to miss branches of code, partly because you simply missed them, and partly because you are tired of writing tests. It just feels tedious to tread on through, writing code hours that adds no functionality to your application. It’s not fun.

Writing the tests first does a few things to make life easier:

1. Write a small test, write a bit of code, is a cycle that remains fresh and fun because you are not stuck writing only tests for hours on end.
2. Only writing code if you have a failing test keeps you focused. Its easy to get side tracked, fixing this and that, introducing more code changes before you are done with the current task. Focusing on smaller goals helps you code faster because there are less variables to think about all at once.
3. Implement features with almost no manual testing. With a tool like autotest its easy to add features or fix bugs without ever leaving your code editor. When all tests pass, you know you did it. One cursory manual test to confirm, is a lot faster than manually testing the features everytime you make a minor code change.
4. There is something very satisfying about seeing that “0 failures, 0 errors” after 45 minutes of hacking. It’s a carrot, and you just want to keep chasing it. When you get it, you just write another carrot to chase. It’s an addictive cycle.
5. The ruby community will like you more. All the cool kids do it.

None of this is novel or new for those who practice this. It’s simply my own journey to the TDD religion. To be honest I am just really tired of writing tests after a large body of code has been written. It’s a painful and tedious process.

• Checkout this is awesome presentation from RailsEnvy.com’s Greg Polluck

@blog_post.gsub!(/test/, "spec")

RSpec, test/unit, test/spec, in the end I don’t think it matters. Use the test suite that is the most comfortable for you. The fact that you practice TDD is far more important than the tool you use to do it. So use the tool that makes you want to do it.

I’m not going back to my lazy old ways, I’ve finally learned my lesson.