Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resolution/Mateus F Torres #1

Closed
wants to merge 11 commits into from
Closed

Resolution/Mateus F Torres #1

wants to merge 11 commits into from

Conversation

mateus-f-torres
Copy link

@mateus-f-torres mateus-f-torres commented Aug 28, 2020

Resolução - Mateus F Torres

Segue minha resolução para este desafio

Foi bem interessante utilizar o Puppeteer para criar um teste E2E, com isso eu pude entender onde seria o melhor lugar para o Puppeteer dentro de um workflow da QA. Eu diria que a experiência de escrita dos testes é um tanto falha, devido ao sua API ser desenhada para automação de navegadores, no entannto, isso pode também ser por falta de prática com a ferramenta.

Minha proposta seria uma mescla de Cypress com Puppeteer:
- Cypress seria a ferramenta para testes de integração e ponta-a-ponta
- Puppeteer seria a ferramente para testes de perfomance (load, first meaning paint, time to interactivity, etc)

Meu interesse agora é integrar Puppeteer dentro desta minha aplicação: Warehouse
Ela já possue uma boa bateria de testes automatizados com Cypress (com alguns fluxos ainda incompletos)
Assim posso capturar métricas de perfomance da PWA e aprender mais Puppeteer.

Extras:

Foquei em apenas commitar código referente ao que foi pedido.
Pessoalmente gosto de automatizar bastante do meu workflow de formatação, lintagem e testes.
Meu template pessoal , Barefoot, tem parte das configuração que eu adicionaria

Edit

Após analisar mais a fundo Cypress e Puppeteer cheguei a conclusão que estava enganado.
Cypress é sim um ferramenta incrível de testes de integração e ponta a ponta...quando local.
Tentar usar está biblioteca para validar aplicações externas é um anti-padrão e basicamente impossível 😞

Em contrapartida ferramentas como Puppeteer, Selenium e BrowserStack são melhores para esta tarefa.
Percebo que o desconforto que senti era por tentar escrever um teste externo com uma mentalidade de testes locais.
Nada como uma tarefa simples e direta para desconstruir presunções.

Since we are using yarn v2 here we need to setup some things:

1. Some of the jest-puppeteer dependecies are not declared
   So we explicitly install and connect with .yarnrc.yml.

2. We need to add babel-jest and related dependencies
   So we can write tests with future Ecmascript features.
Rename tests and description;
Create constants for easy of modification;
Start writing helpers for testing;
Setup jest to run in band with -i flag
Should investigate doing this with expect.extend({});
Would make the API closer to standard Jest behavior;
@rod-stuchi
Copy link
Contributor

fala @mateus-f-torres , realmente o puppeteer é excelente pra rodar contra um site não local, e por ser uma ferramenta de instrumentação, tem controle total sobre as APIs do Chrome, abre o leque para inúmeras possibilidades, como testes, métricas, cobertura, simular devices, network, cpu, etc.

O uso de wait/timeout é normal em ambas as ferramentas, seria mais complicado ouvir todos os eventos (dom, css animations, etc) pra fazer do jeito "certo".

Tenho uma dúvida sobre as dependências que usou, por que não usar apenas o básico jest, jest-puppeteer e puppeteer ?

@mateus-f-torres
Copy link
Author

Sim, sim.

Tenho analisado o uso mais direto de puppeteer uma vez que a biblioteca jest-puppeteer parece estar sem manutenção.
Embora um pouco mais verbal no inicial vejo algo de bom com um contato mais direto da biblioteca, pois pode auxiliar em ter melhor controle de funções assíncronas e fechamento de conexão.

Quanto as depêndencias tem 2 motivos:

  1. Yarn v2

    • dependências adicionadas: expect-puppeteer e jest-environment-puppeteer

    • por utilizar a versão mais atual de yarn foi necessário explicitamente declarar estas dependências

    • caso o projeto utilizasse npm ou yarn <= 1.22 elas seriam resolvidas pelo hasteamente de modulos

      Esse acaba sendo a maldição/benção do mundo de Javascript.
      Comportamentos inesperados e incorretos se tornam comum e algo que dependemos no dia a dia.
      A nova arquitetura de Yarn vem para corrigir estes erros e de pouco em pouco as bibliotecas estão se adaptando.
      Atualmente tem uma PR aberta para esse problema no jest-puppeteer #319

  2. Babel

    • dependências adicionadas: @babel/core, @babel/preset-env, babel-jest, core-js e regenerator-runtime

    • prefêrencia pessoal pela utilização de ES modules, ainda não nativos para jest #4842 e #9430

      Este realmente foi mais um questão de gosto e costume de desenvolvimento atualizado com o ECMAScript.
      Objetivamente poderiamos ter colocado engines dentro do package.json e utilizar CommonJS.
      Desta forma garantimos a versão desejada do Node JS e limpamos essas dependências.

@rod-stuchi rod-stuchi closed this Sep 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants