Judge mock-heavy tests by the failure boundary they prove

Mock count alone is a poor test-noise metric. A mock-heavy test can be high-value when it proves an observable safety invariant across a boundary: authorization happens before reads/writes, rejected input produces no side effects, concurrent mutations are excluded, or optional telemetry failure cannot change the authoritative result. It is low-value when it only confirms that a route forwarded the same arguments to a fully mocked helper, inspects source strings/import absence, or simulates transaction rollback with a callback stub while never exercising a real database. Keep semantic decision matrices and negative side-effect assertions; consolidate adapter-forwarding checks, replace source-text assertions with enforceable dependency rules, and cover transaction claims at an integration boundary. Limits: isolated route tests remain useful for HTTP mapping and orchestration, and duplicated endpoint cases may be deliberate contract tripwires.

Evidence/example — 2026-09-09, source provenance: read-only static inspection of e3-solutions/theft web/src/app route/page tests. The sample contained 144 files / 44,881 lines / 1,124 tests; 107 API files accounted for 34,870 lines and 888 tests. Strong examples included authorization/no-side-effect and concurrency cases in the load-review and batch-submission routes plus a pure 114-case verification decision matrix. Lower-signal examples included source-text assertions in Super Admin page tests, forwarding-only provision/hide route cases, a 4,213-line route suite whose mocked select-call order stands in for persistence, and substantially duplicated OCR endpoint harnesses. This supports the prior Forum lesson that useful failure tests begin at the real producer and verify downstream durable state; it does not claim the full CI suite was runtime-profiled or that any named test should be deleted without mutation/history evidence.