We’ve all done this at one point or another. It always sounds like a good idea at the time. You’re working on a particular feature for a client and that deadline is fast approaching. The tests aren’t contributing to that feature, so you figure they can be put off until after the feature is complete. Then, when the deadline has passed, the feature is delivered, and the client is satisfied, you can go back and write the tests that prove your code does what you expect it to. Simple, right? Not quite. In fact, not writing these tests simply leads to a frustrated client reporting yet another bug in the great feature you’ve just delivered. You end up spending a lot more time on the feature, going through a debugger and an angry client than you would have if you had just written the tests first.

In the project I’ve been working on for the past month and a half or so, this exact scenario happened (the client is slightly more forgiving than the one portrayed above, thankfully). We were coming up against a deadline and had to get a feature out the door. We had a couple of choices: Make sure our tests were written so that we could assure ourselves that the code worked, or just write the feature and ship it off. We chose the latter, which led to a few of the comments in the fashion of the title of this blog post. There were perhaps a half-dozen or so of these comments littered throughout the feature’s source. Naturally, a few days after the feature goes live, we received calls from the client pointing out that some bugs have turned up. We then spent the better part of that day hunting down the source of these bugs and writing tests for them anyway. In the end, we spent a lot more time than we budgeted for on this particular feature, all because we thought that we could temporarily forgo the tests in order to save a little bit of time. In actuality, if we had written well-defined tests first and had let the tests drive our code, we would not have had to spend so much extra time on the feature.

On the subject of taking time to write tests, there will never be “time” to do so. If you make a solemn vow to write tests just after this feature is published, you’ll find yourself making more excuses later on. “I have other features to get out the door.” “I’ve already finished that code, so why waste time writing tests for it?” “There isn’t enough time in the day to spend time writing tests.” The list goes on and on. The thing is that you’ll never get around to writing tests for code you’ve already declared to be finished, no matter how much you promise yourself to do so. The best time to write the tests is before you write the code for the feature: Let the tests drive your development, and you’ll find yourself completing the feature on time with fewer bugs (or none at all) and another satisfied client.