Como você anda testando sua API REST Parte II ?

Como você anda testando sua API REST Parte II ?


Irei aproveitar este post para passar algumas informações de como criar um projeto NodeJs do zero no Github, neste caso em específico vamos criar um projeto simples para testar a API PhoneBook utilizada no primeiro post desta série.

Uma vez que você já tenha uma conta no GitHub basta adicionar um repositório:

Criação de Projeto no GitHub

Você deve preencher o nome do repositório que fará parte da url do seu projeto, a descrição é opcional, faça-me o favor de criar um repositório publico para compartilhar informações por simples que estas possam ser, marcando a opção de iniciar o repositório com o README é criado um README.md este é o arquivo que irá trazer informações na página principal do seu projeto, a extensão .md se refere a Markdown

No nosso caso usaremos o Add .gitignore com o valor Node, este arquivo adicionado ao projeto e é preenchido com informação por exemplo que o git deve ignorar quando você realizar um build, um diretório node_modules é criado no seu projeto com as dependências do seu projeto depois que você executa o "npm install", neste caso este diretório não será versionado pelo git caso você escolha a opção Node. E por ultimo tem a licença que você pode adicionar ao seu projeto vou deixar para vocês lerem um pouco sobre isso neste link. Agora você já tem seu repositório criado!

Vamos para o console e iniciar a criação do seu projeto, crie um diretório com o nome do seu projeto, entre dentro do diretório e digite "npm init", este comando é para interativamente você preencher o arquivo package.json com informações do tipo nome do projeto, licença, autor, comando para testes, url do repositório do GitHub e quais dependências seu projeto vai ter, no nosso caso Mocha, Supertest e Chai. Exemplo: Vídeo

NPM INIT
Eu preenchi com dados quaisquer apenas para título de exemplo mesmo, preencha com as informações do seu projeto, antes de salvar o npm te mostra uma prévia do arquivo e você pode avaliar se está pertinente ou não as informações fornecidas:
Infomações do package.json
 Pronto agora que já você já tem o seu repositório criado e seu projeto também, já pode subir para o Github o seu arquivo package.json, instale o github na sua máquina e use o gitshell no caso de ser windows com os comandos("git status", "git add * ", "git commit" e "git push") da figura abaixo:


Para saber um pouco mais sobre o git recomendo este post do Galani para leitura.

Agora vamos instalar as dependências que iremos usar no nosso projeto de testes da nossa API, execute os comandos dentro do diretório raiz do seu projeto :

  • npm install mocha --save
  • npm install chai --save
  • npm install supertest --save

Com isso será criado um diretório node_modules contendo a instalação das 3 dependências e o parâmetro "--save" será responsável de incluir no arquivo package.json as informações referentes a estas dependências. Qual a vantagem de instalar as dependências com "--save"?

Vai que alguém apague mesmo sem querer a pasta node_modules, tendo o package.json atualizado basta um "npm install" e tudo está resolvido.

Eu finalizei alguns testes num projeto simples que publiquei no Github denominado ApiTest, como API base para os testes eu usei a API Rest PhoneBook que utilizei no primeiro post desta série que irei blogar. Irei comentar os códigos de alguns testes, para que possam entender como criar seu próprio projeto para automatizar seus testes da sua API.



O primeiro bloco é composto pelos 'requires' que equivalem aos 'imports' que você utiliza no Java por exemplo. Logo após temos a criação da variável "URL" onde você preencherá com a sua url base que utilizará no seus testes.

E por final estou criando três váriaveis contendo Json que iremos utilizar nos métodos de POST na sequência.



O "describe" é conhecido como suite de testes, nele você pode colocar títulos que irão te orientar para criar um agrupamento dos seus casos de teste que são representados com o "it". Seguindo temos o request onde passamos a url criada anteriormente, o ".post" você passa o recurso da sua API que você quer criar no nosso exemplo estamos criando um contato, depois vamos ver outras possibilidades que podemos passar utilizando o ".get" por exemplo.

A API PhoneBook que estamos usando exige que você informe no cabeçalho o tipo de conteúdo que você está enviando, estamos trabalhando com Json portanto usamos o ".set('Content-type, application/json')" na sequência usamos o ".send(contatoCompleto)" onde passamos o Json criado contendo as informações que serão persistidas.

Por final o método ".end(function(err, res))" método que passa uma função como callback onde conseguimos receber na variável "res" contendo os dados do "response" da chamada http que fizemos, na linha após estamos fazendo um Parse para Json, ou seja, estou filtrando apenas a propriedade 'text' do response e transformando num objeto do tipo Json.

Se vocês inserirem um console.log(res) e um console.log(result) vocês irão conseguir entender melhor o porque faço isso antes de começar os asserts. Esta foi a maneira mais didática que pensei para expôr estas informações.




O primeiro assert(linha 32) está verificando se o http status retornado no response está de acordo com o esperado, no nosso caso 201 equivalente a created, ou seja, criamos um novo contato na nossa API PhoneBook.

Na linha 33 até 35 estamos conferindo as informações referentes ao contato inserido, faça o post  manualmente na ferramenta de sua de preferência e veja as informações retornadas. Agora pode ser que ao consumir uma Api de uma empresa parceira ou de um terceiro, o contrato da Api consumida informa que retornará apenas o http status e nada mais. Eu retornei todos os dados persistidos para tentar esclarecer como utilizar o módulo Chai nos asserts e ainda exemplificar uma opção de retorno para um post em uma Api.

Eu implementei no projeto apenas alguns testes com post e get  como demonstração, fica o desafio para implementar o put e delete, quaisquer dúvidas podem me procurar :)

Após iniciar o serviço do mongo e iniciar a API PhoneBook, se quiser apenas clonar o projeto ApiTest e executar use:

  • git clone https://github.com/fredmoreira/ApiTest.git
  • npm install
Após use npm test  para executar os testes ou mocha -R spec (arquivo). Eu configurei o comando npm test no arquivo package.json assim:

  "scripts": {

    "test": "mocha -R spec test.js"

  }
Sendo que o arquivo contendo os testes eu dei o nome de test.js

Suponha que agora você não queira executar os testes com o GET, basta você adicionar após os Describe  o ".skip", que também pode ser adicionado após o it não executando assim um caso de teste específico.



Esta é a saída esperada:


Não sei se repararam mas os testes de get  estão consultando contatos criados nos testes de post, não é legal criar dependências entres seus casos de testes, mas irei no ultimo e próximo Post do blog implementar uma classe na API PhoneBook que irá auxiliar na preparação, execução e limpeza do banco de dados pós execução da suite de testes automatizados.

Com isso teremos uma API simples funcionando e no mesmo projeto os seus testes, mostrando de uma maneira simples como funciona na prática os testes a nível de integração no mesmo projeto que os códigos de suas funcionalidades.

Bom você pode achar alguma dificuldade inicial em automatizar testes criando seu próprio projeto, como este que fiz de exemplo, mas pode acreditar que uma suite de testes com aproximadamente uns 200 casos casos de testes chegar a executar em menos de 10 segundos o que te possibilita agregar valor ao seu time ágil com um feedback rápido.

Ahhhh mas não trabalho em um time ágil??? Sem MIMIMI comece a sair da zona de conforto e crie seu projeto de automação, nem que seja para o seu uso apenas ou que seja para aos poucos ir se tornando um QA mais técnico e possivelmente você estará se preparando para uma futura boa oportunidade que pode aparecer!

Ahhhhhhhhhhh mas eu não quero criar um projeto assim como o seu para experimentar uma ferramenta de automação de API tem opção? TEM! Então deixe a preguiça tomar conta de você e use mocks online em apenas alguns segundo e continue sem progredir, use por exemplo: http://www.mockable.io/


Dependendo da tecnologia e arquitetura do seu projeto, você consegue validar muitas funcionalidades sem utilizar um Selenium por exemplo, apenas com recursos de post e get é possível verificar as mensagens contidas no response, garantindo qualidade mesmo antes da UI ficar pronta.

Por hoje é isso! Recebi alguns ótimos e motivantes feedbacks sobre o primeiro post da série, mas também alguns falando que está em um nível muito iniciante e etc, deixo claro que envio prévias dos meus posts para pessoas menos experientes para justamente tentar ajudar todos os níveis e se nem Deus agradou a todos quem dirá EU rsrs vida de blogueiro é isso aí! :)


Este post fez parte do http://desafio.agiletesters.com.br fui desafiado pelo Stefan

11 comentários:

  1. Muito bom post, Fred! Parabéns :)

    ResponderExcluir
  2. Gustavo Moreira da Fonseca10 de dezembro de 2014 11:45

    Muito bom Fred,


    Já tinha falado do seu primeiro post e agora mais uma vez você mandou muito bem. Parabéns pelo trabalho!

    ResponderExcluir
  3. Kenya Nogueira Avelar15 de janeiro de 2015 18:00

    Excelente Fred!!

    ResponderExcluir
  4. Bacana!
    Ainda não tinha pensado sobre como testar serviços REST. E seu post esclareceu muito bem.


    Já pensou em testar utilizando o Jasmine?

    Só uma dica pra deixar os testes mais elegantes.


    Abs!

    ResponderExcluir
  5. Fala Henrique!! Obrigado!
    Não tinha pensado usar o Jasmine ainda não, tenho usado o Chai + Mocha é gero um relatório Xunit para acompanhar pelo Jenkins, mas é uma opção a considerar sim.
    Valeu pela dica! :)

    ResponderExcluir
  6. Valeu pelo Post Fred, voce havia comentado no primeiro post sobre Rest assured, tem algum materia que recomenda sobre essa tecnologia?

    ResponderExcluir
  7. Fala Fernando...Obrigado!

    O que você precisa em específico?

    Dê uma olhada neste link: http://www.hascode.com/2011/10/testing-restful-web-services-made-easy-using-the-rest-assured-framework/



    Acho que te ajudará a resolver bastante possíveis problemas que você pode estar encontrando.

    ResponderExcluir
  8. Cara preciso na verdade comparar o json q a aplicação me devolve com dados que eu ja tenho. seria para automatizar um teste de regressao onde quero garantir que o rest sempre ira retornar os valores.

    ResponderExcluir