Quando o teste passou e a imagem continuava errada, você não está diante de um bug simples. Está diante de um sistema que aprendeu a satisfazer o que foi medido, não o que precisava estar certo em produção. Esse é o tipo de falha que separa demo de operação real: tudo parece verde no pipeline, mas o usuário continua vendo resultado quebrado.
O ponto aqui não é culpar teste automatizado, snapshot ou renderização. É entender por que um conjunto de verificações tecnicamente válido ainda deixa passar erro visível, repetível e caro. Se você está construindo produto, vendendo implementação ou operando múltiplas frentes ao mesmo tempo, precisa de um método para fechar essa lacuna entre passar no teste e funcionar de verdade.
Teste que passa sem proteger a percepção do usuário é só burocracia automatizada.
Quando o teste passou e a imagem continuava errada, o problema era o contrato
Na maioria dos casos, o erro não está na imagem em si. Está no contrato de validação. O teste confirma que um componente renderizou, que a URL existe, que o status veio 200 ou que o elemento está no DOM. Só que o usuário não consome nenhuma dessas abstrações. Ele consome resultado visual.
Esse é um erro clássico de engenharia orientada por conforto interno. O time mede o que é fácil de automatizar e assume que isso representa a experiência final. Não representa. Uma imagem pode estar carregando a partir do endpoint certo e ainda assim aparecer cortada, desatualizada, com proporção errada, cache antigo, fallback indevido ou mapeamento incorreto entre ambiente e asset.
Quando isso acontece, muita gente diz que “faltou um teste”. Às vezes faltou, mas muitas vezes faltou outra coisa: definição operacional de correto. Se correto significa “tag img existe”, o sistema vai entregar isso. Se correto significa “o usuário vê a versão certa, no contexto certo, com recorte certo e sem regressão visual”, o teste precisa ser desenhado para isso.
Em B2B técnico, esse detalhe vira custo rápido. Seu cliente não quer saber se a suite de testes passou. Ele quer saber por que a interface segue errada mesmo com pipeline verde. E a resposta brutalmente honesta é simples: porque o sistema foi validado por um contrato fraco.
Imagem errada mesmo com teste verde: por que a cobertura engana
Cobertura alta não é sinônimo de proteção alta. Esse é um dos mitos mais persistentes em times que cresceram rápido. Você pode ter cobertura de linha, de branch e de integração, e ainda assim não capturar o que de fato quebra a experiência. O número sobe, a confiança sobe junto, mas a realidade não acompanha.
No caso de imagem errada, isso aparece muito em três cenários. Primeiro: testes verificam presença, não semântica. Segundo: o ambiente de teste não replica a cadeia real de CDN, cache e transformação. Terceiro: o dado usado no teste é estável demais e não expõe os casos em que a produção falha. O sistema passa porque foi treinado a passar naquele recorte estreito.
Esse tipo de ilusão é perigoso porque cria um falso senso de maturidade. O dashboard mostra sucesso, o deploy segue, o comercial promete estabilidade, e o suporte recebe ticket minutos depois. Não é falta de capacidade técnica. É falta de observabilidade orientada ao efeito.
Em operação real, o que interessa não é só “o componente renderiza”, mas “qual imagem foi servida, por qual origem, com qual transformação, em qual viewport e com qual consistência entre ambientes”. Sem isso, cobertura vira vaidade técnica. E vaidade técnica costuma ser cara.
Como diagnosticar quando a imagem continua errada depois dos testes
Se você quer sair do ciclo de corrigir sintoma, precisa decompor a cadeia inteira. Imagem errada raramente nasce em um ponto só. Ela emerge da interação entre dado, template, transformação, cache, client-side hydration e regra de fallback. O diagnóstico bom não começa no componente. Começa no fluxo.
Na prática, eu trataria isso como incidente de sistema, não como bug isolado de front-end. A pergunta correta não é “onde a imagem quebrou?”. É “em qual etapa a definição de imagem correta se perdeu?”. Essa mudança de pergunta encurta muito o caminho.
- Mapeie. Liste a trajetória completa do asset: origem, transformação, armazenamento, entrega e renderização final.
- Compare. Rode a mesma entrada em ambiente local, staging e produção para identificar divergência de comportamento.
- Logue. Registre URL final, headers de cache, versão do asset, dimensões retornadas e fallback acionado.
- Visualize. Gere evidência visual da renderização final em viewport real, não só assert de DOM.
- Isole. Troque entradas dinâmicas por fixtures controladas para descobrir se a falha está no dado ou na exibição.
Esse processo parece básico, mas quase ninguém faz com disciplina. Muita equipe pula direto para patch porque está pressionada por prazo. Aí resolve o caso atual e preserva a arquitetura que vai produzir o próximo. Diagnóstico bom é mais lento nas primeiras horas e muito mais rápido nas próximas semanas.
Se você opera código e negócio ao mesmo tempo, isso importa ainda mais. Porque cada regressão visual que passa no teste consome confiança do cliente, tempo do time e margem da operação. O erro técnico se transforma em ruído comercial.
Teste visual, teste funcional e a falha entre os dois
Existe uma diferença importante entre teste funcional e teste perceptivo. O funcional responde se a aplicação executou um comportamento previsto. O perceptivo responde se o resultado final continua fazendo sentido para o usuário. Quando a imagem está errada, normalmente o primeiro passou e o segundo nem foi modelado.
Esse vazio aparece porque muitos times tratam interface como consequência cosmética do sistema, quando na prática ela é parte central da entrega. Se seu produto vende interface, documento, catálogo, dashboard, vitrine ou conteúdo, então o visual não é detalhe. É saída de negócio.
Por isso, vale combinar níveis diferentes de proteção. Teste unitário para regra, integração para fluxo, e uma camada de verificação visual para estado crítico. Não precisa transformar tudo em screenshot test. Isso seria outro erro. Mas pontos sensíveis, como renderização de imagem, transformação responsiva, crop automático e fallback de mídia, precisam de prova visível.
Aqui entra a honestidade que falta em muito conteúdo sobre engenharia: não existe suite perfeita. Sempre haverá escape. O que muda times maduros é que eles assumem isso e desenham defesa em profundidade. Não vendem a fantasia de que pipeline verde significa verdade absoluta.
O método para impedir que o teste passe e a imagem siga errada
Se eu tivesse que resumir o método, seria assim: defina o que é correto do ponto de vista do usuário, traduza isso em contrato testável e monitore o efeito em produção. Sem essas três camadas, você só empurra risco de fase em fase.
Na definição, seja específico. “Imagem correta” é vago. “Thumbnail do produto certo, com proporção 4:5, sem fallback genérico, com atualização em até X minutos após mudança de catálogo” é operacional. Esse tipo de precisão muda completamente o que precisa ser testado.
Na tradução para teste, evite confiar em um único tipo de evidência. Combine assert de origem do asset, regra de transformação, estado do componente e checagem visual nos fluxos críticos. E, principalmente, trate dados de teste como parte do produto. Fixture pobre produz confiança pobre.
Na produção, monitore o que realmente importa. Capture amostras visuais, divergências entre asset esperado e entregue, incidência de fallback, tempo de propagação de cache e erro por contexto de dispositivo. Quando esse tipo de telemetria entra na rotina, o time para de discutir opinião e começa a operar em cima de sinal real.
É isso que diferencia builder de comentarista. Builder não fala que “tem testes”. Builder mostra qual contrato protege o resultado, onde o sistema ainda falha e como a observabilidade fecha o ciclo. Se o teste passou e a imagem continuava errada, a correção não é escrever mais qualquer teste. É subir o nível de precisão do sistema inteiro.
Perguntas frequentes sobre O teste passou e a imagem continuava errada
Por que o teste passa se a imagem está visivelmente errada?
Porque o teste pode estar validando um contrato fraco, como presença do elemento ou retorno 200. Isso não garante que o usuário receba o asset correto, com recorte, versão e contexto certos.
Snapshot test resolve imagem errada em produção?
Resolve alguns casos, mas não todos. Snapshot ajuda a detectar regressões visuais previsíveis, porém não cobre sozinho problemas de cache, CDN, transformação de mídia ou dados inconsistentes entre ambientes.
Como saber se o problema está no front-end ou na entrega do asset?
Você precisa mapear a cadeia completa: origem, transformação, cache, entrega e renderização. Sem esse rastreio, o time tende a culpar o componente quando a falha pode estar antes dele.
Vale a pena adicionar teste visual em todo o sistema?
Não. O melhor caminho é aplicar teste visual nos fluxos em que a saída visual é crítica para negócio ou confiança do usuário. Cobrir tudo costuma gerar custo alto e ruído demais.
Qual métrica acompanha melhor esse tipo de falha?
Mais do que cobertura, acompanhe divergência entre asset esperado e asset entregue, uso de fallback, tempo de propagação de atualização e incidência por viewport ou contexto de dispositivo. Essas métricas mostram efeito real.