Tests aren’t for code you’ve just written

You’ve been coding a couple of years, and in your first commercial job you’re introduced to automated tests.

The experienced devs are saying they’re a crucial part of writing software. But you don’t see why you should use them. They’re time consuming to write, and hard to write well. It’s way faster just to poke the user interface and see whether it does what you expect.

You’re absolutely right. Automated tests are an awful way to test something you’ve just written.

But that’s not what automated tests are for.

What the experienced devs know is that most of coding time on a big project is spent in maintenance. You’ll add small features, but mostly you’ll tweak or fix up existing features.

Even on a big greenfield project, the last ~50% (a.k.a. “the final touches”) of the project is spent on small changes and fix-ups.

During this time, you’ll want to be able to react quickly. You’ll want to change a few lines of code, or maybe do a small refactor to add another case to some logic. The changes are small and numerous.

But without a way to know whether you’ve broken anything else in the system, you’re forced to manually re-test everything that your change touches. And I’ll guarantee you won’t be able to find everything, nor will you enjoy it when your client comes back with yet another regression that you missed…

Tests are a present to your teammates and your future self.

They’re the best type of present: the longer since you wrote them, the more useful they get.

Tests allow you to make changes and refactor without worrying about breaking existing functionality. Make your change, run the test suite, and if it’s green you can feel safe to commit and move on to the next thing.

Technology moves forward and framework authors only support their latest few versions. You’ll need to be frequently upgrading the dozens of libraries that your code depends on, probably every year. A good test suite is the difference between “yep, it works” and a painful manual re-test of every single code path in your codebase.

Tests compel you to write modular code. It’s hard to test something where the logic and view code are all crammed together into a single class.

Tests are also a great form of documentation. Want to understand the different cases of a tricky piece of logic? Go read the tests! When well written, they should spell out everything that a piece of code does in plain English.

There’s also Test Driven Development.

I don’t TDD myself but it works for some people, helping them architect their code in a clean, modular way with complete test coverage. For them, tests are a coding tool, as important as their code editor and API reference. I’d recommend everyone give TDD a good try to see whether it works for them.

When shouldn’t I write tests?

If you’re writing some code by yourself and you’re going to throw it away as soon as it’s used, don’t write tests. Prototypes are a good example. But beware: if your prototype turns into your production system, you are going to have to write tests for an awful lot of hacky code. And that will be very, very unpleasant. Trust me.

You’ll only truly appreciate your automated testing suite when it saves your butt by preventing a regression you would never have thought to look for. Until that time, put your head down and get writing great tests. Your future self will thank you.