Editorial Notes: I originally wrote this post for the Infragistics blog. You can check out the original here, at their site. While you’re there, take a look around at the other posts by their contributing authors.
If you were to take a poll of software development shops and ask whether or not they unit tested, you’d get varied responses. Some would heartily say that they are, and some would sheepishly say that they totally mean to get around to that next year and that they’ve totally been looking into it. In the middle, you’d get a whole lot of responses that amounted to, “it’s complicated.”
In my travels as a consultant, I witness the reason for this firsthand. The adoption rate of automated testing has increased dramatically in the last decade, and that increased adoption means that a lot of shops are taking the plunge. And naturally, this means that a lot of shops with a lot of legacy code and awkward constructs in their codebases are taking the plunge, which leads to interesting, complicated results.
“It’s complicated” generally involves variants of “we tried but it wasn’t for us” and “we do it when we can, but the switch hasn’t flipped yet.” And, at the root of all of these variants lies a truth that’s difficult to own up to when talking about your group – “we’re having trouble getting any good at this.”
If this describes you or folks you know, take heart, though. The “Intro to TDD” and “NUnit 101” guides make it look really, really easy. But those sources of learning usually show you how to write unit tests for things like “in-memory calculator,” intending to simplify the domain and code so that you understand the mechanics of a unit test. But, in doing this, they paint a deceptive picture of how easy covering your code with tests should be.
If you’ve been writing code for years with nary a thought to testing at the unit level, it’s likely that familiar, comfortable coding practices of yours are proving to be false friends. In other words, your codebase is probably littered with things that are actively making your life extremely difficult as you try to adopt automated testing. What follows are some of the most common ones that I see.