Test the layers that pay: coverage is not a strategy

Asked to estimate "adding unit tests" to a mature application, the honest answer is that the estimate is the wrong question.

Counting the actual surface made the point: dozens of controllers, dozens of repositories, sixty-plus UI components - against a handful of existing tests. Broad unit coverage of that estate costs months, and most of it would verify plumbing: that a controller calls its repository, that a mapper maps. Tests that fail only when you refactor, never when the business breaks.

What survived scrutiny was a layer strategy. Integration and end-to-end tests across the critical user paths - sign-in, the money screens, the data flows the business runs on - catch the failures that matter, with a fraction of the test count. Unit tests stay reserved for genuinely branchy business logic, the code with real decisions in it. Glue code gets nothing, deliberately.

The principle: test value comes from choosing the layer, not raising the count. A coverage percentage is the easiest metric to move and the least correlated with sleeping well after a deploy.