I Spent a Full Month Fixing Tests — Here's What I Learned
I once spent a full month… fixing tests.
Not building features. Not improving the product. Just fixing tests.
Here's what happened.
A few years ago, I went all-in on testing
Same codebase. 1,000+ tests. Unit. Integration. End-to-end. Everything.
At first, it felt amazing.
I could confidently:
- Validate complex math-heavy logic
- Test database queries without fear
- Protect critical flows like the entire e-commerce checkout
It felt like nothing could break.
But then reality kicked in
Every small change started breaking tests.
Not real bugs. Just… tests.
Added a new internal function call? → Update mocks
Refactored something harmless? → Fix 5 tests
Changed implementation but not behavior? → Still broken
And suddenly, every feature had an extra cost: +1 full day just for tests
Now multiply that by:
- Every task
- Even small ones
- Over an entire year
That's when I realized:
I wasn't just writing tests. I was maintaining a second codebase.
My controversial takeaway
Tests are powerful. They can save you.
But testing everything comes with a hidden price: maintenance.
If I could go back, I'd do it differently:
I'd test what truly matters.
The core flows. The things that, if broken, would kill the product.
Not everything.
The AI game changer
Now, here's the interesting part.
This was 3 years ago, before AI really entered the game.
Recently, I've been using AI to generate and fix tests.
And it changes everything.
AI can:
- Create tests faster
- Update broken tests automatically
- Run fix loops with minimal human-in-the-loop involvement
What used to take days… now takes minutes.
So maybe today, having 1,000+ tests isn't the problem anymore.
But one thing still matters
Always balance 👉 number of tests vs 👉 maintenance cost
Because in the end, tests should protect your velocity, not kill it.