Todo projeto que assumo hoje tem algum nível de teste automatizado, mas nem sempre foi assim — levei um tempo pra entender onde testar traz retorno de verdade e onde é só burocracia. É parecido com o que já falei sobre middleware onde vale a pena: a pergunta certa não é "devo testar isso?", é "o que quebra em produção se eu não testar isso?".
Onde eu realmente invisto tempo
Testes de feature (ponta a ponta, batendo nas rotas da API) são onde concentro a maior parte do esforço em Laravel. Eles cobrem regra de negócio, autorização e validação ao mesmo tempo, então cada teste vale por vários unitários isolados. Regra de domínio complexa — cálculo, máquina de estado, regra de desconto — ganha teste unitário à parte, porque ali eu quero rodar dezenas de combinações de entrada sem precisar subir toda a stack HTTP a cada vez.
Onde eu não perco tempo
Não escrevo teste pra Model simples, getter/setter ou Controller que só delega pra um Service sem lógica própria — isso é testar o framework, não o meu código. Também evito mockar demais: se um teste de feature precisa simular metade das dependências pra passar, geralmente é sinal de que a arquitetura está errada, não que falta mock. Documentação oficial do Laravel sobre testing é clara nisso: o framework já facilita testar através de HTTP real, sem precisar isolar tudo artificialmente.
O teste como rede de segurança, não como meta
Cobertura de 100% nunca foi meu objetivo — já vi times perseguirem esse número e ainda assim deixarem passar bug de regra de negócio óbvia, porque testavam o que era fácil de testar, não o que importava. Prefiro menos testes bem colocados nos pontos onde erro custa caro (pagamento, permissão, cálculo) do que muitos testes superficiais que só dão sensação de segurança.
