Tech Chat – Utilizando Playwright like a Pro – com Stefan Teixeira
Neste Tech Chat, recebi o Stefan. Ele é uma referência na área de qualidade há muito tempo. Já palestrou em vários eventos e agregou muito a comunidade de TI no Brasil. E dessa vez, ele nos conta sobre a sua longa experiência com Playwright e sua perspectiva desde quando a ferramenta foi lançada.
Stefan, super obrigada pela contribuição no Tech Chat. Nunca paro de aprender com você!
1. Conte-nos um pouco sobre você e os projetos em que trabalha com Playwright.
Me chamo Stefan Teixeira, trabalho na área de QA há mais de 13 anos e atuo como Arquiteto de Qualidade de uma das áreas da empresa onde trabalho. Lido com múltiplos times dentro da área, trabalhando em múltiplos projetos Web usando JavaScript/TypeScript/Ruby on Rails. Sou responsável pela visão e estratégia de QA e CI da área, liderando 15+ QAs que compõem os times e trabalhando próximo aos Diretores de Engenharia e Produto.
2. Quando começou a trabalhar com Playwright e qual foi o processo de decisão por este framework? E qual linguagem você utiliza nos seus testes?
No início de 2020, decidi usar o Puppeteer quando começamos a implementar testes End-to-end no nosso projeto principal. Na época, vi que o Playwright era uma opção (e que era um fork do Puppeteer), mas havia sido criado há muito pouco tempo e decidi não arriscar.
No início de 2021, notei que a integração jest-puppeteer não estava mais sendo mantida regularmente, o que era um grande risco e que impossibilitava usarmos versões mais recentes do Puppeteer de forma simples. Com isso, fiz a migração dos testes para o Playwright e o usamos em todos os projetos JS/TS desde então.
3. Você tem experiência com outros frameworks? Em que o Playwright se destaca quando de forma geral?
Trabalho com automação de testes em múltiplos níveis há pelo menos 12 anos, durante a carreira já trabalhei com diversos frameworks com linguagens diferentes, como o Selenium WebDriver (e RC), Cypress, Protractor, etc. Posso afirmar com tranquilidade que o Playwright é o melhor framework que temos hoje em dia e que está muito à frente de outras opções.
O paralelismo nativo do Playwright e a sua velocidade/tempo de execução são determinantes e definitivamente os pontos mais fortes, na minha opinião. Tempo rápido de feedback é crucial durante o desenvolvimento, e com o Playwright podemos facilmente paralelizar testes de acordo com os recursos de hardware disponíveis.
4. Tem alguma coisa que você acha que ainda não está legal no Playwright?
O Playwright evoluiu bem em termos de recursos de debugging nos últimos tempos, o que era um aspecto que realmente poderia ser melhor. Atualmente, a funcionalidade que estou aguardando ganhar mais solidez é a de Component Tests. Em projetos de Front-end, seria ótimo poder substituir o React Testing Library pelo Playwright para esse nível de teste, o que permitiria rodar usando browsers reais. Entretanto, essa parte ainda está como experimental e espero que tenhamos mais atualizações no futuro.
5. Qual é sua funcionalidade favorita do Playwright?
Definitivamente é o paralelismo nativo e facilmente customizável. Isso permite escalar a execução de forma simples e tem um impacto enorme no desenvolvimento dos nossos projetos.
6. Pode nos contar um pouco como é estruturada a sua pipeline? Você utiliza paralelismo? E sharding?
Os testes rodam sempre na pipeline depois de um merge de um pull request e precisam estar passando para que um deploy seja realizado automaticamente. Dependendo do tamanho do projeto, rodamos os testes em pull requests de forma manual, através de um comentário que faz o trigger do CI job. Paralelismo é algo que usamos sempre, mas temos nosso próprio script pra fazer o processo equivalente ao sharding do Playwright. Para projetos muito grandes e com um número alto de testes, usamos isso para distribuir a execução em mais de uma máquina.
Para lidar com o aumento do número de testes e a distribuição em diferentes máquinas, devemos avaliar 4 aspectos: tempo de execução, nível de paralelismo, nível de distribuição (sharding) e custos do CI. Tempo de execução é importante, mas é preciso considerar os custos quando pensamos em adicionar mais máquinas para rodar os testes.
7. Qual é a IDE que você utiliza para desenvolver os testes? E você utiliza mais linha de comando ou o plugin do Playwright na IDE?
Uso o Visual Studio Code como IDE e costumo executar os testes diretamente pelo terminal, não faço uso de outros plugins.
8. O que acha do Codegen do Playwright?
Não cheguei a utilizar, mas há um tempo vi que um devs de um dos times estava utilizando e gostou da experiência.
9. Já utilizou GitHub Copilot pra implementar os testes? E utilizou Inteligência Artificial para criar algum teste ou alguma função (page object model por exemplo) no seu projeto? Tem alguma opinião sobre esses pontos?
Não cheguei a utilizar o Copilot até o momento, apenas o ChatGPT (GPT-4) para uso geral. O uso de IA facilita bastante e permite agilizar o processo de desenvolvimento, mas antes de usar no ambiente de trabalho, verifique sempre quais ferramentas são aprovadas pela empresa e tome cuidado para não informar dados sensíveis/confidenciais nos prompts. Ainda existem muitos aspectos relacionados à privacidade e segurança da informação no uso de IAs generativas que precisam ser analisados com cuidado.
10. Como você lida com as atualizações do framework? Você atualiza de forma automática ou manual? E tem alguma dificuldade em lidar com o número frequente de releases? Como você determina/prioriza o que será atualizado no código existente com as novas features do framework?
Para projetos menores, é mais simples atualizar as versões de forma automática (usando o dependabot, por exemplo) e vendo se os testes passam. Para projetos maiores e/ou legados, é preciso ter mais atenção e verificar também se a aplicação está funcionando corretamente. Minha recomendação é usar o dependabot e ajustar sua configuração após alinhar com o time sobre a periodicidade de atualização das dependências. Também é importante criar tarefas para tais atualizações, que sejam estimadas pelo time e priorizadas no Backlog.
Quanto a atualizações no código com novas funcionalidades, é preciso analisar as release notes e ver se tem alguma feature que seria interessante utilizar no projeto. Caso tenha, recomendo seguir o mesmo processo de criação de tarefa(s) no Backlog, estimadas pelo time todo e priorizadas adequadamente.
11. Além de UI e API, você usa Playwright para algum outro tipo de teste?
Uso o Playwright para diferentes tipos de teste. Majoritariamente, para testes End-to-end, testes de regressão visuais (integrando com o Happo.io), testes de integração (verificando apenas o Front-end da aplicação, testando comportamentos de design responsivo, fluxos simples, etc.). Além disso, também usamos para testes mais específicos, como testes de Acessibilidade, testes de aspectos de SEO (validando renderização no lado do servidor – SSR, validando meta tags, schemas de dados estruturados, tags de open graph) e testes de API.
12. Os devs também dão manutenção nos testes? Se sim, como vocês garantem os padrões de desenvolvimento com profissionais de diferentes backgrounds trabalhando no mesmo código?
Certamente, isso é algo imprescindível. Ainda vejo muitas empresas e profissionais com uma cultura de separação do que são “testes do QA” e “testes do Desenvolvedor”. Essa mentalidade é completamente ultrapassada e impede que tenhamos testes melhores em todos os níveis. Durante o dia-a-dia de um time, é natural que cada papel lide com níveis de testes específicos. Entretanto, é crucial que todos os membros do time saibam manter todos os níveis de testes e que sejam capazes de analisar logs, debugar e identificar/aplicar melhorias.
Quanto aos padrões de desenvolvimento, isso é garantido através do uso de linters e formatadores de código, como o ESLint e o Prettier no mundo JS/TS. É recomendado que os próprios times criem regras customizadas para garantir que padrões/convenções sejam seguidos no código. Finalmente, também é importante que pull requests sejam revisados por diferentes membros do time (por exemplo, 1 Dev e 1 QA). Durante as próprias revisões de PRs, os membros do time podem identificar melhorias nas configurações de linters e/ou ideias para novas regras a serem criadas.
Referências Complementares:
- Talk sobre Playwright do Stefan Teixeira para Minas Testing Conference 2022
- Outros Tech-chats
- Treinamentos de Playwright da Renata Andrade
