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.
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 comandonpm run cy:open
) e garanta que todos os testes continuam passando antes de seguir adiante.
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')
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".
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.