Why Unit Testing? Why now?
But I have so many other things to do!
A common and probably ever-recurring discussion is whether or not unit tests can be “afforded” for a current project.
The general response is that it’s too much work and too slow to write Unit Tests for all of our code, and we have deadlines to meet, but we definitely are all agreed (finally) about the benefits of Unit Testing along with CI, so we will definitely start Unit Testing.
On our next project.
As every developer knows well, the environment with deadlines always looming is also the environment where there is never time to do things right, to get over the initial learning curve, and reap the benefits of the time-saving, quality-increasing, anxiety-relieving practice of Unit Testing.
And this is a big problem.
Until the team starts Unit Testing, they cannot increase development velocity. But until they increase development velocity, they cannot find time to get over the initial slowness that any learning curve will cause.
Stop Everything
Unit Testing is SO important that you should not be doing your next project — or even finishing this one — without it.
Jeff Atwood (of Coding Horror fame) said once: “unit tests are so important that they should be a first-class language construct.”
Why does he say this? It’s simple. Unit tests make everything you touch better and easier, both now and in the future.
Anecdotally, I can think of a half-dozen times I thought “I’m only writing this Unit Test as a best practice, but it’s probably completely unnecessary” only to discover that I had, in fact, made some sort of mistake.
So let’s consider how to start Unit Testing without completely disrupting our current workflow — so we can ease into it.
One Thing At a Time
To start Unit Testing where there is zero Unit Testing can seem like a big task.
The biggest hurdle is actually putting the unit testing framework in place so you can easily write and run your unit tests. This is left as an exercise for the reader and Google.
Once that’s done, however, it’s just a matter of writing your first test.
Write one unit test for an existing class in your project. Notice what’s hard to test. Notice what’s easy to test.
If the whole thing is hard to test, it tells you something about your code. If you can’t test the class without inadvertently involving 3 other classes, and affecting the file-system or interacting with the database, then you may have tightly coupled code.
Which is bad.
Or maybe you find it rather pleasant, but you wonder what would happen if you put in some non-standard parameters, and suddenly your code breaks in an interesting way.
Also bad. (But good that you caught it, right?)
The point is, you have to start somewhere. Start writing tests, see how tests are written, and get better at writing tests.
Writing tests is an art, just like writing code is. It’s an art that will help you write better code, and better code will make writing tests easier as well.
You won’t get to 100% test coverage (nor should that be a goal) on an existing project, but some tests are better than no tests. And it will make your code moving forward better.
Growing Up
Learning how to write a unit test is the first step toward becoming a professional developer.
It’s more important than complicated patterns. It’s more important than understanding bits and bytes, sockets, database design, or good software architecture.
It is a foundational practice that lets a programmer use the above principles when they’re needed by allowing him to fearlessly restructure, change, and improve his code, while always being assured that he’s not breaking the contract his code has made to work as expected.
Unit Testing becomes a tool to allow your continual growth as a programmer, and it allows you to have professional confidence that what you ship works, and that your last-minute hot-fixes aren't going to blow up the internet.
So make the decision to be a better developer and start unit testing now.
