O que é um teste de regressão visual? Detectando mudanças de UI não intencionais
Um teste de regressão visual captura uma screenshot da UI e a compara pixel a pixel com uma baseline aprovada, sinalizando qualquer mudança visual inesperada.
Os testes funcionais confirmam o comportamento, mas deixam passar quebras visuais: um botão desalinhado ou uma cor errada ainda passa em um teste de clique. Um teste de regressão visual renderiza a UI, captura uma screenshot e faz o diff dela contra uma imagem baseline. Qualquer diferença é apresentada para revisão. Como as screenshots são sensíveis ao ambiente, executá-las de forma confiável é, em grande parte, um problema de consistência do CI.
Como funciona
O teste renderiza um componente ou página, captura uma screenshot e a compara com uma baseline armazenada. Se os pixels diferirem além de um limiar, o teste falha e mostra o diff para que um humano possa aprovar ou rejeitar a mudança.
Baselines e aprovação
A baseline é a aparência correta acordada. Quando uma mudança é intencional, você atualiza a baseline; quando não é, você corrige o código. Gerenciar baselines é o workflow central do teste visual.
O desafio da instabilidade
- A renderização de fontes difere entre sistemas operacionais.
- Animações e temporização causam capturas instáveis.
- Dados dinâmicos como datas alteram a imagem.
Combinando com o Storybook
As stories são estados determinísticos de componentes, o que as torna entradas ideais para testes visuais. Muitas equipes fazem snapshot de cada story para que cada estado de componente tenha uma baseline protegida.
Testes de regressão visual no CI/CD
Esses testes são executados no pipeline contra um app compilado ou o Storybook, então a consistência é tudo: fontes ou tamanhos de tela diferentes entre o local e o CI produzem diffs falsos. Executar as capturas em runners estáveis e idênticos mantém as baselines confiáveis. Runners gerenciados (como o Latchkey) fornecem esse ambiente consistente para que os diffs de screenshot reflitam mudanças reais, e não ruído do runner.
Principais conclusões
- Um teste de regressão visual faz o diff de screenshots da UI contra uma baseline aprovada.
- O gerenciamento da baseline é o workflow central; mudanças intencionais atualizam a baseline.
- Runners de CI consistentes são essenciais para evitar diffs falsos causados por diferenças de renderização.