Testing is boring - why do I care about it so much?

Automated testing is boring to software engineers. Everyone would like to build something that's more complex, feature-rich, or faster. Faster JSON serializer, microservices instead of monolith, real-time updates instead of request-response. "Our app is well tested" for sure doesn't sound as exciting as "With AI agents, we're building an event-driven app that's running on AWS Lambdas". So why do I care about it so much?

Developers hate testing so much that they prefer being called at 9 PM when on vacation - just so that they don't have to write tests

— Jan Giacomelli (@jangiacomelli) May 12, 2026

Users deserve the best

I believe that users using the software I'm building deserve the best. I want to be able to look them in the eye and proudly say: "Yes, that's the feature that I've built." It doesn't matter how fancy my development stack is or which fancy algorithm I used. What matters is whether my software is "making people's problems go away". I want to have proof that this is really the case. There's no better proof that some behavior is in place than having an automated test. If I see that there's a false sense of security, I need to improve my testing skills. Do not remove the tests and hope for the best.

Team can move more efficiently

I believe that close collaboration within the team is essential to building great software products. Collaboration is much easier when team members don't need to tiptoe around each other's toes. Tests that protect against regression allow you to take more risks without the fear of breaking someone else's work and ending up on the blame-game carousel. If anyone can touch anything, you can move faster and more efficiently. For example, when someone is out of the office, others can pick up the work. There's no need for the team to wait for the person who owns "this or that garden".

Designing for testability enforces lower coupling

"Everything is coupled too tightly" is quite a common complaint among software engineers. The good news is that tightly coupled code is hard to test. So if you solve testability, you can largely solve too-tight coupling as well. This way, we kill two birds with one stone. Does that mean that it's enough for a codebase to have tests to not be too tightly coupled? Unfortunately, no, you can still use lots of tricks like patching and heavy mocking to write tests while keeping the coupling too high.

Want to learn how to better design code through tests? Complete Python Testing Guide Course will teach you that and much more.

Manual testing is not repeatable and slow

One thing I learned throughout my career is that manual testing is not repeatable. Yes, you can use a checklist, but you may still miss some steps. Then there's also time needed for manual testing. Deploying the app, logging in, clicking around, ... A computer can do that much faster and more reliably. So why waste time with manual testing?

Note: Manual testing is important, but it should be used to find the weirdest edge cases, not things like "email field is not validated".

I like my free time

I like to do many different things. Windsurfing, surfing, trail running, playing guitar, hiking with my family — to just mention a few. I don't want to be bothered by broken production on Sunday morning when I'm just about to climb the mountain with my wife and two daughters. I don't want to be called out of the surf lineup to fix the bug that should've been caught 3 days ago. That's why I'd much rather invest time into valuable tests on Tuesday than be a hero on Friday afternoon instead of surfing.

Conclusion

While the automated tests might not be particularly fun, there are many great reasons to leverage their power in our development work. In my experience, valuable tests lead to faster, more reliable delivery, happier customers, better team spirit, and a higher quality of life. If nothing else, getting your Sunday mornings back should be reason enough.