Como você decide o que cobrir com testes unitários versus testes de integração?

Teste unitariamente lógica com ramificações e casos de borda: regras de precificação, parsing, máquinas de estado. Teste por integração as costuras onde suas premissas encontram a realidade: queries de banco, serialização, middleware de autenticação, clientes de terceiros. Se um teste precisa de cinco mocks para rodar, ele está testando principalmente os seus mocks e o valor está num teste de integração. Mire em muitos testes unitários rápidos mais um conjunto menor de testes de integração cobrindo os caminhos críticos.

Eu divido por onde o risco mora. Se o risco é lógica, ramificações, arredondamento, casos de borda numa máquina de estado, isso é teste unitário, e ele deve ser rápido o bastante para eu rodar o arquivo inteiro ao salvar. Se o risco está numa costura, meu SQL de fato retornando o que eu acho que retorna, JSON serializando do jeito que o cliente espera, middleware rejeitando um token expirado, isso é teste de integração com um banco real num container. A heurística que eu uso é contagem de mocks: se eu preciso de quatro mocks para um teste rodar, aquele teste afirma o meu modelo mental daquelas quatro coisas, e o meu modelo mental é exatamente o que está errado quando aquilo quebra em produção. Também tento ser honesto sobre o que eu não testo. Um controller fininho que só repassa, ou um getter, é coberto incidentalmente e testar separado é custo de manutenção sem sinal. A suíte que eu quero é muitos testes unitários rápidos e talvez vinte testes de integração sobre os caminhos onde dinheiro ou autenticação estão envolvidos.