Teste Superespecificado.

Você reconhece um teste superespecificado pelo que o quebra: uma refatoração inofensiva ou uma mudança incidental faz os testes falharem mesmo que o comportamento que descrevem ainda esteja correto.

Sinais comuns:

• Asserções sobre detalhes irrelevantes. Espaços em branco/markup exatos, strings completas de mensagens de erro, texto de log, formatação ou valores voláteis como timestamps, UUIDs e ids autoincrementados.
• Igualdade de objeto inteiro quando importa um único campo. toEqual({...o objeto inteiro...}) quando o teste, na verdade, trata de uma única propriedade.
• Asserções sensíveis à ordem em dados logicamente sem ordem. Fixar a ordem de um conjunto, das chaves de um mapa ou de resultados de consulta que o contrato não garante.
• Verificação de comportamento de colaboradores internos. Mocks que asseguram contagens exatas de chamadas, valores argumento por argumento e a ordem das chamadas de dependências internas em vez do resultado final observável.
• Snapshots gigantes que capturam uma árvore renderizada inteira ou um corpo de resposta, de modo que qualquer mudança aninhada força uma regravação.
• Mexer na implementação. Consultar estado privado ou estrutura do DOM (container.querySelector, campos internos) em vez do comportamento público e observável pelo usuário.

// Superespecificado: fixa markup exato, um timestamp volátil e cada chamada de colaborador
test('renders user badge', () => {
  const html = renderBadge(user);
  expect(html).toBe('<span class="badge badge--admin">Ada Lovelace</span>'); // markup exato
  expect(analytics.track).toHaveBeenCalledTimes(1);                          // contagem de chamadas internas
  expect(analytics.track).toHaveBeenCalledWith('badge_render', { ts: 1718445693221 }); // volátil
});

Um teste decisivo útil: se você consegue alterar a implementação sem mudar o comportamento documentado e o teste ainda falha, ele está superespecificado.

Por que acontece

• Uma mentalidade de "mais asserções = mais minucioso": os desenvolvedores fixam tudo o que conseguem ver, confundindo completo com correto.
• O ferramental torna a superespecificação o caminho de menor resistência: toMatchSnapshot() registra toda a saída, e os frameworks de mocking tornam trivial asserir cada interação (toHaveBeenCalledWith, ordem das chamadas, contagens).
• Copiar e colar um literal de objeto real dentro de toEqual em vez de asserir apenas o campo de que o teste trata.
• Testar por meio de ganchos de implementação convenientes (nós do DOM, campos privados) em vez do contrato público.

Por que isso prejudica

No xUnit Test Patterns, de Gerard Meszaros, essa é a causa raiz por trás do smell Teste Frágil (Fragile Test), atribuído a Software Superespecificado e Sensibilidade a Comportamento: os testes ficam acoplados a como o código funciona em vez de o que ele produz, então falham diante de mudanças que não afetam o comportamento.

• Manutenibilidade. Cada refatoração dispara uma cascata de falhas de teste não relacionadas, tornando a suíte cara de manter verde e desencorajando ativamente a refatoração.
• Confiabilidade / confiança. Testes que "dão alarme falso" em código correto treinam o time a ignorar ou regravar cegamente as falhas (especialmente com snapshots).
• Falsa confiança. A superespecificação costuma coexistir com a sub-asserção do resultado significativo: um teste pode fixar um timestamp e uma linha de log mas nunca verificar o valor com que o usuário realmente se importa. Como diz a literatura de teste de interação, a superespecificação é "verificar coisas que não fazem parte do resultado final"—na maioria das vezes asserindo interações em vez de resultados.
• Legibilidade. Uma parede de asserções incidentais obscurece o único comportamento que o teste deveria documentar.

Afirme apenas o que o comportamento sob teste exige—e prefira verificar o resultado final em vez das interações internas.

1. Nomeie o único resultado que o teste documenta e afirme apenas isso, nada mais. Divida resultados genuinamente distintos em testes separados e bem nomeados, em vez de uma megaasserção.
2. Use matchers parciais/flexíveis em vez da igualdade exata de objeto inteiro: expect.objectContaining, toMatchObject, arrayContaining, stringContaining/stringMatching e expect.any(...) para campos que você não pode ou não deve fixar.
3. Neutralize dados voláteis (timestamps, ids, valores aleatórios) com matchers de propriedade (expect.any(String)) ou injetando um relógio/gerador de id fixo—não deixe o valor de hoje hard-coded.
4. Abandone suposições de ordem para dados sem ordem: afirme a pertinência (arrayContaining) ou ordene antes de comparar.
5. Prefira verificação de estado à verificação de comportamento. Faça stub das consultas (não afirme sobre elas); só verifique a chamada de um colaborador quando essa chamada for o efeito colateral observável (um comando), e evite asserir contagens/ordem exatas de colaboradores puramente internos.
6. Mantenha os snapshots pequenos e intencionais, ou substitua um snapshot extenso por algumas asserções direcionadas. Consulte pela API voltada ao usuário (por exemplo, getByRole/getByText da Testing Library) em vez de acessar container/nós do DOM.

Antes → depois:

// Antes: acopla o teste a campos voláteis e à sequência de chamadas internas
expect(result).toEqual({
  id: '8f3c-92a1-...',                  // uuid aleatório
  createdAt: '2026-06-15T10:01:33.221Z',// Date.now()
  name: 'Ada Lovelace',
  role: 'admin',
});
expect(logger.info).toHaveBeenCalledTimes(3);
expect(db.connect).toHaveBeenCalledBefore(db.query);

// Depois: afirme apenas o comportamento de que este teste trata
expect(result).toMatchObject({ name: 'Ada Lovelace', role: 'admin' });
// id/createdAt são incidentais; logging e ordem das chamadas são detalhes de implementação — não os fixe