Fazendo uma aplicação em Vue.js com TDD — Um guia extensivo para quem quer aprender — parte 4
Testando o nosso serviço de requisições para a API
Este é o quarto de uma série de artigos:
- Parte 1: Setup e o primeiro teste
- Parte 2: Continuando a UserView
- Parte 3: Testando a store e o restante dos componentes de apresentação
- Parte 4: Testando o serviço de requisições para a API
- Parte 5: Adicionando e testando com dependências de terceiros
- Parte 6: Resumo geral — 26/11
Primeiro, desculpem mesmo a demora para esta parte, acabei não conseguindo me organizar para lançar o artigo na semana passada 😅 mas vamos ao que interessa.
Semana passada finalizamos todos os testes dos nossos componentes, e fizemos isso tudo integrando com a store, o que provavelmente foi a parte mais extensa e importante.
Vamos agora para a última parte da aplicação que falta ser testada, o serviço responsável pelas requests a api do github.
Testando o nosso serviço de requisições para a API
Aqui está o nosso último teste, a única diferença do que foi visto até agora, é que estamos fazendo o uso de uma nova dependência instalada no início do projeto, o nock.
Basicamente essa biblioteca permite que você teste requisições http de forma isolada. Podemos especificar urls e caso seja feita uma requisição para ela, o nock irá interceptar, e tratar internamente a request para fazer as operações da forma como você especificou.
Vamos alanizar a partir da linha 11, estamos fazendo o nock observar qualquer requisição GET para a url: https://api.github.com/users/:username e ele irá interceptar isso para nós, e retornar uma resposta de status 200 com o usuário esperado (a fixture).
Em seguida, chamamos o método do service passando o usuário, e fazemos um flushPromise para garantirmos que todas as promises estarão resolvidas a partir deste ponto.
Para a faze de asserts, queremos garantir que o resultado do serviço, seja o nosso userFixture garantindo assim, que ele fez a requisição para a URL esperada, no qual estamos mockando com o nock.
E por fim, queremos garantir que a URL mockada no nock tenha sido chamada.
Nosso teste vai falhar, já que não temos nenhum tipo de implementação ainda, vamos começar.
Finalmente temos o serviço responsável pelas requisições.
Fazemos o uso do axios, uma biblioteca que nos ajuda a fazer requisições HTTP.
Na linha 4, criamos uma instância do axios para fazer requisições para a API do Github, o adapter que passamos como configuração é necessário, para conseguirmos utilizar o axios com o nock.
O adapter permite a gente customizar a forma que o axios lida com as requests, possibilitando que o nock consiga interceptar as requisições.
Na linha 10, temos o método que recebe o username, retornando uma requisição GET para a api de usuários do github.
Na linha 13, pegamos a resposta da requisição, e retornamos a propriedade data da request, estou fazendo isso aqui, pois o axios altera o valor de retorno e encapsula a resposta da api dentro desta propriedade.
E com isso, concluímos todos os nossos testes da nossa aplicação.
Vamos ver como ficou?
Agora podemos finalmente ver o resultado final do nosso trabalho, rode:
npm run serve
O que estamos vendo?
Absolutamente nada, mas é claro… precisamos criar uma rota para o nosso componente 😆
Pronto, agora sim:
Lembrando que podemos também testar as rotas, podemos criar um teste para garantir que temos as rotas esperadas, junto com os guards caso necessário, mas não faremos isso neste momento.
Mas com isso, a gente conseguiu criar uma aplicação inteira, sem ver ela, e o melhor de tudo, temos as principais partes totalmente cobertas por testes 😍
Resumo da obra
Neste quarto artigo, fizemos:
- Testamos o serviço responsável por fazer requisições para o Github
- Finalizamos a nossa aplicação 😃
Recomendo caso tenham interesse para dar uma lida nos repositórios do:
Pois há uma gama de funcionalidades que podemos fazer com estas bibliotecas, e também não se limitem com elas, existem outras libs que fazem esse tipo de serviço com o jest-axios-mock.
Também como um aviso, esta forma de testar esse tipo de serviço não irá substituir testes de integração e e2e, estamos garantindo aqui que a aplicação funciona desde que a api esteja retornando o que a gente espera, se algum dia a API do github sair do ar, mudar o endereço ou alterar o formato de resposta (isso é extremamente errado), a aplicação irá quebrar, e aí que vai entrar estes outros testes para garantir o funcionamento total da aplicação.
Fiquem atentos que próxima semana estaremos inserindo uma biblioteca de componentes de terceiros e iremos atualizar os nossos testes para comportar ela.
Muito obrigado pela atenção e me desculpem novamente pela demora 😅
Se gostou, por favor, clique no 💚, e qualquer dúvida, sugestões ou correções sinta-se a vontade para me mandar uma mensagem, eu agradeço muuito 😄.
Meu Twitter: @DKuroski
Vejo você próxima semana 😄
