Suggested controversy background reading: Joel hates tests, Uncle Bob is incredulous, Kent Beck is offended, the VP of software development for Justin.tv shoots proudly from the hip, Jay doesn’t see the big deal but blogs about it anyway, and here’s little old me, exxagerating only slightly. Hat tip to every single developer on Twitter.
So, bugs. Do tests find ‘em? Good lord, yes. I don’t know what kind of unit tests you write, but mine find bugs all the time, though not generally until I try to change something ‘twere better left unchanged. I can’t begin to count the number of times a well-placed test has saved my own individual slice of bacon or the collective bacon of my team. Maybe I’m no rock star, but most of your team members won’t be, and a good rock star may well make a bad teammate. A robust test suite is the critical difference between me being enthusiastic about improving my team’s code and being terrified of doing so for fear of breaking something.
And finding bugs isn’t even the best reason to write tests.
- They communicate intent and serve as a living, breathing specification for a codebase that may not have one.
- They allow you to reason about code that hasn’t been written yet.
- They demonstrate how best to utilize what’s already there.
- They bring discipline and coordination to your process.
Two things really brought me around on testing:
- I’ve worked on several large, complicated codebases written in a dynamically-typed high-level language.
- I’ve had several great mentors who’ve demonstrated to my satisfaction the zen-like benefits thereof.
- Every time I have written code without testing it as I go I’ve come to regret the decision, without fail, even on personal, why-bother-testing stuff. I honestly don’t know how you people get a decent night’s sleep.
Stuff can break:
- Tests that once described the behavior of a particular module in a very granular fashion start to inhibit your ability to change evolve code in reasonable ways. Write more robust tests.
- Slow tests can result in a slow build cycle. There are technical solutions for this. (You do continuously integrate, don’t you?)
- 100% code coverage is hard to achieve. Code coverage is a funky measurement and a perfect score is no guarantee that you’re actually perfectly tested. I will also happily acknowledge that striving for it seems to yield diminishing returns. I try to stay above 90%, 95% if I can swing it, but I don’t let not hitting 100% bother me.
- Plus all of the other triumphs and tribulations that go along with maintaining a good test suite, as with any other body of code.
If you’re still undecided, well, it helps to work with someone who’s done it before.