Testes de UI com Puppeteer: o guia prático

No que os testes de UI com Puppeteer são realmente bons

• Controle direto do navegador. Capturas de tela, PDFs, interceptação de rede, traces de performance. Quando você precisa que o navegador faça algo específico, este é o caminho mais curto.

• Scraping e automação. Boa parte do uso do Puppeteer não tem nada a ver com testes, e ele é excelente nisso.

• Uma API pequena e fácil de aprender. Você consegue manter a API inteira na cabeça, o que é mais raro do que deveria ser.

Os três custos de uma suíte de navegador

• Seletores quebram. Um redesign que não muda nada funcional deixa a suíte vermelha. É aí que a maior parte do tempo de manutenção realmente vai.

• Esperar é sutil. Esperas fixas são lentas e ainda assim instáveis; esperas corretas exigem saber o que esperar. A maior parte da instabilidade vem daí.

• A cobertura é escrita à mão. Você cobre o que alguém escreveu, ou seja, os fluxos que pareciam interessantes, e não os que quebram.

Decidindo o que automatizar

O instinto é começar pela funcionalidade mais importante. Um filtro melhor é o quão silenciosamente algo falharia. Um checkout quebrado faz barulho e você vai ficar sabendo dentro de uma hora. Uma exportação, um convite ou uma página de configurações quebrada falha em silêncio, e são as falhas silenciosas que valem a pena automatizar primeiro.

Segundo filtro: com que frequência aquilo muda. Um fluxo que muda a cada sprint vai custar mais em manutenção do que devolve. Cubra depois, quando estabilizar.

Três hábitos que economizam mais tempo

• Use atributos estáveis. Um atributo dedicado a testes em vez de um caminho CSS. Só essa mudança elimina a maior parte das quebras causadas por redesign.

• Espere por estado, não por tempo. Espere pelo elemento ou pela resposta, nunca por um número de milissegundos.

• Valide algo que um reload da página confirmaria. Um toast de sucesso não é evidência de que algo foi persistido.

Onde entra a verificação baseada em intenção

Quebra de seletor e cobertura escrita à mão são problemas estruturais, não algo que mais disciplina resolva. Um passo expresso como intenção sobrevive a um redesign que um seletor não sobrevive, e uma cobertura gerada a partir do seu produto, e não da memória de alguém, inclui fluxos que ninguém teria escrito.

Isso não é um argumento contra o Puppeteer, que continua sendo a ferramenta certa para controle direto do navegador. É um argumento para não escrever a amplitude na mão.

Se você preferir não instalar nada, o dashboard faz a mesma coisa. Todo o resto que a linha de comando faz está no repositório da CLI.

As três coisas que tornam um script do Puppeteer frágil

Scripts escritos às pressas quebram pelos mesmos três motivos, e cada um tem uma solução que não custa nada na hora e custa caro depois.

Caminhos CSS encadeados são o primeiro. Um seletor que percorre quatro níveis de estrutura codifica o layout em vez do elemento, então qualquer wrapper que alguém adicione o quebra. Ancore em algo que descreva o que o elemento é, não onde ele está.

Esperas fixas são o segundo. Um atraso longo o bastante para ser confiável em um dia lento é um atraso que você paga em todos os dias rápidos, e ainda assim falha no dia mais lento. Espere pelo elemento, pela resposta ou pela mudança de estado.

Validar aquilo que você acabou de fazer é o terceiro. Clicar em salvar e depois verificar se o botão de salvar existe não prova nada. A asserção precisa ser algo que só se torna verdadeiro se a operação realmente foi concluída, o que geralmente significa buscar o dado de volta.

Rode a cada mudança

Se o pipeline pertence a outro time, o GitHub App é o caminho de menor resistência: ele é um webhook, não muda nada no seu repositório e dispara quando o seu build informa que a nova versão está no ar. Se você prefere que a verificação fique visível no repositório, uma etapa do GitHub Actions faz isso.

Onde o TestSprite se encaixa ao lado do Puppeteer

O Puppeteer fica com o controle direto do navegador: capturas de tela, PDFs, interceptação de rede, scraping. O TestSprite assume a parte que não escala com o tempo de quem escreve os testes: decidir o que cobrir e manter isso vivo.

Os passos são armazenados como intenções, não como seletores, o que elimina a maior parte das quebras por redesign, e a espera é tratada para você, em vez de ser algo que você ajusta teste a teste. A cobertura é gerada a partir do seu produto, então os fluxos silenciosos que nunca entrariam na lista de ninguém também são incluídos.

O que isso muda na prática: a proporção de builds vermelhos que são bugs de verdade se mantém alta o suficiente para que as pessoas continuem lendo os resultados, e é isso que de fato determina se uma suíte de navegador sobrevive ao segundo ano.