A reader of mine recently asked how I make testing a habit.
The question is an understandable one. There’s a lot of friction in the process of writing tests. Even for someone like me who has been in the habit of writing tests most of my code for many years, the friction is still there. On many occasions I still have to “make myself” write tests, the same way I “make myself” brush my teeth every few days or so.
I actually had to think long and hard about the question. I definitely DO write tests, but I’m not sure that the force that drives me to write tests is exactly a habit.
Yesterday I realized what drives to me to write tests. What drives me to write tests is that I realized, at some point, that coding with tests is easier, faster and more enjoyable than coding without tests.
So for me, writing tests is not a matter of self-discipline or anything like that. To the contrary, the driving force is something more like laziness. I’m taking the easier, faster, more enjoyable path instead of the harder, slower, more miserable one.
Let me explain each one of these three things in a little more detail.
How writing tests makes programming easier
Imagine you have some big, fuzzily defined programming task to carry out. You’re not sure what part to try to tackle first, or even what the parts of the task are.
It’s easy to see this kind of task as a monolithic, intractable mystery. You look around for an obvious toehold and there isn’t one. It’s overwhelming and discouraging.
Tests can serve as an aid in finding that non-obvious toehold. The act of writing a test separates the mental task of figuring out what from the mental task of figuring out how.
How writing tests makes programming faster
Writing tests is often seen as a trade-off: it takes more time to write features with tests, but it saves you time in the long run. I’m not so sure this is the case. I’ve definitely had cases where I’ve wasted 15 minutes writing a feature by testing my code manually, failed to get it properly working, and then had the feature working in 5 minutes with the aid of tests.
The reason it’s faster to code with tests is because you don’t have to perform a full set of manual regression tests every time you make a change. Without tests, it’s so easy to get into a game of whack-a-mole where new changes break old functionality.
How writing tests makes programming more enjoyable
As a person I’m lazy, impatient and easily bored. I also hate wasting time. This means that manually repeating the same 9 clicks through a feature over and over, and then multiplying that chore by however many possible paths there are through my feature, is like a task that was custom-made to torture me.
Automated tests can never fully replace manual testing (I’m still going to pull up every feature in the browser at least once) but they can go quite a long way. I find that coding using tests is quite a different experience from not using tests.
My testing habit
So my testing “habit” is really just a choice to take the path of least resistance. Since I believe that my job will be easier, faster and more fun if I write tests, then I’ll usually take that path instead of the other, worse path. And if I fail to remember that I know this and start coding without tests, the pain I encounter usually reminds me that writing tests is the easier way.