Sean Voisen

Thoughts on test-driven development

August 28, 2011

Clean code is all the rage these days. It’s what all the cool kids are doing. Which is a bit odd, because you would think that clean code should never have been a fad, but rather a staple of software development since the earliest days of FORTRAN. Such is not the case.

Instead, it took the recent rise in popularity of dynamically typed languages like Ruby and Python to make test-driven development (TDD) — and clean code by extension (or is it vice-versa?) — fashionable. Mostly out of sheer necessity. If you don’t have a compiler to tell you when you made a mistake as simple as a misspelled variable name, you better have a suite of tests that will.

I’m guessing here, but I get the sense that in the software industry TDD is still the exception rather than the rule. Why? Some software developers might say it comes down to a matter of priorities. Software companies prioritize ship dates and over quality. And writing fully tested code cleanly takes time — time which developers don’t have. This results in code that you might generously call “quick and dirty.” In fact, in software development, “quick” and “dirty” are two adjectives you always find paired together. Like light and shadow, or peas and carrots, or Batman and Robin, or C and buffer overflows, where you find one you find the other. The rule is: code written quickly is by necessity sloppy. And, conversely, clean code takes time.

Uncle Bob, however, says otherwise. In order to go fast, your code has to be clean and it needs to have full test coverage. If it does not, you’ll spend too much time fixing bugs that could’ve been caught with a proper test suite or made easier to find with proper naming conventions. And you’ll waste hours or days accidentally breaking the functionality of existing code when you try to refactor or add new features.

Recently, our team at Adobe XD invited Uncle Bob over to our office to spend three full days beating this philosophy into our craniums. Since then, a few of us have been practicing employing clean code techniques in our day-to-day projects. I’ve been sticking to it as rigorously as possible. A few takeaways from my own experience:

Writing tests is not fun. Anyone who tells you otherwise is a liar. But, getting tests to pass is surprisingly addictive. And therein lies the power of TDD: it offers a kind of IV drip of continous daily victories.

But would I use TDD for every project I work on? Probably not. For personal “one-off” projects or projects I know will not see much future maintenance, the slower development time is simply not worth it. For serious, long-term projects however, TDD is now a must.


More posts in the archives →