Frederico Moreira

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



Vamos a definição de REST, também conhecido como Representational State Transfer ou ainda Transferência do Estado Representativo, segundo o Wikipédia REST é:

"Transferência de Estado Representativo (Representational State Transfer) ou somente (REST) é uma técnica de engenharia de software para sistemas hipermídiadistribuídos como a World Wide Web. O termo surgiu no ano de 2000, numa tese de doutorado1 (PHD) sobre a web, escrita por Roy Fielding, um dos principais autores da especificação do protocolo HTTP que é utilizado por sites da internet."

REST não é um padrão muito menos um protocolo, a definição que acho que melhor se encaixa é que REST é um estilo arquitetural para aplicações. REST define um conjunto de princípios simples que devem ser seguidos para a implementação de uma API. Alguns dos seus princípios são:
  • URL identifica um recurso 
  • URLs tem uma hierarquia 
  • Métodos executam operações em recursos 
  • As operações devem ser implícitas 
A intenção deste Post não é definir, nem discutir princípios e boas práticas de REST e sim como podemos testar uma API REST. Para quem quiser aprofundar mais nos conceitos para entender melhor o que é o estilo arquitetural REST pode ler esses links: 

Motivado por este post eu escrevi uma API REST simples para que possamos experimentar ferramentas/frameworks de automação de testes para api's rest, a api irá persistir os dados num banco MongoDB (já aproveita e instala o Mongo é bem simples e no site tem todas as informações) iremos utilizar os recursos do protocolo HTTP (PUT, POST, DELETE e GET) para atualizar, criar, excluir e consultar contatos na nossa agenda telefônica.

Você pode estar perguntando porque eu não publiquei esta api e disponibilizei uma Url para facilitar?
Propositalmente quero que tenham a oportunidade de ter contato com o MongoDB, Java Script - NodeJs e o GitHub. Muitos testadores se quer tem um conta no GitHub que é uma excelente fonte de códigos para estudar e ter contato com diversas linguagens e frameworks.

Para começar vamos instalar na sua máquina o NodeJs e o MongoDB que são requisito para executar nossa API.

Mongo : Download Install
Node.Js : Download Install


 Para prosseguir caso não tenha uma conta no GitHub  aproveite para criar, logo em seguida acesse a nossa API-PhoneBook que utilizaremos como base para automatizar alguns cenários de testes. Na página no github existe uma pequena documentação no "Readme.md" que pode ser útil para testarmos algumas chamadas na api de forma manual para entendermos o que vamos automatizar.




Se você já criou sua conta no github apenas clone o projeto na sua máquina:
Se não faça download do projeto no github e descompacte em um local de sua preferência.
Com o projeto na sua máquina acesse o diretório raiz onde tem o arquivo "package.json" que contém as dependências do projeto e execute o comando:
  • "npm install" ou apenas "npm i"

Agora inicie o mongo para que quando a api for iniciada ela possa já conectar ao banco, pois caso o mongo não esteja iniciado a api também não conseguirá ser "startada".

Agora vamos iniciar o mongo para que a aplicação quando iniciar possa acessar o banco e persistir os dados. Para iniciar o mongo basta digitar o comanda abaixo caso tenha colocado o mongo na estrutura proposta no seu site. 
C:\mongodb\bin\mongod.exe --dbpath d:\test\mongodb\data
Uma dica é colocar o mongo como serviço do seu sistema operacional para evitar que você inicie sempre o mongo manualmente.
Agora podemos iniciar a aplicação para começar a testar a api.
  • npm start


Agora que iniciamos a aplicação, vá até o browser e digite :

  • http://localhost:5000/
E verifique que a API está funcionando.
Vale ressaltar que a princípio eu deixei a porta 5000 configurada para rodar a API, nada impede de vocês irem no arquivo "server.js" e alterar para a porta que desejarem.

Vamos começar a persistir alguns dados manualmente para verificar o funcionamento da API, existe diversas maneiras de fazer isso, irei usar uma extensão do Chrome denominada Postman.
Existem diversas outras ferramentas que possibilitam executar chamadas na api manualmente como o Fiddler e o SoapUI.
Para acessar o Postman digite no Chrome: chrome://apps/.
Preencha os dados para criação de um contato da seguinte maneira:
Enviei a requisição post no botão "send" e o retorno deve ser:

Desenvolvi a api para responder um json com os dados que foram persistidos e o mongo automaticamente gera um "id" para o registro conforme destacado acima e ainda o status "201 Created" que é o status padrão para uma resposta de um post. Para saber o um pouco mais sobre os status que podemos retornar acesse http://i.stack.imgur.com/whhD1.png

Depois de ver a api persistindo podemos dar um get via browser ou via postman para ver o registro que acabamos de persistir.




Bom esta foi a parte de preparação e testes manuais na api que desenvolvi, fiquem a vontade para explorar mais alguns recursos de atualizar e excluir registros presentes na api, além da opção de pesquisar registros com filtros(Query String). Estas informações estão no readme do projeto da api presente no github. Caso achem possíveis bugs favor me informar.

Na parte II desta série de testes em API REST vou demonstrar algumas ferramentas que conseguimos automatizar os nossos testes desta api de exemplo que escrevi, para os preguiçosos de plantão escrevi o post orientando como preparar e executar uma api simples em ambiente windows e ainda irei publicar para quem não quiser executar a api localmente poder a partir de uma url automatizar seus testes.

Em breve a parte II estará publicada, aproveite e leia blogs e artigos sobre Rest-Client em Ruby, Rest-Assures em java, FrisbyJs, Mocha e SuperTest em Java Script, pois irei escrever alguns testes possivelmente em uma dessas ferramentas.

Aproveite o código da api e estude um pouco sobre Java Script, NodeJs, Mongo, Mongoose e etc!

Dúvidas, elogios e críticas são sempre bem vindas :) 

Até breve...


Comecei a me interessar por Agile Testing um pouco após do início da minha carreira, porém sem efetivamente saber do que se tratava. Em 2009 quando eu ainda tratava a Automação de Testes como um “super” desafio, através de um amigo de profissão tive acesso ao Livro Agile Testing – A Practical Guide for Testers and Agile Teams que assim como a grande maioria dos testers que já leram este, julgo como a bíblia do Agile Testing.

Mas antes de prosseguir já deixo uma primeira dica que é antes de estudar sobre Agile Testing, primeiro estudar sobre o “Manifesto Ágil”, considero de imensa importância entender os valores e princípios do manifesto, porque qualquer abordagem, práticas e etc que se derivar do manifesto irá seguir os mesmos valores e princípios.

Atualmente vejo em muitos currículos e até em perfis no Linkedin as pessoas escrevendo conhecimento em Agile Testing, mas será que estas realmente possuem este conhecimento? Assim como as pessoas as vezes falam que trabalham em times ágeis e na verdade aplicam parte de uma metodologia apenas, sem ao menos preocupar se estão agregando valor ou efetivamente aplicando as recomendações básicas da metodologia utilizada.

Acredito que não é apenas colocar um chapéu e dizer eu sou um Agile Tester ou então apenas por ter fortes skills de automação considerar ser um agile tester, o papel de um tester em um time ágil gira muito além de saber automatizar testes ou aplicar uma prática de BDD.

Partindo da quebra de paradigma que é necessária para atuar de uma forma mais efetiva em um time ágil, onde julgo que a comunicação é tudo, o tester precisa ter coragem, no sentido de sentar ao lado de um desenvolvedor e de uma forma amigável falar que alguma coisa não está certa ou não está retornando um comportamento esperado e ainda ajudando aumentar a cobertura dos testes unitários num time que utiliza TDD por exemplo. Até mesmo na hora de ajudar esclarecer um desejo de um cliente com perguntas, mesmo que talvez estas não sejam sempre pertinentes.


Enquanto nas metodologias tradicionais os testers esperam pelo documento de requisitos para deste derivar seus casos de testes, num time ágil o papel de um tester é questionar, levantar a maior quantidade de dúvidas que você tiver a respeito dos desejos de um cliente, ajudando assim não só a ele mesmo, mas o time inteiro entender melhor o que o cliente realmente deseja, como consequência você irá ajudar no planejamento gerando assim tarefas mais objetivas.

  Automação de Testes

 As skills de automação de testes desempenham um papel fundamental no Agile Testing, mas estas estão longe de ser o objetivo final, nem mesmo os testes manuais feitos de maneira exploratória, o objetivo do Agile Testing é fazer com que os testes sejam parte integrada e natural dentro de um processo de desenvolvimento ágil que seja Scrum, Kanban ou qualquer outro.

"Coisas" Técnicas

Entender de "coisas" técnicas é essencial! Muitas vezes testers tradicionais não tem acesso ao banco de dados da aplicação que estão testando, quando tem acesso nem se quer executam um Select qualquer. Não tem mais como fugir disto, pode ter certeza que entender "coisas" técnicas vai agregar e muito valor ao time e a qualidade do produto desenvolvido. 

Defino coisas técnicas como coisas "simples" mesmo, como uma query sql, alguma ferramenta de integração continua como Jenkis, Bamboo e Continuum, entender um pouco de CSS, um pouco da linguagem que o time utiliza, conhecer e utilizar algum framework da família xUnit. Não é se tornar especialista, mas sim saber como utilizar uma ferramenta X,Y,Z em pró do time ou saber o básico da linguagem utilizada no time para aumentar a cobertura dos testes unitários junto ao desenvolvedor por exemplo, não só implementando, mas contribuindo com cenários de testes que só nós conseguimos imaginar.

Testes Exploratórios

Segundo Elisabeth Hendrickson testes exploratório é "Uma abordagem sistemática para descobrir riscos utilizando técnicas de análise rigorosas juntamente com heurísticas de testes".

"Em um time ágil os testers utilizamos testes exploratórios para ajudar o time a identificar se estão evitando, com sucesso que os bugs cheguem ao código final." 

Teste manual existe sim em Agile Testing, mas de uma maneira diferente, na verdade de forma exploratória, onde simultaneamente um tester vai aprender sobre o software que está testando, utilizando a sua experiência e usando sempre o feedback do ultimo teste para executar o próximo.

Vinculado ao assunto os testers pode utilizar o SBT (Session Based Test) onde criamos um pequeno documento conhecido como Charter, podemos dizer que o charter é o objetivo do teste baseado em sessão. Abaixo segue um exemplo:

Explore it! By Elisabeth Hendrickson

A maturidade do time é muito importante, pois a qualidade passa ser responsabilidade de todos da equipe não só da pessoa com o papel de tester, o time agora é auto-organizado, onde a comunicação é tudo e fugindo do tradicional o time não responde mais e-mails, foco na colaboração, teste agora é uma atividade não mais uma fase, a suposição perde espaço para perguntas, prevenir bugs é MAIOR que procurar bugs, as alterações requisitados pelo cliente são "bem vindas", ou seja, são vistas de maneira diferente do tradicional e possuem maior aceitação.

Qualidade = Responsabilidade do Time

Uma das atividades mais interessante na minha opinião é decidir junto ao time a estratégia de automação de teste, ou seja, definir  em qual nível deve-se automatizar um cenário de teste, diferente dos tempos que eu trabalhava em empresas onde existia apenas testes automatizados na profundidade de interface (GUI Tests) e ainda feita apenas por testers, muitas vezes sem se pensar em arquitetura de um projeto de teste automatizado, algumas vezes projetos feitos apenas com record-play e sendo executado em uma quantidade de horas que tornava na maioria das vezes o projeto de automação incrédulo na visão de gerentes de projeto e diretoria de tecnologia das empresas. 

Pirâmide de Automação de Testes

Assim como a um tempo atrás eu fiz, aconselho a você testador, de modelo tradicional ou não, profissional alocado, profissional de fábrica de teste ou software a repensar sua carreira, é colocar na balança seus conhecimentos e desejos de evolução. Sair da zona de conforto quase sempre é um bom combustível de ânimo para uma evolução na carreira e possibilitando até a realização de um sonho de trabalhar com atividades incríveis/desafiadoras em um ambiente incrível que você sempre almejou. 

Adeus Zona de conforto

Muitas pessoas vão dizer: "Mas existe isso?""Existe este lugar?" Sinceramente não sei se todos encontrarão, mas ao apostar numa oportunidade que eu tive, me fez sair da zona de conforto e encontrar um ambiente / atividades com características bem perto do que eu sempre quis trabalhar.

A intenção  deste post foi trazer algumas informações e opiniões minhas sobre Agile Testing, já possuo uma certa experiência atuando efetivamente em times ágeis, mas acredito que temas como este são passíveis de discussões e de uma diversidade imensa de opiniões. Fiquem a vontade em concordar ou não, aqui críticas são bem vindas também! :)

Referências:

Elisabeth Hendrickson:
  1. http://www.slideshare.net/ehendrickson
  2. Explore It! new book on Pragmatic Programmers

  • https://leanpub.com/AgileTesting/read
  • http://blogdojonas.com.br/2014/05/18/o-papel-dos-testadores-nos-times-scrum/
  • http://www.stickyminds.com/article/how-software-tester-helps-during-product-discovery?page=0%2C1
  • http://blog.myscrumhalf.com/2014/03/melhorando-sua-estrategia-de-testes-automatizados/
  • Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin e Janet Gregory
Quantas vezes tentamos acessar uma página e não conseguimos, recebemos uma página contendo uma mensagem de erro. Quem nunca passou por isso?



Muitas pessoas quando acessam uma página, não tem ideia do que acontece nos bastidores para que esta página possa ser exibida.

Existe um protocolo denominado HTTP(HyperText Transfer Protocol) que é o responsável pela comunicação entre o seu navegador Web e o servidor onde a página está hospedada. 

Os servidores onde as páginas estão hospedadas sempre que requisitados, retornam um código de resposta HTTP para quem fez uma requisição. 

Podemos ressaltar a importância desses códigos para um time de desenvolvimento, pois estes informam o status de uma requisição de uma página ou de algum recurso dela. Estas informações podem ser usadas como Debug por exemplo durante um ciclo de desenvolvimento.
 


Esses códigos de status HTTP podem ser classificados em cinco grupos específicos, sendo que o primeiro dígito de cada grupo especifica a sua classe de resposta:

  • Classe 1xx (Informativo)
  • Classe 2xx (Sucesso)
  • Classe 3xx (Redirecionamento)
  • Classe 4xx (Erro gerados pelo lado do cliente)
  • Classe 5xx (Erro do Servidor)

Irei mostrar alguns exemplos de cada classe.

100 - Continue - O cabeçalho do pedido foi recebido pelo servidor corretamente eo cliente pode continuar a enviar o corpo da solicitação.

101 - Ligue o Protocolo - O cliente tem solicitações ao servidor para mudar o protocolo e o servidor está respondendo de forma positiva.

102 - No processo - Devido a este código, ele indica que o servidor recebeu o pedido do cliente e processar o pedido, mas a resposta ainda não está disponível. Devido a este cliente não se expirou e presume-se que o pedido foi perdido.

201 - Criado – A solicitação foi bem sucedida e o servidor criou um novo recurso.

202 - Aceito – O servidor aceitou a solicitação, mas ainda não processou.

305 – Utilizar Proxy – O solicitante poderá acessar a página solicitada utilizando um proxy. Quando o servidor retornar essa resposta, também indicará qual proxy o solicitante deverá usar.

400 - Solicitação Inválida – O servidor não entendeu a sintaxe da solicitação.

404 - Não encontrada - A página solicitada não se encontra agora, mas podem estar disponíveis no futuro.

406 - Não Aceitável – A página solicitada não pode responder com as características de conteúdo solicitadas.

505 - Versão HTTP incompatível – O servidor não é compatível com a versão do protocolo HTTP usada na solicitação.

O protocolo HTTP define somente alguns códigos em cada classe descritos na RFC 2616, mas cada servidor pode definir seus próprios códigos.

Referências:

http://www.testinginterviewquestion.com/2014/06/what-are-different-http-status-codes_5.html

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

http://www.w3schools.com/tags/ref_httpmessages.asp