Como Decidir o que Testar e o que Não Testar

O problema

Muita gente aprende teste por dois extremos ruins.

Ou escuta que precisa testar tudo. Ou escuta que teste atrasa entrega e passa a tratar isso como luxo.

As duas ideias quebram na vida real.

Testar tudo custa caro, deixa suite lenta e cria manutenção inutil. Não testar o que importa deixa o time descobrir bug serio tarde, quando o dano já saiu do editor e foi parar em produção.

A pergunta certa não e:

“Como eu aumento cobertura?”

A pergunta certa e:

“Onde uma quebra vai doer mais, aparecer tarde demais e custar caro para corrigir?”

Modelo mental

Pense em testes como distribuição de confiança.

Você não esta premiando cada linha de código com um teste. Você esta escolhendo onde quer detectar erro cedo.

Um jeito prático de decidir e olhar para quatro coisas:

1. Impacto de negócio: se isso quebrar, o usuário perde dinheiro, dado ou fluxo crítico?
2. Frequência de mudança: essa parte muda sempre e pode regredir fácil?
3. Dificuldade de perceber o erro: o bug apareceria na hora ou passaria quieto?
4. Custo da camada: da para validar isso com teste pequeno ou só com fluxo pesado?

Teste bom costuma nascer da intersecao dessas perguntas.

Quebrando o problema

Uma estratégia simples costuma funcionar melhor que um manifesto.

1. Regras de negócio merecem testes pequenos e diretos

Se o sistema calcula desconto, escolhe frete, valida limite ou decide estado de pedido, isso costuma ser barato de testar e caro de quebrar.

Esse tipo de lógica quase sempre merece teste unitario.

2. Fronteiras entre componentes merecem testes de integração

Quando o risco esta na conversa entre partes, o teste unitario sozinho não basta.

Exemplos comuns:

• controller com banco
• serviço com fila
• API com validação e persistencia
• componente com estado, rede e UI trabalhando juntos

Aqui, alguns testes de integração bem escolhidos protegem mais do que vinte testes isolando tudo com mock.

3. Fluxos criticos merecem poucos testes ponta a ponta

Checkout, login, recuperação de senha, publicação de conteúdo, renovação de assinatura.

Esses fluxos justificam e2e porque o erro atravessa várias camadas.

Mas “merece alguns” não significa “merece um e2e para cada detalhe visual”.

4. Nem tudo merece teste explícito

Coisas que normalmente não precisam de muita energia:

• getter simples
• mapeamento trivial sem regra
• comportamento obvio de framework
• repetição da mesma cobertura em tres camadas diferentes

Se a unica razão para testar e “porque existe código ali”, o critério ainda esta fraco.

Exemplo simples

Imagine um checkout com estas partes:

• calculo de desconto por cupom
• frete
• integração com gateway de pagamento
• tela final de confirmação

Uma estratégia madura poderia ser:

• unitario para calculo de desconto, total e regra de frete
• integração para garantir que pedido salvo, pagamento e atualização de status conversam direito
• e2e para um fluxo feliz de compra e um fluxo de falha de pagamento

O que provavelmente não vale tanto:

• testar cada componente visual isolado só para provar que um botao ainda renderiza
• criar dezenas de cenarios e2e para cobrir regras que já estao protegidas em teste menor
• mockar o mundo inteiro e concluir que o checkout esta seguro

Perceba o critério:

teste pequeno onde a regra mora, teste maior onde a integração pode trair, e2e só onde o negócio realmente pede.

Erros comuns

• Usar cobertura como objetivo final em vez de sinal auxiliar.
• Testar detalhe interno em vez de comportamento observável.
• Repetir o mesmo cenario em unitario, integração e e2e sem ganhar confiança real.
• Gastar energia com código trivial e deixar fluxo crítico descoberto.
• Mockar tanto que o teste para de encostar no risco real.

Como um senior pensa

Quem tem mais experiência costuma pensar em mapa de risco, não em pureza ideologica.

O raciocínio normalmente e:

“Eu quero o menor conjunto de testes que me avise cedo quando o que importa quebrar.”

Isso muda a conversa.

Em vez de testar por culpa, você testa por critério.

Em vez de cobrir tudo igual, você protege melhor o que tem impacto alto.

O que o entrevistador quer ver

Em entrevista, raramente o avaliador quer ouvir “depende” e depois silencio.

O que costuma sinalizar maturidade:

• você explicar que estratégia de teste parte de risco, não de religiao
• você diferenciar bem unitario, integração e e2e
• você defender a menor camada que gera confiança suficiente
• você saber dizer claramente o que não testaria e por que

Uma resposta forte costuma soar assim:

“Eu testo mais forte onde quebrar custa caro e onde o erro seria difícil de perceber cedo. Regras de negócio eu protejo com teste pequeno. Fronteiras eu valido com integração. Fluxo crítico eu cubro com poucos e2e.”

Testar tudo e preguiça disfarçada de rigor. Critério de risco protege mais.