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 yes, 60–70% unit test coverage is solid. Push beyond that and diminishing returns kick in fast.
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.
What has worked extremely well for me:
- Any logic that can be turned into a pure function has 100% unit tests.
- Anything that can be mocked gets mocked.
- 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, anomalies flagged.
First pass is read-only. Second pass allows mutation.
Before any deployment, staging (identical to production, but private) must pass full E2E to unlock upstream merge. No exceptions.
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. Repeatable, fast, high signal.
Sit back, relax, and prosper.
Download at: https://ehAye.io
Watch video at: https://www.youtube.com/watch?v=Bb1C1NmduV8
Top comments (0)