Primeiro defina o que precisa aprender
Antes de escolher uma ferramenta, formule a pergunta. A regra de desconto está certa? O endpoint conversa com o banco real? Um fluxo funciona em navegador? Dois serviços concordam sobre uma mensagem? A aplicação atende ao objetivo de latência? Cada pergunta pede uma fronteira de teste distinta.
Não existe um número universal de testes, uma proporção fixa para a pirâmide ou uma ferramenta que substitua todas as outras. Priorize riscos e mantenha feedback rápido, reproduzível e compreensível.
Um mapa da série
- Testes unitários em .NET: regras isoladas, limites de unidade e doubles de teste.
- TDD: ciclo Red-Green-Refactor como método de desenho e feedback.
- BDD: exemplos de comportamento para alinhar produto, desenvolvimento e testes.
- Testes funcionais: validação do comportamento observável e dos fluxos do sistema.
- Caixa preta, caixa branca e caixa cinza: perspectivas de teste e técnicas para escolher casos.
- Cypress para testes de navegador: automação de jornadas reais de interface.
- k6 para desempenho e carga: cenários, métricas e limites sob tráfego controlado.
- Testes de contrato: verificação independente dos acordos entre serviços.
Como os níveis se complementam
Um teste unitário verifica uma regra em isolamento. Um teste funcional observa comportamento de uma funcionalidade através de uma ou mais fronteiras. Um teste de integração verifica que componentes concretos colaboram, como API e banco. Um teste de contrato confirma formatos e interações entre consumidor e provedor. Testes de desempenho medem a resposta do sistema a uma carga definida. Os nomes variam entre equipes, então documente o escopo do teste em vez de depender só do rótulo.
Os artigos existentes aprofundam testes de integração com ASP.NET Core e containers e testes de arquitetura em .NET.
Uma estratégia equilibrada
Coloque a maioria das verificações de regra perto da lógica, onde são rápidas; valide integrações representativas em fronteiras reais; cubra poucas jornadas críticas de ponta a ponta; e execute testes de carga no ambiente e na cadência apropriados. Uma falha deve indicar o que quebrou sem exigir horas de investigação para descobrir a causa.
Uma suíte ampla mas instável, lenta e ignorada não oferece confiança. Reduza duplicação entre níveis, elimine dependências de ordem e dados compartilhados, e faça cada teste justificar o risco que cobre.