Skip to content

Latest commit

 

History

History
105 lines (66 loc) · 5.59 KB

File metadata and controls

105 lines (66 loc) · 5.59 KB

Aula 2 - Testando a aplicação como um usuário real

Antes de começar, dê uma navegada pela os arquivos contidos no diretório cypress/ para se familiarizar com o código existente.

Agora que você já conhece um pouco a base de código, podemos começar a melhorá-lo!

Já no começo da suite de testes existente, temos um espaço para melhoria.

Me refiro ao seguinte trecho de código.

beforeEach(() => {
  cy.visit('/')

  cy.assertLoadingIsShownAndHidden()
  cy.contains('More').should('be.visible')
})

Este código funciona, porém não é assim que um usuário real se comporta quando utilizando uma aplicação web que faz buscas. Ou seja, o usuário não espera primeiro pelo componente que exibe o texto Loading ... estar visível, depois não estar mais visível, e então pelo botão de paginação estar visível.

Se nos colocarmos no lugar do usuário, após visitarmos a aplicação, simplesmente esperamos que a mesma esteja em um estado pronta para receber uma nova busca. Nada mais.

Pensando nisso, seria legal se pudéssemos interceptar a requisição que a aplicação faz à API do Hackernews, darmos um alias à ela e então aguardarmos por tal requisição acabar antes de seguir adiante.

Sorte nossa que estamos usando o Cypress para escrevermos os testes. 🚀

O Cypress possui uma funcionalidade chamada cy.intercept(), a qual pode nos ajudar bastante.

A propósito, escrevi um post sobre como aguardar uma requisição acabar antes de seguir adiante com Cypress. Recomendo a leitura antes de seguir adiante. É melhor fixar o conhecimento do que correr e não entender o que está fazendo, não é mesmo?

Para mais detalhes sobre a funcionalidade cy.intercept(), recomendo a leitura da documentação oficial do Cypress.

Exercício

Refatore o bloco de código do primeiro beforeEach da suite de testes, para em vez de aguardar por elementos estarem visíveis ou não, aguardar por uma requisição do tipo GET para o endereço **/search?query=React&page=0 antes de seguir adiente.

🧙🏻 Ao final de cada implementação, recomendo executar o comando npm run lint, o qual irá fazer a análise estática do código para garantir que o estilo de codificação definido está sendo seguido.

🧙🏿 Alguns problemas encontrados via análise estática de código podem ser automaticamente resolvidos executando o comando npm run lint:fix.

🧙🏼 Após a resolução de cada exercício, lembre-se de executar os testes com o comando npm test, ou utilizando o test Runner do Cypress (com o comando npm run cy:open) e garanta que todos os testes continuam passando antes de seguir adiante.

Extra credit 1

Extra credits são exercícios extra para te ensinar outras formas de resolver o mesmo problema, assim você aumenta suas possibilidades.

Refatore mais uma vez o bloco de código do beforeEach, para que este aguarde por uma requisição do tipo GET para o pathname **/search, passando o valores das query strings query e page como propriedades do objeto query que pode ser passado ao cy.intercept().

🙊 😃

cy.intercept({
  method: 'GET',
  pathname: '**/search',
  query: {
    query: 'React',
    page: '0'
  }
}).as('getStories')

Extra credit 2

Nos seguintes testes, requisições do tipo GET também são feitas à API do Hackernews, e portanto, poderíamos aguardar por tais requisições acabarem antes de seguir adiente, em vez de aguardar por elementos estarem ou não visíveis.

  • shows 20 stories, then the next 20 after clicking "More"
  • types and hits ENTER
  • types and clicks the submit button
  • searches via the last searched term
  • shows a max of 5 buttons for the last searched terms

Tua missão é refatorar os testes acima utilizando uma das abordagens das refatorações anteriores, para testarmos a aplicação o mais próximo de como usuários reais à utilizam.

Gravei um vídeo com a solução para cada um dos testes acima, ou seja extra-credit-2-1, extra-credit-2-2, etc.

Curiosidade: Você percebeu a implementação do teste shows a max of 5 buttons for the last searched terms, onde em vez de repetir o código para fazer 6 buscas, utilizo a funcionalidade Cypress._.times(), passando como primeiro argumento o número 6, e como segundo argumento uma função que executa a busca? Isso se chama "simplificando comandos repetitivos".

Extra credit 3

Logo após o teste types and clicks the submit button, adicione um novo teste chamado types and submits the form directly.

Algo como o seguinte.

it('types and submits the form directly', () => {
  cy.get('form input[type="text"]')
    .should('be.visible')
    .clear()
    .type('cypress')
  cy.get('form').submit()

  // Assertion here
})

Resolvi trazer este extra credit para demonstrar uma opção disponível para submissão de formulários com Cypress, porém, a qual não recomendo utilizar a não ser que seja totalmente necessário, visto que não é assim que usuários utilizam a aplicação. Ou seja, os usuários não tem como invocar a submissão do formulário diretamente.

Obs.: 🧙🏿 Visto que estamos testando a aplicação sob a perspectiva de um usuário real, delete este novo teste após sua implementação. Só queria mostrar pra você esta possibilidade.


Está ficando melhor, hein?

Vá para a aula 3 para implementarmos alguns testes pendentes, para situações de erro.