A real world story of why TDD is good

As if I needed any more convincing, I ran into another situation where TDD saved me from a lot of pain.

On my current project, we have a lot of client-side Ajax-y goodness. The feature that I was working on was dragging something from one part of the page and dropping it on another part of the page. I was using jQuery UI’s Draggables and Droppables to do this. I got most of the way done, and then realized that jQuery UI draggable/droppable support does not work completely in IE because of some IE bugs that they apparently have not worked around yet. (A newer version of the jQuery UI has come out since I wrote this so it’s probably fixed now.)

Luckily, I wrote all my JavaScript the TDD way, so all of the UI concerns were separated out from the code that has the logic in it. So I was easily able to pull out jQuery’s drag and drop and replaced it with Yahoo UI’s drag and drop in only 4 hours (and I’ve never used YUI before). The only code I needed to change was the JavaScript that was in the ASPX page (this is all of the untestable stuff that wires stuff up to actual DOM objects). All of the underpinning logic (some of which still uses jQuery, as does the rest of the site) all works the same as it did before.

If TDD hadn’t led me into well-designed, object-oriented JavaScript, doing this would have taken a lot longer than 4 hours. In fact, it probably would’ve been really difficult to do without just rewriting most of what I had done. But this is one of the reasons that we write tests first — it gives a code based is easy to change and easy to maintain. I experienced that first-hand today.