Testes automatizados de UI: escolha pelo que falharia em silêncio

Um filtro melhor para testes automatizados de UI

Classifique os fluxos pelo tempo que uma quebra ficaria sem ser notada, não pela importância deles. Uma exportação, um convite, uma página de configurações, um resumo agendado. Cada um importa para alguém e nenhum deles tem uma plateia olhando, então uma regressão fica ali por um mês.

Segundo filtro: com que frequência o fluxo muda. Uma tela redesenhada a cada sprint vai custar mais em manutenção do que devolve. Cubra quando ela estabilizar.

Os três custos

Os dois primeiros dá para resolver com disciplina. O terceiro é estrutural: a cobertura escrita à mão é limitada pelo tempo de quem escreve, e esse tempo não cresce.

Três hábitos que mais economizam

• Ancore em atributos estáveis. Um atributo dedicado a testes em vez de um caminho CSS. Só isso já elimina a maior parte das quebras causadas por redesign.

• Espere por estado, nunca por tempo. Espere pelo elemento ou pela resposta. Um atraso fixo é lento e pouco confiável ao mesmo tempo.

• Valide o que um recarregamento confirmaria. Um toast de sucesso não é prova de que algo foi persistido.

Por que suítes acabam deletadas

Não porque não encontram nada. Porque a proporção entre falhas reais e falhas de manutenção piora a ponto de as pessoas pararem de ler os resultados. Quando um build vermelho passa a significar “provavelmente um seletor” em vez de “provavelmente um bug”, a suíte já parou de funcionar, mesmo que continue rodando.

Proteger essa proporção é o trabalho de verdade, e isso tem mais a ver com a forma como os passos são expressos do que com a quantidade de testes que você tem.

Cobertura que não depende do tempo de quem escreve

Passos expressos como intenções sobrevivem a mudanças cosméticas, e a cobertura gerada a partir do produto, e não da memória de alguém, inclui fluxos que ninguém teria escrito. Essa é a parte do custo que disciplina nenhuma resolve.

O dashboard cobre o mesmo terreno para quem não quer uma instalação local, e a superfície completa de comandos está no repositório da CLI.

O tamanho de suíte que continua útil

Existe um tamanho a partir do qual uma suíte de navegador passa a custar mais do que devolve, e ele é menor do que a maioria dos times imagina.

A restrição não é tempo de execução, é atenção. Uma suíte de trinta fluxos produz falhas que alguém investiga. Uma suíte de trezentos produz uma lista diária, e listas são triadas, não lidas. Quando a triagem começa, o teste marginal passa a somar ruído em vez de cobertura, por melhor que esteja escrito.

Então a pergunta útil na hora de adicionar um teste não é se o fluxo importa. É se você investigaria esse teste falhando numa sexta à tarde. Se a resposta honesta é que você rodaria de novo e seguiria em frente, o teste já é ruído e escrevê-lo piora a suíte.

Rode a cada mudança

O gatilho importa mais do que o mecanismo. Apontar a execução para o seu evento de deploy faz com que toda mudança seja verificada sem que ninguém precise decidir por isso; o GitHub App faz isso pelo dashboard, e um passo de GitHub Actions faz isso de dentro do seu workflow.

Onde o TestSprite muda a conta

O terceiro custo, a cobertura limitada pelo tempo de quem escreve, é o que disciplina nenhuma resolve, e é justamente ele que o TestSprite elimina. Os casos são gerados a partir do seu produto e refinados em linguagem simples, então os fluxos silenciosos ficam cobertos sem que ninguém precise arrumar uma tarde para escrevê-los.

Os dois primeiros custos melhoram como efeito colateral. Os passos são armazenados como intenções, e não como caminhos pelo DOM, então um redesign que muda um botão de lugar não deixa a suíte vermelha, e a espera é tratada em vez de ajustada teste a teste. É nesses dois que vai a maior parte do tempo de manutenção.

O que isso protege é o número que decide se uma suíte sobrevive: a fatia de builds vermelhos que são bugs de verdade. Mantenha essa fatia alta e as pessoas continuam lendo os resultados, que é a diferença entre cobertura e um job que roda toda noite.