My Journey with Unit Testing

I still don't love writing unit tests — but I've learned to respect what they bring. Property-based testing (fast-check) and mutation testing (Stryker) shifted my view from "tests are overhead" to "tests are confidence at scale." This article shares that evolution.

Key takeaways

• Good code and strict TypeScript are the foundation — unit tests complement, not replace
• Property-based testing (fast-check) finds edge cases you wouldn't think of manually
• Mutation testing (Stryker) reveals whether your tests actually catch real issues

Why I Thought Unit Tests Were Overrated

I'll be honest: I was never a big fan of unit testing — and even now, I can't say I love it.

For a long time, I was part of the team that believed good code and strong TypeScript rules were enough. My reasoning was simple: I write clean, typed, maintainable code, and I rarely get bugs that unit tests would have prevented.

In my experience, when something went wrong, it usually took less time to fix the specific issue than it would have taken to write unit tests for every possible case.

Unit tests always felt like a time sink. They slow development down, especially when deadlines are tight — and they don't always deliver the payoff people expect.

In one of my earlier projects, the test suite was unreliable: only one colleague could run it successfully, false positives appeared constantly, and tests didn't really prove anything. It was frustrating. That experience left me skeptical for a long time.

If the project was well-typed, the architecture was clean, and reviews were strict, why spend time testing what already worked?

What Changed My Perspective

That changed during my work on Voyage Vibe, when I started experimenting with fast-check and Stryker.

Fast-check introduced me to property-based testing — a different mindset where the test tries random inputs to explore edge cases. It revealed scenarios I wouldn't have thought of manually.

Stryker, on the other hand, was a wake-up call: it literally mutates your code to test whether your tests can catch the change. Seeing it break code I thought was "covered" showed me that my confidence wasn't as high as I believed.

That's when I realized: even if I don't enjoy writing unit tests, they can provide confidence at scale — especially when projects grow, evolve, and get more contributors.

Where They Make Sense

Today, I still approach testing pragmatically.

Business logic: Where I find unit tests most valuable. Complex calculations, data formatting, or domain-specific rules deserve tests because that's where subtle bugs hide.

Other layers: UI, hooks, APIs come second — useful, but not mandatory unless they contain intricate behavior.

In product-oriented missions, where code is expected to evolve continuously, tests shine. They protect the foundation while new features are built on top.

Balancing Speed and Rigor

Writing unit tests still feels slow to me.

When time is limited, I'll focus on major tests only — the ones covering critical paths or complex logic — and sometimes skip the rest.

But in projects like Voyage Vibe, where I control the quality gates, both fast-check and Stryker run in CI. I've set Stryker's mutation score threshold at 70%, meaning any PR that weakens coverage fails. That keeps things strict enough to catch real issues, without turning testing into a bottleneck.

My Rule of Thumb

If I had to summarize my stance:

Write unit tests when the code should be as robust as possible, when the project will keep evolving, and when time isn't the issue.

In other words, I see unit tests as a long-term investment. They don't make sense everywhere, but they pay off when you're building something meant to last.

Final Thoughts

I still think good code and strict TypeScript rules are the foundation of reliability. Unit tests don't replace that — they complement it.

I might not enjoy writing them, but I now respect their purpose. They give confidence when refactoring, safety when scaling, and calm when shipping.

Maybe that's the real shift: not learning to love unit tests, but learning to appreciate what they bring to the table — even when you'd rather skip them.