What running tests on every push actually changed
"We don't have time to write tests" is how teams end up with no time at all.
I've heard it on every team I've joined. Then we built a product where automated tests ran on every single push — and ended up at 95% coverage with E2E suites in CI. Here's what that actually changed, and what it cost.
What it bought us
- Manual QA dropped by half. The boring regression checks — login flows, forms, permissions — ran themselves on every push. Humans only tested what was genuinely new.
- Refactoring stopped being scary. With Playwright covering the critical user journeys end-to-end, "let's restructure this module" became a Tuesday task, not a risk assessment meeting.
- Bugs surfaced in minutes, not in production. The cost of a bug is a function of when you find it. CI finding it 5 minutes after the commit is the cheapest it will ever be.
What nobody tells you about high coverage
- Flaky tests will eat the whole benefit if you let them. One unreliable E2E test and the team starts ignoring red pipelines. We treated a flaky test as a P1 bug — fix it or delete it, never "just re-run it."
- 95% coverage of the wrong things is worth less than 60% of the right things. We prioritized user-critical paths (auth, payments, data sync) over chasing the number.
- E2E tests are slow. Keeping the suite fast enough that nobody is tempted to skip it is ongoing work, not a setup task.
The mindset shift that mattered: tests aren't something you do after the work. They're what makes the next piece of work fast.
Honest question: what's your team's real relationship with tests — disciplined suite, "we have some, they're flaky," or none and shipping anyway? And if you could only keep ONE layer — unit, integration, or E2E — which one survives?