BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Notícias É possível escrever testes para CSS! Gil Tayar no ReactiveConf 2019

É possível escrever testes para CSS! Gil Tayar no ReactiveConf 2019

Favoritos

Gil Tayar, arquiteto sênior e desenvolvedor da Applitools, apresentou no ReactiveConf 2019 os problemas específicos inerentes dos testes de CSS e como podem ser abordados por meio de metodologia e ferramentas.

Tayar começou enfatizando uma tendência que se fortaleceu muito nos últimos cinco anos na área de desenvolvimento frontend, que é os desenvolvedores escrevem os próprios códigos de testes automatizados. Um dos principais motivos dessa tendência é a confiança que os testes fornecem ao adicionar, remover ou refatorar o código. Nos últimos anos, o frontend desenvolveu vagarosamente, metodologias baseadas em testes de unidade, de componentes e multi-componentes (usando o JSDOM, por exemplo) e testes de automação baseados no navegador (com ferramentas como Cypress ou webdriverio).

No entanto, os desenvolvedores frontend ainda não sabem como escrever testes automatizados para CSS, recorrendo a testes manuais ou mesmo ignorando totalmente os testes de CSS. Contudo, esse teste é essencial para automatizar testes de interfaces responsivas. Uma boa técnica para testes, é o teste funcional, que nada mais é que testar uma saída produzida pela inserção de entradas em uma função, no entanto, essa não é uma opção para o CSS. Taylar afirmou que testar o CSS é uma tarefa difícil, porque por ser de natureza visual, não é funcional. A tarefa de testar o CSS pode então ser reformulada em um problema de teste visual, e Tayar prosseguiu com uma lista de metodologias, técnicas e ferramentas para solucionar o problema de testes visuais.

Tayar explicou que a metodologia dos sonhos consiste em navegar em uma página, tirar um print screen, verificar se a imagem tem uma boa aparência ou se está de acordo com algum sistema de design. Esse processo semelhante a um problema de reconhecimento de padrões que poderia ser tratado por meio de técnicas de machine learning, mas, como lamentou Tayar, os algoritmos de machine learning ainda não são bons o suficiente para isso. A estratégia de mitigação sugerida por Tayar é substituir o teste visual por um teste de regressão visual.

O código a seguir ilustra a metodologia (usando o módulo cy do Cypress):

it ('home page visual test'), () => {
  // pick up a view port dimension
  cy.viewport(1024, 768);
  // navigate to the page
  cy.visit('http://localhost:3000');
  // Bring the interface to some state by simulating some user actions
  cy.get('#searchBar').type('test');
  // Take a screenshot and compare it to the previously validated baseline screenshot
  cy.matchImageSnapshot('home-page');
}

A ideia é começar com uma captura de tela validada (geralmente manual) e testar se o que era, ainda continua sendo. As diferenças são detectadas de maneira automática e o testador aceita ou rejeita as diferenças manualmente. A intervenção manual do testador é necessária, pois o programa de testes não sabe se a nova captura de tela é o resultado de novos recursos, ou seja, uma captura de tela válida e esperada. O testador deve portanto invalidar manualmente o screenshot inicial quando for o caso. Desde que os falsos negativos não sejam frequentes (ou seja, as modificações do programa não resultem sistematicamente na invalidação de capturas de tela anteriores), essa metodologia oferece progresso em relação ao uso de testes visuais inteiramente manuais.

Tayar, no entanto, mencionou quatro pontos importantes em relação a metodologia anterior. Antes de tudo, tirar uma print screen envolve solucionar a heterogeneidade dos ambientes em execução. O Cypress no Chrome permite que os desenvolvedores façam capturas de tela, de uma janela, de uma página inteira, de uma área selecionada ou região. O Selenium ou o webdriver propõem apenas a captura de tela de forma nativa da janela de um navegador. O primeiro problema pode ser solucionado alterando as ferramentas quando necessário e quando for possível, ou recorrendo às ferramentas comerciais existentes que fornecem as opções de captura de tela necessárias. Tais ferramentas, produzem uma captura de tela para uma página que começa com a janela visível e então rolam até o final dela, juntando todas as imagens em uma.

Comparando as capturas de tela, o segundo problema é difícil. A abordagem ingênua, de comparação pixel a pixel, geralmente não fornece resultados confiáveis ​​o suficiente. O que parece ser a mesma imagem para um ser humano será, de fato, objetos de imagem diferentes para o computador, pois os pixels exatos representados podem variar de acordo com a placa gráfica utilizada ou com a utilização de um aliasing. Tayar exemplificou que a mesma imagem jpeg no Chrome 67 e no Chrome 68, possui diferenças significativas quando comparadas pixel a pixel, ele ainda apresentou outro exemplo da mesma interface na mesma máquina, exibido duas vezes no mesmo navegador, com um intervalo de cinco minutos, e que também apresentou importantes diferenças a nível de pixels.

Uma estratégia para atenuar este problema é configurar manualmente um limite de diferença aceitável. A principal questão que explique o motivo de pequenas diferenças de cor (normalmente não perceptíveis ao olho humano) ou o conceito de alias. O limite deve, portanto, ser ajustado regularmente para reduzir significativamente a quantidade de falsos negativos. Como antes, existem ferramentas que resolvem este problema de maneira mais sofisticada, aplicando algoritmos avançados de comparação que tentam ver as imagens da maneira que um ser humano faria. Tayar enfatizou que essas ferramentas são o avanço mais significativo que o campo de testes visuais registrou nos últimos anos. A maioria das ferramentas possui planos gratuitos e planos OSS e como tal, podem ser usados ​​por desenvolvedores em uma ampla variedade de contextos de projetos.

O terceiro problema está relacionado ao gerenciamento das comparações de screenshots. Como mencionado anteriormente, o teste de regressão visual inclui uma parte manual na qual os desenvolvedores invalidam uma captura de tela anterior. Esse manuseio pode se tornar complicado quando há centenas de comparações para serem revisadas. Tayar forneceu três estratégias de mitigação para aliviar o problema. Uma estratégia consiste em invalidar uma grande série de capturas de tela através da linha de comando (com Cypress, isso seria npm run cypress: run - --env updateSnapshots = true ). Uma segunda estratégia consiste em percorrer os diretórios em que os snapshots estão armazenados e substituir os atuais pelos novos, quando necessário, removendo os falsos negativos. A terceira estratégia envolve o uso de ferramentas comerciais que geralmente incluem um painel para acelerar a invalidação manual, com níveis configuráveis ​​de granularidade.

A quarta questão se origina da necessidade de testar todas as larguras responsivas (como 1024x768, iPhone, iPad), densidades de pixel (Retina e Desktop) e navegadores. Mais uma vez, existem três maneiras de resolver o problema. A primeira solução óbvia, é executar o mesmo teste visual várias vezes para cada configuração de largura/densidade/navegador. A segunda solução seria a primeira melhorada, paralelizando os testes. Embora isso possa exigir uma infraestrutura mais complexa, muitas empresas usam a técnica. A última solução consiste novamente em terceirizar o teste para provedores de serviços de testes na nuvem.

Tayar concluiu a palestra conduzindo o público através de uma demonstração ao vivo de testes de regressão visual, ilustrando algumas das soluções para os quatro problemas descritos anteriormente.

O ReactiveConf é uma conferência anual voltada para desenvolvedores, com palestras abordando as mais recentes tecnologias e tendências no desenvolvimento de software. O ReactiveConf 2019 ocorreu entre os dias 30 de outubro a 1 de novembro de 2019 e está em sua quinta edição.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT