Coverage is not confidence
A suite can cover lines and still miss behavior. The useful question is not how much code ran, but what user-facing promise would break if this test failed.
The useful signal is usually already there.
A tiny patch rarely touches only one thing. Push it and watch the review surface appear.
Name the promise
Write tests around the contract: inputs, outputs, state transitions, and error paths. Implementation details deserve fewer tests because they should be allowed to move.
The assertion names behavior a user would notice.
Keep the pyramid honest
Fast unit tests catch most logic changes. A smaller number of integration and end-to-end tests catches wiring. Too much of either creates blind spots or slow feedback.
Flip the switches and watch the story turn into a tiny operating model.
A failing test is a useful alarm
Good tests make change safer because they remember the promises the code made before your brain got busy.