Run your tests"Oh yeah, we have lots of tests! I'm not sure if they work, though."
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.
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.
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?
My Most Controversial Opinions
Edited by Taavi Kivisik Happy New Year to everyone! I was excited to kickstart the new year with a new position at Lana, a Spanish FinTech startup. As part of my first week on the job, I met a candidate for another position there, and we started talking about controversial opinions in IT. Unfortunately, we found nothing to disagree about. Although I was inspired to catalog a number of my own personal opinions about software development, which may be more controversial.
Make the change safe, then make the safe change
What can you do when no change would be safe to make? First, make the change safe.
Improve your software delivery