Como times maduros tratam testes — não como obrigação, mas como ferramenta de design e confiança.
Oito ideias que separam quem escreve testes "porque tem que ter" de quem usa testes como ferramenta de pensamento e confiança em produção.
O ciclo de Beck destrinchado. Disciplina específica de cada passo, padrões de aprendizado (Calculator kata, FizzBuzz, Bowling), e os erros típicos de quem está aprendendo.
Cohn, Kent C. Dodds, Spotify. Quando cada estratégia faz sentido, e como decidir o mix certo para o seu sistema.
Dummy, stub, spy, mock, fake. Quando usar cada um, por que mocks demais é antipattern, e a heurística de Fowler em "Mocks Aren't Stubs".
Por que Dan North inventou BDD, como Gherkin estrutura conversa entre devs e stakeholders, e quando BDD ajuda vs estorva.
Hypothesis, FsCheck, gopter. Em vez de testar "soma(2,3) == 5", testar "soma é comutativa". Encontrando bugs que ninguém pensaria em escrever como exemplo.
Cobertura mente. Mutation testing introduz bugs propositais e verifica se os testes os pegam. Stryker, mutmut, go-mutesting.
Pact, OpenAPI validation. Como testar a fronteira entre serviços sem subir tudo em E2E. Consumer-driven contracts.
Snapshot tests, builders de dados de teste, e o problema dos testes flaky — como diagnosticar, isolar e exterminar.
Teste não é cerimônia que vem depois do código. É a ferramenta que revela onde o design está mal-posto, antes mesmo do código ir para produção. Quando esse hábito vira reflexo, qualidade deixa de ser inspeção e vira propriedade estrutural.
Decisões de qualidade que separam o teste como cerimônia do teste como ferramenta.
TDD sempre, ou só onde faz sentido?
TDD funciona melhor quando o problema é razoavelmente bem-definido e o ciclo é curto (lógica de domínio, parsers, transformações). Funciona mal em exploração (UI nova, integração com API desconhecida, bibliotecas de terceiros sem clareza). Em projetos exploratórios, escreva código spike primeiro, jogue fora, e implemente com TDD a versão final. "TDD obrigatório em tudo" é dogma; "TDD onde fortalece" é prática.
Cobertura como métrica — útil ou enganosa?
Cobertura mede se o código foi executado, não se foi verificado. Você pode ter 100% de cobertura sem nenhuma assertion útil. Use cobertura como sinal de alerta (caiu de 80% para 60%? algo mudou) e não como meta. Para verificar qualidade real dos testes, use mutation testing — ele mede se os testes pegam bugs introduzidos propositalmente.
Mocks ou fakes para dependências externas?
Fakes (implementações alternativas funcionais) quase sempre vencem.
Um InMemoryUserRepository que implementa a mesma interface
que PostgresUserRepository permite testar lógica de
domínio rapidamente, com comportamento real. Mocks excessivos
verificam como o código foi escrito (chamadas, ordem) em
vez de o que ele faz. Mocks são apropriados para fronteiras
de protocolo e efeitos colaterais sem outra alternativa.
E2E quanto e onde?
E2E é caro, lento e frágil — mas pega bugs que nenhum teste isolado pegaria. Use poucos, em caminhos críticos do usuário (login, checkout, ações que se erradas custam reputação ou receita). Não tente cobrir todas as variantes — isso é trabalho dos testes de integração e unidade. E2E foca em garantir que o sistema está vivo e funciona ponta a ponta.
Quando contract testing vs E2E entre serviços?
Em arquitetura de microsserviços, E2E entre todos os serviços vira inviável: combinatórias explodem, ambiente fica frágil, builds lentos. Contract testing (Pact, OpenAPI) verifica que cada serviço cumpre o contrato que outros consomem, sem precisar subir todos juntos. E2E vira último recurso, focado em fluxos críticos.
Construir uma suíte multi-camada — unidade, integração, contract, E2E — para um sistema real força você a sentir o trade-off de cada nível.
Um sistema simples (catálogo + pedido + pagamento + notificação) implementado via TDD desde o primeiro commit, com cobertura por unidade, integração (banco real em container), contract test (Pact entre serviço de pedido e pagamento), e E2E mínimo no caminho feliz. Property-based em parsers e mutation testing rodando em CI.
Repositório com README documentando cada camada de teste, qual problema ela pega, e quanto tempo leva. Mostre via screenshots de CI: unidade em segundos, integração em minutos, mutation em dezenas de minutos. O gradiente de feedback é o ponto.
Perguntas reais sobre filosofia e prática de testes. Diferenciam quem escreve testes de quem entende para que servem.
Explique o ciclo TDD. Por que escrever o teste primeiro e não depois? Qual é a parte mais negligenciada?
Qual a diferença entre mock, stub e fake? Quando você prefere cada um? Por que "mockar tudo" é antipattern?
Cobertura de testes 95% — isso significa que os testes são bons? Como você verifica a qualidade dos testes?
Você tem um teste flaky que falha 1 em cada 20 execuções. O que faz?
Em microsserviços, como garantir que mudanças em um serviço não quebram outros sem subir tudo em E2E?