Testes automatizados de UI e o índice de manutenção

O que derruba o índice nos testes automatizados de UI

Seletores e esperas produzem falhas que não são bugs. Cada uma delas consome um pouco da disposição do time de olhar o próximo build vermelho.

O momento em que uma suíte morre

Em geral dá para identificar olhando para trás: a semana em que alguém disse “é só rodar de novo” e estava certo. Depois disso, reexecutar vira a primeira reação a qualquer falha, e uma regressão real é reexecutada até passar por sorte ou acabar em quarentena.

Ninguém decide deixar de confiar na suíte. A confiança vai se desgastando.

Como proteger esse índice

• Corrija testes instáveis antes de adicionar novos. Impopular e correto. Um teste novo adicionado a uma suíte que as pessoas ignoram não tem valor nenhum.

• Coloque em quarentena de forma visível, não silenciosa. Um teste pulado precisa estar visível e ter um responsável; caso contrário, a lista de testes pulados vira o cemitério de testes.

• Trate uma reexecução como um achado. Se um teste precisou ser reexecutado, algo está errado com o teste ou com o ambiente. Registre isso em vez de seguir em frente.

A parte estrutural

Disciplina resolve seletores e esperas. Ela não resolve o terceiro custo: a cobertura é limitada por quanto alguém consegue escrever, e o produto cresce mais rápido do que isso, principalmente quando boa parte do código vem de um agente de codificação.

Passos expressos como intenções, e não como caminhos pelo DOM, eliminam de saída boa parte das falhas de seletor, que são o maior fator isolado desse índice.

A mesma configuração está disponível no dashboard do TestSprite, caso você prefira não instalar nada localmente. O restante dos recursos do CLI está no repositório do CLI.

Como recuperar um índice ruim

Se a suíte já chegou ao ponto em que as pessoas reexecutam em vez de investigar, adotar disciplina daqui para frente não resolve, porque o ruído que já existe continua alimentando o hábito. A recuperação exige um recomeço deliberado.

Pegue as últimas cinquenta falhas e classifique cada uma como real, de seletor, de tempo ou de ambiente. Essa hora de trabalho mostra qual dos três custos você realmente tem, e ele costuma estar concentrado, não espalhado. Corrija essa categoria em toda a suíte, em vez de consertar testes conforme eles falham.

Depois, coloque em quarentena tudo que continuar falhando, com um responsável e uma data, e deixe o resto da suíte verde. Uma suíte pequena e verde em que as pessoas confiam vale mais do que uma grande e vermelha que elas aprenderam a ignorar, e esse é o único estado a partir do qual o índice pode melhorar.

Rode onde as falhas custam menos

Em cada pull request, para que uma falha aponte para uma única mudança, e não para uma semana inteira delas.

• O GitHub App é um webhook que você configura no dashboard do TestSprite. Ele escuta o evento de deploy que seu pipeline já produz, então nada muda no seu repositório.

• GitHub Actions coloca o passo dentro do seu próprio workflow, configurado pelo terminal.

Como o TestSprite protege esse índice

De forma direta: eliminando a maior fonte de falsas falhas. Os passos são intenções, não localizadores, então as mudanças cosméticas que geram a maior parte das quebras de seletor não produzem builds vermelhos. A espera é tratada para você, em vez de ser um exercício de ajuste teste a teste, o que elimina quase todo o resto.

A cobertura é gerada a partir do seu produto e refinada em linguagem natural, então ampliar a suíte não significa ampliar a manutenção na mesma proporção, que é justamente o que costuma forçar a escolha entre cobertura e confiança.

O resultado é uma suíte em que uma falha surpreende. Esse é o estado em que as pessoas investigam em vez de reexecutar, e é o único estado em que a cobertura pode continuar crescendo sem que tudo vire, silenciosamente, mera decoração.