What to cover, async pitfalls, and flaky tests

Coverage is a spotlight, not a scoreboard

Jest prints a coverage number (jest --coverage), and it's easy to chase it as a target. Don't. 100% line coverage can still miss every important branch; 60% can be fine on a glue file. Coverage is useful for one thing: finding code no test touches at all. Read it as a map of blind spots, not a grade.

A sane bar for the PawWalk API: aim for roughly 70–80% line coverage overall, and demand high branch coverage on the code that hurts when it's wrong — auth (does the guard actually reject a bad token?), billing (is the Stripe amount right on every path?), and any write (create/update/cancel a booking). A getter that formats a price can stay lightly covered; the branch that decides whether a walk gets charged cannot.

The senior line: I don't chase a coverage percentage — I make sure every branch in auth, billing, and writes is exercised, because those are the paths that lose money or leak data when they're wrong.