Fundamentos6 min de leitura

O que testar (e o que não testar)

Um jeito baseado em risco de decidir onde os testes compensam e onde só atrasam você.

Mais testes não é o objetivo. O objetivo é confiança por unidade de esforço. O trabalho é gastar o orçamento de testes onde um bug doeria mais e onde um teste é mais barato de manter verde.

Comece pelo risco, não pela cobertura

A cobertura diz que código rodou durante os testes, não se o comportamento importante está protegido. Faça duas perguntas sobre cada comportamento: qual a chance de quebrar e qual o tamanho do estrago se quebrar? O que pontua alto nas duas merece teste primeiro.

Valor alto, risco alto: contas com dinheiro, autenticação, integridade de dados, qualquer coisa irreversível. Teste a fundo.
Valor alto, risco baixo: fluxos centrais estáveis. Cubra com poucos testes de alto nível.
Valor baixo, muita mudança: interface cosmética, textos. Apoie-se nos tipos e em um teste de fumaça.
Valor baixo, risco baixo: getters, ligação com o framework. Em geral, deixe de fora.

Teste o comportamento, não a implementação

Um bom teste descreve o que o código deve fazer, visto de fora. Se renomear um método privado ou refatorar por dentro quebra o teste mesmo sem mudar o comportamento, o teste estava preso à implementação, e vai custar caro a cada refatoração.

// ❌ Preso a um detalhe de implementação
expect(cart._items.length).toBe(2);

// ✅ Confere o comportamento observável
expect(cart.total()).toBe(42.0);
expect(cart.itemCount()).toBe(2);

Dica: Uma regra prática: uma reescrita competente deste módulo, com o mesmo contrato público, ainda passaria neste teste? Se não, você está testando a implementação.

O que em geral não vale testar

Os detalhes internos de bibliotecas de terceiros: confie na suíte delas e teste o seu uso.
Código trivial que só repassa dados, sem desvio nem lógica.
Código gerado e declarações só de tipo.
A posição exata de cada pixel: prefira capturas de regressão visual a asserções frágeis.

Depois treine a habilidade inversa, escrever o teste mínimo que guia uma mudança, no playground de TDD, onde o ciclo vermelho, verde, refatorar obriga você a testar um comportamento por vez.

Pratique isto

Leia a seguir

Comece pelo risco, não pela cobertura

Valor alto, risco alto: contas com dinheiro, autenticação, integridade de dados, qualquer coisa irreversível. Teste a fundo.

Valor alto, risco baixo: fluxos centrais estáveis. Cubra com poucos testes de alto nível.

Valor baixo, muita mudança: interface cosmética, textos. Apoie-se nos tipos e em um teste de fumaça.

Valor baixo, risco baixo: getters, ligação com o framework. Em geral, deixe de fora.

Teste o comportamento, não a implementação

// ❌ Preso a um detalhe de implementação expect(cart._items.length).toBe(2); // ✅ Confere o comportamento observável expect(cart.total()).toBe(42.0); expect(cart.itemCount()).toBe(2);

Dica: Uma regra prática: uma reescrita competente deste módulo, com o mesmo contrato público, ainda passaria neste teste? Se não, você está testando a implementação.

O que em geral não vale testar

Os detalhes internos de bibliotecas de terceiros: confie na suíte delas e teste o seu uso.

Código trivial que só repassa dados, sem desvio nem lógica.

Código gerado e declarações só de tipo.

A posição exata de cada pixel: prefira capturas de regressão visual a asserções frágeis.

Depois treine a habilidade inversa, escrever o teste mínimo que guia uma mudança, no playground de TDD, onde o ciclo vermelho, verde, refatorar obriga você a testar um comportamento por vez.