Testes automatizados

A pirâmide de testes e o que ela recomenda

Muitos testes de unidade (base), poucos e2e (topo). Invertido, a suíte fica lenta e frágil.

Mock, stub e fake: qual é qual

Stub = resposta canned. Mock = stub + asserção sobre as chamadas. Fake = implementação real simplificada (ex: repo em memória).

O que faz um teste unitário ser bom

Rápido, isolado, determinístico, testa comportamento (não implementação), uma razão pra falhar. Frágil = acoplado ao 'como'.

O ciclo do TDD (red / green / refactor)

Red (teste que falha) → Green (mínimo pra passar) → Refactor (melhora o design, testes seguem verdes). Repete pequeno.

Cenário: um teste que passa e falha sem o código mudar

Reproduza isolando e rodando em loop/ordem aleatória. Culpados: estado compartilhado, tempo, await faltando, paralelismo, rede.

Por que 100% de cobertura não significa código bem testado

Cobertura vê linha executada, não asserção feita nem caso de borda faltando. Boa como alarme, ruim como meta.

Arrange-Act-Assert e um assert por teste

Arrange (cenário) / Act (a ação, 1 linha) / Assert (verificação). Um comportamento por teste: falha aponta a causa e não para no primeiro assert. Várias asserções sobre o mesmo resultado é ok.

O que não vale a pena testar

Getters triviais, código de terceiros, detalhes de implementação, wiring de framework, UI pixel-perfect, o que os tipos já garantem, e a meta de 100% de cobertura. Teste o que, se quebrar, dói.

Quando um teste de integração vale mais que dez de unidade

Quando o risco está nas costuras (HTTP→validação→repo→serialização→SQL/migração), não na lógica interna. Mocks concordam com sua suposição errada; um banco de teste real não. 'Testing trophy'.

Fixtures, factories e o teste que ninguém entende

Fixtures compartilhadas acoplam testes (mudar quebra dezenas) e escondem de que dado o teste depende. Use builders/factories com defaults e monte o dado relevante dentro do teste, explícito.

TDD sempre? Quando o teste-primeiro ajuda e quando atrapalha

TDD rende com comportamento claro e implementação incerta (regra de negócio, bug, refactor, design de API). Atrapalha no exploratório (spike, tuning, protótipo). Faça spike, jogue fora, reimplemente com teste.

Snapshot testing: útil ou armadilha?

Compara a saída serializada com um arquivo salvo. Bom pra mudança não intencional e caracterizar legado. Ruim quando grande demais (vira 'atualiza tudo sem ler') e frágil a mudança cosmética.

Testes de contrato entre serviços

Verifica que consumidor e provedor concordam sobre a forma da API, sem subir os dois. Consumer-driven (Pact): testes do consumidor geram um contrato que a CI do provedor valida — quebra antes de prod.