Testes de snapshot e golden file: como mantê-los confiáveis

O que é

Um teste de snapshot (ou golden file) serializa uma saída, como um componente renderizado, a resposta de uma API, a stdout de um comando ou um arquivo gerado, e a compara com uma referência armazenada. Na primeira execução a referência é gravada; depois disso, qualquer diferença faz o teste falhar. A documentação do Jest descreve o toMatchSnapshot() gravando em um arquivo .snap, dentro de um diretório __snapshots__ ao lado do teste, além de snapshots inline escritos de volta no código-fonte do teste, do --updateSnapshot para regenerar as referências após uma mudança intencional e da regra de que, no CI, novos snapshots não são gravados automaticamente sem essa flag. O insta, do Rust, segue o mesmo padrão: gera arquivos .snap.new, que são aceitos por meio de cargo insta review, e oferece redactions para campos voláteis.

Por que importa

Para saídas com muitos detalhes, asserções escritas à mão verificam alguns campos e deixam o resto de fora; o snapshot verifica tudo, ao custo de não expressar nenhuma intenção. Ele transforma a pergunta "algo mudou?" em um diff que o revisor consegue ler, e é justamente disso que se precisa para formatos de saída, mensagens de erro e artefatos gerados. Bem usados, os snapshots são testes de caracterização de formatos; mal usados, viram uma pilha de diffs aceitos que ninguém lê.

Como aplicar

• Faça snapshot de saídas que são contratos: formato de respostas, configuração gerada, texto de ajuda, mensagens de erro. Mantenha cada snapshot curto e focado; a documentação do Jest recomenda snapshots pequenos e nomes descritivos, para que o revisor possa julgar pelo nome se o conteúdo armazenado está correto.
• Normalize os dados voláteis antes de serializar: timestamps, ids gerados, ordem de coleções não ordenadas, caminhos absolutos. O Jest oferece property matchers como expect.any(Date); o insta oferece redactions.
• Revise os diffs de snapshot no pull request como se fossem código. A documentação do Jest alerta contra o hábito de regenerar snapshots quando as suítes falham, em vez de investigar a causa.
• Atualize de forma seletiva, por padrão de nome de teste ou de modo interativo, em vez de fazer uma atualização geral após uma falha não relacionada.
• Faça commit dos arquivos de snapshot e configure o CI para falhar quando eles estiverem ausentes ou obsoletos.

Armadilhas

Um snapshot que muda em todo pull request deixou de testar qualquer coisa e acostuma as pessoas a aceitar às cegas. Snapshots de páginas inteiras acoplam o teste a componentes que não têm relação com ele. Um snapshot registra a saída atual, não a correta: um bug capturado na primeira execução continua aprovado até que alguém leia o arquivo. Locale, quebras de linha e formatação de ponto flutuante fazem os snapshots diferirem entre máquinas. Um snapshot não substitui uma asserção que declara o requisito.