Criando um ambiente de desenvolvimento mais seguro e eficiente com Playwright Visual Comparisons

Contexto e identificação do problema

• Os testes de frontend têm muitas dificuldades devido a mudanças na UI e entradas imprevisíveis dos usuários.
• Os testes validados manualmente têm limitações, então passou-se a considerar a adoção de testes automatizados.
• Os testes E2E no modelo tradicional de gravação (TestProject, Playwright) têm alto custo de manutenção e são frágeis diante de mudanças na UI.

Adoção do Playwright Visual Comparisons

• Aplicação de testes de regressão visual para detectar mudanças na UI.
• Armazenamento de screenshots de referência e comparação após alterações no código para detectar mudanças.
• Comparação de imagens possível nos modos 2-up, Swipe, Highlight e Onion Skin.

Principais problemas enfrentados na adoção e soluções

1. Falhas falsas causadas por diferenças mínimas (0,01%)
   Problema: diferenças na renderização de fontes conforme o ambiente de execução dos testes (SO, navegador, configurações de display etc.).
   Solução: uso de contêineres Docker para executar todos os testes no mesmo ambiente.

2. Necessidade de tirar a screenshot após a conclusão do carregamento dos dados
   Problema: se a screenshot for tirada antes de a página carregar completamente, a UI de loading pode aparecer na captura.
   Solução: uso de uma função utilitária com getByText + toBeVisible para aguardar até que uma determinada string apareça.

3. Diferenças nas screenshots causadas por elementos animados
   Problema: elementos de CSS animation, Canvas, SVG e WebGL são capturados em tempos diferentes a cada execução, gerando flaky test.
   Solução: diversos tratamentos para desativar animações e melhorias adicionais para aumentar a eficiência da execução dos testes.

4. Detecção desnecessária de mudanças por plugins de terceiros (iframe etc.)
   Problema: plugins de terceiros, como feedback de clientes, pesquisas e chatbots, são carregados via iframe e geram mudanças visuais.
   Solução: ao gerar a screenshot, aplicar um CSS comum para ocultar iframe e elementos de plugins específicos.

5. Falha na validação de elementos na parte inferior em páginas com rolagem
   Problema: toHaveScreenshot captura por padrão apenas a área visível no momento, exigindo tratamento relacionado ao scroll.
   Solução: aplicação da opção fullPage: true para capturar a screenshot da página inteira.

Conclusão

• Os testes de regressão visual automatizaram com eficácia a detecção de mudanças na UI.
• Não é uma solução perfeita, mas melhora tanto a produtividade do desenvolvimento quanto a estabilidade dos testes.
• São necessárias melhorias contínuas e otimização do ambiente de testes.