Alta cobertura no relatório não significa confiança real para mudar. Time com 80% de cobertura e medo de deploy na sexta-feira tem problema de estratégia, não de cobertura. Testes concentrados no lugar errado da pirâmide entregam aparência de segurança com feedback lento. Testes frágeis que quebram por mudança de implementação sem mudança de comportamento criam falso alarme que o time aprende a ignorar. Quando o pipeline está sempre quebrado, o pipeline deixa de ser sinal confiável.
Subcapability 04 de 05 · Software Engineering & Architecture
Testing Strategy
Estratégia de testes calibrada por risco, custo e velocidade que substitui pirâmide invertida por distribuição que dá confiança real para mudar e elimina a cerimônia do medo.
O que está em jogo
O pipeline sempre quebra por razão diferente. Os testes travam o CI por horas antes de mostrar resultado. Quando um bug chega à produção, a pergunta é por que o teste não capturou. E a resposta é sempre: o teste que capturaria esse caso nunca foi escrito. A estratégia de testes cresceu por acumulação, sem critério de onde cada tipo de teste agrega mais valor.
O que é, na prática
Como atuamos
Pirâmide calibrada por risco e velocidade
Definimos a distribuição de testes por camada com critério explícito: unitários rápidos para lógica de negócio isolada, integração para boundaries entre componentes, E2E restrito aos fluxos críticos de maior custo de falha. Cada camada tem responsabilidade clara e não substitui as outras.
TDD como ferramenta de design
Estabelecemos TDD para código novo em lógica de negócio complexa, onde escrever o teste antes guia a interface e a separação de responsabilidades. O resultado é código mais testável e design emergente por restrição do teste.
Consumer-Driven Contracts para microservices
Implementamos contratos via Pact para validar a interface entre serviços independentemente. O consumidor define suas expectativas em contrato. O provedor verifica que atende essas expectativas sem deploy conjunto. Mudanças de API com impacto são detectadas antes da integração.
Mutation Testing para validar a suite
Executamos Mutation Testing para verificar se os testes existentes detectam defeitos reais ou apenas cobrem linhas. Mutantes que sobrevivem revelam lacunas na suite que cobertura de linha não mostra.
Indicadores de confiança no pipeline
Medimos frequência de deploy e Change Failure Rate como proxy da confiança real do time nos testes. Time que não confia no pipeline não deploya com frequência. Time que deploya frequentemente sem incidente tem estratégia funcionando.
Ganhos mensuráveis
O que muda no resultado quando essa subcapacidade amadurece.
Tempo de execução do pipeline de CI end-to-end
Distribuição correta da pirâmide, com a maioria dos testes sendo unitários rápidos, reduz o tempo de feedback do pipeline. CI que rodava horas por excesso de E2E pesa menos quando cada camada cobre o que lhe cabe.
Frequência de deploy em produção por semana
Time que confia na suite de testes deploya com maior frequência. Confiança real muda o comportamento: menos acumulação de mudança em batch, menos risco por release, mais ciclos de feedback com o usuário real.
Change Failure Rate (taxa de mudanças que causam incidente)
Estratégia de testes calibrada por risco reduz a proporção de mudanças que chegam à produção com defeito. O custo de cada incidente evitado é mensurável em tempo de engenharia de remediação e em impacto ao usuário.
Custo de bug detectado em desenvolvimento versus em produção
Cada defeito capturado no pipeline custa uma fração do mesmo defeito após impactar usuário. Testes nos pontos certos da pirâmide movem a descoberta para onde o custo de correção é mínimo.
Perguntas frequentes
Qual a diferença entre Pirâmide de Testes e Testing Trophy?
A Pirâmide de Testes enfatiza unitários na base porque são rápidos e isolados. O Testing Trophy, proposto por Kent C. Dodds, desloca o peso para testes de integração porque em muitas aplicações modernas a falha real acontece na fronteira entre componentes, não na lógica isolada de uma função. A escolha entre os dois depende de onde os defeitos reais do seu sistema aparecem com mais frequência.
TDD vale para todo tipo de código?
TDD entrega mais valor em lógica de negócio complexa onde o teste guia o design e a interface. Em código de infraestrutura, configuração ou glue code simples, o custo de manter o ciclo de test-first supera o benefício de design emergente. A pergunta certa é: onde a clareza da interface importa mais? Nesses pontos, TDD justifica o custo.
O que é Consumer-Driven Contract Testing e quando usar?
Consumer-Driven Contract Testing formaliza o que cada consumidor de um serviço espera da sua API em um contrato versionado. O provedor verifica continuamente que atende esses contratos sem precisar de ambiente integrado. O padrão resolve o risco específico de microservices: mudança no provedor que quebra o consumidor sendo descoberta apenas no ambiente de integração ou em produção.
Como Mutation Testing difere de cobertura de código?
Cobertura de código mede quantas linhas o teste executa. Mutation Testing mede se o teste detectaria uma falha real. O framework introduz pequenas mutações no código (troca de operador, remoção de condição) e verifica se algum teste falha. Mutante que sobrevive indica que aquela linha é executada pelo teste mas o comportamento incorreto não seria detectado.
Como convencer o time de que testes lentos no CI são problema de estratégia?
Com o custo em tempo de engenharia: CI de 90 minutos em time de 20 pessoas que faz 5 commits por dia consome 150 horas por semana esperando feedback. Parte desse custo desaparece quando a distribuição da pirâmide é corrigida, com unitários em segundos cobrindo a maioria dos casos e E2E restrito aos fluxos críticos. O dado de tempo economizado por semana é o argumento que fecha a discussão.
Outras subcapabilities desta capability
Arquitetura Evolutiva
ADRs e fitness functions que registram decisões caras de reverter e validam conformidade automaticamente, mantendo o custo de cada mudança dentro de limites que o negócio consegue absorver.
Domain-Driven Design
Linguagem ubíqua e bounded contexts do Domain-Driven Design que alinham modelo de software ao modelo de negócio e eliminam a camada de tradução onde retrabalho e custo se acumulam.
Clean Architecture & Patterns
Clean Architecture com Dependency Rule que isola regras de negócio de frameworks, banco e UI, reduzindo custo de troca de tecnologia de projeto de seis meses para sprint.
Code Quality & Craft
Technical Debt Ratio mensurável e Quality Gates reais que mantêm velocidade de entrega sustentável e impedem que dívida técnica silenciosa vire congelamento de evolução.
Quer clareza sobre onde investir primeiro?
Diagnóstico completo de capacidades de tecnologia com roadmap de evolução conectado ao resultado financeiro.