How do you decide what to cover with unit tests versus integration tests?

Unit test logic with branches and edge cases: pricing rules, parsing, state machines. Integration test the seams where your assumptions meet reality: database queries, serialization, auth middleware, third party clients. If a test needs five mocks to run, it is mostly testing your mocks and the value is in an integration test instead. Aim for many fast unit tests plus a smaller set of integration tests covering the critical paths.

I split it by where the risk lives. If the risk is logic, branches, rounding, edge cases in a state machine, that is a unit test, and it should be fast enough that I run the whole file on save. If the risk is at a seam, my SQL actually returning what I think it returns, JSON serializing the way the client expects, middleware rejecting an expired token, that is an integration test with a real database in a container. The heuristic I use is mock count: if I need four mocks to get a test running, that test asserts my mental model of those four things, and my mental model is exactly what is wrong when it breaks in production. I also try to be honest about what I do not test. A thin controller that just passes through, or a getter, is covered incidentally and testing it separately is maintenance cost with no signal. The suite I want is lots of fast unit tests and maybe twenty integration tests over the paths where money or auth is involved.