Last week I was listening to the Changelog podcast where they were interviewing Scott Chacon. They talked about a lot of good stuff, but one interesting point Scott made about version control struck me. I was unable to find a transcript of the podcast, so this is my best paraphrasing of what he said:
In colleges and programming education, version control isn’t taught as a toolset that is important. People see it as a necessary evil, not, “this is a tool that can make you a better developer or better at your job.” Git is more complicated (than Subversion), but it’s worth learning about it. When people learn Subversion, it’s usually, “alright, here are the eight commands you need, and that’s it.” But learning version control is more important than that — it’s as important as learning your editor. Everyone spends hours learning their editor, and people become incredibly proficient with them. Nobody uses notepad for development, but people use Subversion like Notepad. People don’t treat it as a toolset that gives you power.
It’s a very valid point. Git is more powerful than Subversion, but in order to harness that power, you have to actually sit down and learn it. Otherwise, it’s just a complicated tool which gets in your way.
I see a similar parallel with peoples’ overly-negative attitudes towards unit testing. Some developers declare that unit testing is, “a waste of time.” They’ll reference situations where test suites take minutes (or hours) to run, or an overly invasive test suite where changing any application code causes so many tests to break, much more time is spent fixing tests than actually making the change in the first place.
The thing is…these problems are real, but they only really plague you when you first start out writing unit tests — when you’re inexperienced with testing tools and techniques. And most often the developers I’ve seen voice these complaints are the ones who haven’t investing the time to learn about testing. They’re doing unit testing “like Notepad” and not as a tool that can make them better.
Unit testing is a tool for the developer, no more no less. Simply using it isn’t going to lower your software defect rate any more than simply using a hammer is going to build you a well made house. It’s how you use your tools that matters.
For me, I use unit testing as a tool in the following ways:
- By doing TDD, I think about my interface before I code it. I’m able to flesh out architectural issues during development.
- A test suite helps give me confidence my future refactoring won’t break existing behavior.
- A test suite helps accommodate for the lack of a QA department at my job.
How you use unit testing is up to you — there is no “right” way to do it. You certainly don’t have to do it for the same reasons that I do. But you should figure out what makes sense for you. Ask yourself, “how can I use this tool to make me better at my job? How are people using it successfully? What can I learn from their ideas and experiences? How does it fit in with my project/work style?”
Then go and try to learn the tools and techniques of doing unit testing and see how it goes. You’ll probably find that you like it.