Testes E2E do Zero com Claude Code e Playwright

Destaques

• Diferença prática entre Playwright CLI, Playwright MCP, Playwright Library (usada internamente pelo Pest) e a extensão oficial do VS Code, e quando usar cada uma.
• Fluxo de 5 prompts para construir a aplicação de demonstração (um todo list com Filament, guest/admin/super admin panels e Laravel Reverb): PRD, implementação, roteiro de testes end-to-end, execução dos testes com screenshots, refatoração de landing page e documentação.
• Playwright MCP conduzindo o Claude Code ao vivo pelo login, criação de listas, configuração de slug e cadastro na fila de beta, com o agente decidindo os próximos passos sozinho.
• Um bug real de autenticação no broadcasting do Laravel Reverb (erro 403) encontrado e corrigido pelo próprio agente durante a execução dos testes.
• Uso dos screenshots capturados durante os testes para gerar automaticamente uma página de documentação navegável (menu "docs"), incluindo seção de troubleshooting.
• Testes cobrindo não só o caminho feliz, mas cenários negativos: senha incorreta, usuário inexistente, slug duplicado e acesso a lista pública com e sem senha.
• Testes de responsividade: captura de tela em diferentes resoluções e verificação de overflow/breakpoints quebrados.
• Integração do Playwright em CI via GitHub Actions rodando os testes em modo headless, como alternativa a Cypress e Laravel Dusk.

Profundidade técnica

A abordagem apresentada separa dois usos distintos do Playwright dentro do fluxo com IA. Para testes propriamente ditos — que precisam ser determinísticos, versionados e continuar passando ao longo do desenvolvimento — a recomendação é o Playwright CLI (ou a Playwright Library usada pelo Pest), porque roda fora do contexto do agente e não consome tokens além do necessário, sendo mais rápido para suítes já bem definidas. Já para o momento de exploração e desenvolvimento — quando ainda não se sabe exatamente o que vai acontecer na tela, como depurar a configuração do Laravel Reverb/Echo — o Playwright MCP é preferido, pois devolve respostas multimodais inline (sem precisar salvar e reler arquivos de screenshot) e permite que o agente siga um ciclo completo de decisão até resolver o problema sozinho. Um roteiro de testes end-to-end escrito em markdown (docs/end-to-end-testing.md) funciona como contrato explícito do que o agente deve validar: sem essa explicitação, o agente pode tomar decisões erradas, como remover uma feature problemática em vez de corrigi-la. A prática de manter na memória do Claude Code regras como "achou bug, pare, pense, debug, entenda, resolva, teste, só depois continue" evita tanto testes falso-positivos (do tipo assertTrue(true)) quanto decisões silenciosas do agente. Por fim, os mesmos screenshots gerados durante os testes E2E alimentam diretamente a documentação da aplicação e a landing page, eliminando o trabalho manual de manter imagens e manuais atualizados a cada mudança de tela.

Faça parte do Clã

Encontros como esse, com mão na massa e convidados que vivem engenharia de IA no dia a dia, são exclusivos de quem está no Clã. Garanta sua vaga em beerandcode.com.br/workshops/beer-and-code-cla-nivel-1.