O que é o teste de regressão visual? Capturas de ecrã como asserções

O teste de regressão visual tira uma captura de ecrã da sua interface, compara-a com uma aprovada anteriormente e falha quando mudaram píxeis que ninguém concordou em mudar. É o único tipo de teste que apanha uma alteração à folha de estilos que desloca um botão quatro píxeis para a esquerda, porque isso não é um comportamento que alguma asserção alguma vez fosse descrever.

Tudo o resto decorre de um facto incómodo: uma captura de ecrã não é determinista, e um teste que não é determinista acaba por ser ignorado.

O que uma execução produz

Três imagens por verificação, e a terceira é a única que alguém olha.

• A baseline - a captura aprovada, guardada no repositório ao lado do código.
• A candidata - o que a interface desenha agora.
• O diff - as duas sobrepostas, com os píxeis alterados marcados.

Uma verificação passa quando a candidata corresponde à baseline, e falha caso contrário. Falhar não é o mesmo que estar errado: um redesenho deliberado faz falhar todas as verificações que toca, e a correção é aprovar as novas capturas como baselines. É nesse passo de aprovação que está o trabalho a sério.

As falhas que não são falhas

Quase tudo o que aqui é difícil são falsos positivos, e vêm de uma lista curta das mesmas causas.

• O antialiasing e o desenho dos tipos de letra. O mesmo texto em duas máquinas, ou com dois controladores gráficos, não são os mesmos píxeis.
• Tudo o que mostre a hora atual. Uma data e hora, um “há 3 dias”, um ano de copyright.
• Dados dinâmicos. Uma lista ordenada por data, um nome tirado ao acaso de uma fixture, um número que cresce.
• Animações e transições. Uma captura tirada a meio de uma transição é cara ou coroa.
• Tipos de letra que chegam tarde. A captura é tirada antes de a webfont carregar, por isso a baseline tem uma tipografia e a candidata outra.
• As barras de deslocamento. Diferentes de sistema operativo para sistema operativo, e muitas vezes dentro da área capturada.

Cada uma tem uma correção aborrecida: congelar o relógio, substituir os dados por dados fixos, desligar as animações, esperar que os tipos de letra assentem e fazer todas as capturas num único ambiente controlado em vez de na máquina que estiver livre. O Docker é a resposta habitual ao último ponto, e é de longe a maior fonte de ruído se o saltar.

Ou seja, uma suite visual é um problema de testes flaky com outro chapéu. Aplica-se a mesma regra: uma verificação que falha por razões alheias ao código deixa de ser lida, e uma suite que ninguém lê é pior do que suite nenhuma, porque continua a custar o tempo.

Os limiares são o primeiro instinto errado

A resposta óbvia ao ruído é permitir que uma percentagem de píxeis difira. Funciona, e é também como passa um defeito a sério.

Fraco

Falhar se mais de 0,5 % dos píxeis diferirem - que é espaço mais do que suficiente, numa página grande, para um botão se deslocar, um preço mudar ou a etiqueta de um campo desaparecer

Melhor

Tolerância zero, com regiões excluídas pelo nome: o relógio no cabeçalho, o avatar, o gráfico que se redesenha. Cada exclusão é uma decisão que alguém escreveu

Um limiar global é uma declaração de que uma fração desconhecida da sua interface pode mudar sem lhe dizer nada. Uma região ignorada é uma declaração sobre um elemento concreto, revisível num pull request, e não cresce em silêncio à medida que a página aumenta.

O que não lhe consegue dizer

Não lhe consegue dizer que uma alteração está errada. Diz-lhe que houve uma alteração, e é uma pessoa que decide qual das duas coisas é.

Parece uma distinção pequena até contar as revisões. Cada alteração visual deliberada produz uma fila de diffs que alguém tem de ver e aprovar, e se essa pessoa não tiver nome, num mês a fila passa a ser um carimbo. A partir daí a suite corre, está verde e não vale nada.

Além disso só verifica aquilo para onde a apontou, nos navegadores e tamanhos de janela de que lhe falou. É esta a lacuna que vale a pena nomear, porque é aí que vivem os bugs interessantes. Um layout que parte só no Safari, ou só a 320 píxeis de largura, ou só quando o navegador não consegue descodificar o vídeo que está a servir, é invisível para uma suite que captura o Chrome a um único tamanho.

Quando compensa

O padrão é a repetição. O teste visual compensa onde os mesmos componentes são desenhados muitas vezes, de maneiras que uma pessoa não consegue na prática voltar a verificar.

Um design system ou uma biblioteca de componentes é o caso mais forte: uma alteração ao padding toca em tudo, e a suite diz-lhe exatamente onde tocou. As páginas de marketing são o segundo, porque são sobretudo layout e uma página partida custa dinheiro diretamente. Tudo o que é desenhado em várias línguas ou temas é o terceiro - a mesma página em sete línguas são sete oportunidades para uma tradução ser mais comprida do que o seu contentor, e ninguém abre as sete à mão a cada lançamento.

Compensa muito menos numa interface que é redesenhada todas as semanas, onde cada execução é um muro de aprovações, e em ecrãs internos onde um defeito cosmético custa a alguém um encolher de ombros.

Onde fica ao lado de tudo o resto

O teste de regressão visual é teste de regressão com uma captura de ecrã como asserção, por isso é a mesma lógica que decide o que lhe pertence: coisas que funcionavam e têm de continuar a funcionar. O seu plano de testes deve dizer que páginas estão cobertas e, mais útil ainda, quais não estão.

Também não é a mesma coisa que o relato visual de bugs, apesar da palavra em comum, e os dois respondem a perguntas opostas. Uma suite visual encontra alterações não intencionais antes de alguém as ver, nos ambientes que escolheu. Um relatório de erro diz-lhe o que correu mal a uma pessoa real, no navegador que ela tem mesmo, na página que estava mesmo a usar. Nenhum substitui o outro: o primeiro é uma rede, o segundo é o que faz ao peixe que passou por ela.

Não vendemos uma ferramenta de teste visual, e este é o limite honesto do que lhe podemos dizer sobre manter uma a funcionar. O que nós vemos é a outra ponta - o relatório que chega porque alguma coisa se desenhou mal para alguém, num navegador ou num tamanho de ecrã que ninguém capturou.

Um ponto de partida que sobrevive ao contacto

Cinco páginas, um navegador, um tamanho de janela, a correr em CI em cada pull request, num contentor para que os píxeis sejam estáveis. Uma pessoa com nome aprova os diffs. Regiões excluídas em vez de uma percentagem.

Acrescente navegadores e tamanhos quando as cinco páginas estiverem verdes e merecerem confiança há um mês. A maioria das suites que são abandonadas eram demasiado largas no primeiro dia, e as que sobrevivem começaram mais pequenas do que parecia sério.