So you’re a responsible little developer who likes to see good test coverage, so you have some confidence that your changes haven’t had unexpected ripple effects. And you’ve just joined a new project.

You’re delighted to see that there are hundreds of tests in the project.

But then…

You try to run the test suite.

Half of the tests don’t even compile.

A good portion of the other half fail for various reasons.

Sound familiar?

I’ve seen this on countless projects.

“Oh yeah, we have lots of tests! I’m not sure if they work, though.”

What causes this?

Well, it’s pretty simple, in my experience. If you don’t run your tests for every change, and before merging, you’ll end up with a broken test suite.

What’s so sad about this is that running tests automatically for every change is fall off a log easy.

It’s usually just a few clicks, if you’re using modern tools like GitHub Actions. And if you have more custom needs, it’s still usually just a few hours of work at most to solve this problem permanently.

Yet many teams seem to behave as if setting up an automatic test runner is some sort of super power that only certain people are capable of accomplishing.

Does your project have tests? Do they run for every change? If not, what’s stopping you (yes, YOU) from fixing that today?