Code coverage is not a one-size-fits-all rule.
Source: Dev.to
The myth of a universal coverage percentage
The obsession with “85 % code coverage” usually comes from people far removed from real software and systems architecture. It is a checkbox mindset, often driven by me‑too thinking rather than engineering judgment.
If your code runs close to the silicon, has no presentation layer, and is mostly deterministic logic, then 60–70 % unit‑test coverage is solid. Pushing beyond that yields diminishing returns quickly.
In large projects—especially outsourced ones—coverage metrics get gamed. A function gets called, a test passes, the percentage goes up. Management cheers, cookies are shared, and nothing meaningful is actually validated.
For any software with a real UI, unit testing beyond ~40 % is usually a tax on the project’s bottom line.
A pragmatic testing strategy
Pure functions
Any logic that can be turned into a pure function should have 100 % unit tests.
Mockable components
Anything that can be mocked gets mocked.
End‑to‑end (E2E) testing
Everything else moves to end‑to‑end tests.
E2E testing used to mean brittle browser‑automation scripts. That era is over. Today I run full end‑to‑end flows using my own product, ehAye Engine, with built‑in browser automation. Sessions are fully recorded, screenshots captured per page and tab, and anomalies flagged.
- First pass is read‑only.
- Second pass allows mutation.
Before any deployment, a staging environment (identical to production but private) must pass the full E2E suite to unlock an upstream merge—no exceptions.
Comfort level with coverage
I am perfectly comfortable with 20 % unit‑test coverage when I know E2E is validating 100 % of the system behavior.
The key is measurement, but let ehAye Engine do the heavy lifting: record everything, capture screenshots, narrate what is happening. The result is repeatable, fast, and high‑signal testing.
Tools & resources
- Download ehAye Engine:
- Watch the overview video: