Não me conhece? Seja bem vindo :) 

Meu nome é Frederico Moreira trabalho com testes desde o final de 2008, tem alguns anos que tento continuamente melhorar meu dia a dia de tester, estudando novas técnicas, novas tecnologias e tentando aplicar no meu dia a dia as novas tendências e ainda algumas tecnologias que ando estudando. Com isso procuro agregar mais valor nos times que trabalho, participando mais efetivamente dos projetos na qual sou envolvido e tentando resolver todos os desafios que aparecem nessa jornada.

Mas já pode estar se perguntando: Qual a relação da vida de um DJ com a vida de um QA?   

Para contextualizar melhor você, eu trabalhei como DJ durante minha graduação e parte da minha pós graduação para auxiliar no pagamento destas, esse tempo foi de meados de 2009 até o final de 2014, onde meu sócio resolveu casar e juntos resolvemos "fechar" nossa pequena empresa e cada um seguir a sua vida profissional, somos muito amigos até hoje, mas não trabalhamos mais profissionalmente com isso.

O primeiro ponto a ressaltar desta relação é a comunicação! Quando se participa de uma reunião de "Grooming" por exemplo é a hora que um QA vai ajudar o seu time a refinar os requisitos, mas como?  Levantando 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. Fazendo perguntas mesmo que pertinentes ou não, porque as vezes quando se entra em um time que já está trabalhando em um projeto, nem sempre você conhece as minucias do negócio.

Imagine agora você como DJ entrevistando um casal, na qual você irá tocar no casamento deles. Assim como em projetos de software você está lidando com o dinheiro do seu cliente, tocar em um casamento é lidar com o sonho de duas pessoas, imagine um casal que sonhou a vida inteira com aquele momento e você simplesmente estraga tudo no dia mais importante da vida deles.

Para isso na hora de assinar um contrato, eu abusava nas perguntas, como por exemplo: Qual estilo de músicas vocês querem que eu não toque? Tem alguma música especial quando entrarem no salão? Vocês irão dançar valsa? Tem alguma valsa específica? Tem alguma música que marcou a vida de vocês que eu não posso esquecer? Entre outras perguntas, deixando assim o mais claro possível o que um casal realmente esperava de mim no dia do casamento.

No final de um "ciclo" e/ou "interação" de desenvolvimento, quando trabalhamos com alguma metodologia ágil, nós não fazer uma reunião de PO Review, ou mostramos para o cliente o que agregamos de valor para o seu negócio, para que ele possa sentir se era aquilo mesmo que ele esperava.

Na minha vida de DJ eu convidava possíveis clientes(noivos) para irem em outros casamentos que eu ia trabalhar para eles conhecerem o meu trabalho e ainda durante as conversas que eu tinha com potenciais clientes, eu perguntava sabe aquela música que vocês escolheram? Tem alguma versão específica que querem? Ao vivo? Algum remix? Essa valsa tradicional serve? E assim por diante pensando em atender eles da melhor maneira possível.

Umas das virtudes que mais gosto é a aceitação a mudanças que um time ágil tem, quando se trabalha com metodologias tradicionais, temos aquela dura resistência a mudanças, mas em um time ágil sabemos que as mudanças são esperadas, porque sabemos que requisitos surgem e evoluem enquanto o produto é desenvolvido.

Quando uma festa de casamento está acontecendo, sempre tem alguém para pedir um ritmo que os noivos pediram para não tocar, ter jogo de cintura e saber lidar com essas situação fazem parte do dia a dia de um DJ, por diversas vezes pessoas convenciam os noivos a pedir aquele estilo de musica que durante as conversar, eles imploraram para não tocar. Você está ali sujeito a ter que improvisar e atender as possíveis mudanças do desejo de seus clientes.

Para fechar...

Pensando em melhoria eterna dos processos que um time ágil segue, é comum pedir feedbacks, celebrar as glórias e fazer reuniões como de retrospectiva, onde se "lava a roupa suja" e o time aprende o que pode melhorar para a próxima interação.

Em um casamento é super importante pedir feedback para seus clientes e para os convidados, é a oportunidade de conquistar novos potenciais clientes e ainda ter maturidade de absolver possíveis crítica, porque nem sempre em uma festa se consegue agradar a todos.

Bom esses foram alguns pontos que julguei ter relação da minha vida de QA em um time ágil com a minha vida de DJ. Espero que tenham gostado e estou a disposição para debatermos sobre esses pensamentos fora da caixa que gosto de escrever, mas fiquem a vontade de discordar de algum ponto por mim escrito.

Inspiração para este post, foi um post de um desenvolvedor que eu trabalhei, que para mim foi um dos melhores que tive a oportunidade de parear e aprender com ele.
Leandro Bitencourt

Até a próxima...

Tive um sonho realizado de conseguir fazer um evento em Belo Horizonte voltado para teste/qualidade de software, na abertura do evento contei um pouco da história, a ideia surgiu em uma iniciativa no fórum bem legal denominado agiletesters. Em um tópico as pessoas queriam saber o que você planejava para o ano de 2015 para evoluir na sua carreira e uma das minhas metas era fazer um evento do porte do MTC. Depois que joguei a ideia no ar, apareceu o Mateus apoiando a ideia e se colocando a disposição para ajudar na organização. Em conversa via linkedin surgiu a Samantha com a mesma iniciativa e compartilhando do mesmo sonho. Marcamos uma primeira reunião e fomos via Brainstorming definindo as primeiras tarefas e alinhando os valores e princípios que seguiríamos na organização do evento.

No início era muita indecisão, três pessoas sem experiência alguma em realização de eventos, tentando organizar um. Tirei algumas dúvidas com pessoas que já tinham feito eventos voltados para nossa área como JJ e Eduardo, a ajuda deles foram bem relevantes para o sucesso do nosso evento. Após as coisas começarem a efetivamente acontecer durante a organização, fomos procurados pela Renata, que estava disposta a ajudar na organização e logo aceitamos pois enxergamos a necessidade de mais pessoas para nos ajudar.

Logo no início eu particularmente tinha um imenso receio de não conseguir apoio/patrocínio para evento e para minha grata surpresa a Take.net comprou a ideia, em um tempo record já se pronunciou que gostaria de saber patrocinadora ouro do evento. Com isso ganhamos confiança, esta que aumenta a cada, pois cada vez mais pessoas nos procuravam para obter informações sobre o evento. Na sequência a Avenue Code também desde o início confiou na organização do evento. Como nosso primeiro evento, aprendemos algumas coisas importantes e conhecemos algumas pessoas que agiram má fé, ou seja, houve tentativa de explorar comercialmente o evento em troca de quase nada que iria agregar valor para que o evento acontecesse.

Aos pouco fomos conseguindo alguns apoios como Casa do Código, a UNA que nos cedeu o auditório, BHTec que nos cedeu sala para reuniões presenciais e o Uber. Mais próximo do acontecimento do evento chegaram a Base2 como patrocinador ouro junto da Qualister, QATest como bronze e Interasys e CaTechnologies.

Por ultimo deixei propositalmente a Qamob que além de arcar com todas as despesas iniciais do evento como criação e hospedagem do site até o registro da patente do MTC. Além disso os seus fundadores trabalharam voluntariamente no evento na organização em geral, no credenciamento dos participantes e ainda patrocinaram o brinde mais desejado "MOTO G".

Fizemos o nosso melhor, mas image você conseguir agradar umas 20 pessoas num churrasco, nem sempre é possível não é mesmo? Agora pense em cerca de 250 pessoas, cada uma querendo uma informação no seu tempo, algumas reclamando por não ter sua palestra aprovada, outras por não conseguir comprar ingresso e por aí vai...

Momento desabafo, mas essas coisas também precisam ser compartilhadas, desde o início tentamos divulgar o máximo que conseguimos, deixamos claro o motivo principal do evento que era fortalecer a comunidade de testadores de Minas Gerais e mesmo assim chegada a todo tempo um "caminhão" de reclamações e sugestões voltadas para o gosto pessoal. Na medida do possível conseguimos administrar essas situações e ganhamos maturidade para um evento melhor no próximo ano.

Vamos voltar a falar de coisa boa!

A emoção tomou conta, quando subi no palco para fazer a abertura do evento e o auditório quase todo cheio, alguns rostos conhecidos, outros jamais vistos. Mas mesmo antes disso a vendas das entradas nos surpreendeu muito, ainda faltavam praticamente 15 dias para o evento e não tínhamos sequer uma entrada disponível e já trabalhávamos com a venda apenas no caso de desistências.

Aconteceu alguma problema durante o evento?
SIMMM! Alguns marinheiros de primeira viagem junto fazendo um evento é claro que alguma coisa ia dar errado. Mesmo testando em alguns notebooks antecipadamente, na hora das palestras iniciarem não foram todos os notebooks de palestrantes que a entrada HDMI funcionou, não tínhamos em mãos um adaptador para VGA, isso acabou acumulando atrasos entre as palestras e tentamos contornar essa situação comprando adaptadores durante o almoço e controlando melhor o tempo das apresentações.

Palestras ahhh palestras, como foi difícil escolher, abrimos o call4papers com bastante antecedência e quando encerramos nos deparamos com quase 30 temas onde teríamos que escolher no máximo 10, para a escolha definimos alguns critérios como: Valorizar palestras de testadores de Minas Gerais, inclusão da mulher na computação, temas técnicos entre outros, mesmo assim não foi fácil, pois cada organizador ainda deixava seu gosto pessoal influenciar na sua escolha.

A cada palestra selecionada, entravamos em contato com o palestrante, pois parte deles não era de Minas Gerais e teria que arcar com suas despesas, tivemos apenas uma desistência por motivos pessoais, aproveito este paragrafo para agradecer a cada um dos palestrantes pela presença e por optar em nos ajudar a realizar um sonho.

Voltando para os momentos de satisfação, quando após o término do primeiro coffe break, pedi que todas as pessoas que estavam satisfeitas como o coffe erguesse sua mão, para minha surpresa não consegui identificar ninguém que não levantasse sua mão.

O tempo foi passando, as palestras acontecendo, o sentimento de dever cumprido foi chegando, pessoas pelos corredores elogiando, alguns deixando sugestões de melhorias, outros reclamando mesmo. Mas no geral foi ocorreu tudo de uma maneira satisfatória e com certeza ganhamos uma boa bagagem para que em 2016 podermos fazer um MTC melhor para todos.

No fim do evento nós da organização estávamos exaustos, mas felizes por realizar um sonho e comum e com a sensação de missão cumprida. No mesmo dia colemos feedbacks num quadro que deixamos exposto na entrada, mas ainda sim as redes sociais estavam num volume de comentários e elogios suficientes para que possamos chegar em casa e dormir tranquilo.

Me perguntem se quero passar por isso novamente? 
COM CERTEZA, usaremos as lições aprendidas com este primeiro evento, para que possamos fazer um MTC2016 muito melhor que este primeiro, para isso contaremos com mais pessoas na organização, repensaremos algumas formas de interação com o público e patrocinadores entre outros pontos que tentaremos melhoras.

Ficou alguma pendência do MTC, me procure, procure as pessoas da organização, critique mas também elogie, nossos canais de comunicação nas redes sociais estão a sua disposição.

Neste mês de agosto no dia 19 teremos um dia de teste solidário uma iniciativa da organização do MTC:
http://www.meetup.com/BH-Software-Testing-Meetup/events/224193105/

Obrigado!

Para os que não me conhecem, sou mineiro, assim como os demais, temos a fama de "come quieto", de ser tímido, somos pessoas acolhedoras entre outras características.

Há aproximadamente uma ano comecei a escrever neste blog, que hoje já conta com mais de 12.000 visitas e alguns comentários. Nos primeiros posts poucos acessos, quase que nenhum comentário, mas também pouca divulgação da minha parte. Eu querendo que as pessoas descobrissem meu blog sem ao menos divulgar, complicado né?

Então parti para divulgação em algumas listas que eu participava na maioria das vezes apenas como leitor, iniciei com o DFTestes e isso já vou o suficiente para despertar a curiosidade da comunidade e fazer os acessos quadruplicar em alguns dias. Assim como os acessos, os comentários também apareciam e eu fui tomando coragem a participar de maneira mais efetiva nos grupos e listas, contribuindo com as dúvidas relacionadas aos assuntos que eu possuía um maior domínio do assunto.

Em pouco tempo comecei a ver o quanto é gratificante um elogio, por menor que seja, o feedback e sentimento de ajudar alguém que passava por um problema similar ao que você já passou e você ali com pouco esforço conseguir contribuir para a solução de um problema de alguém com pouca experiência ou dificuldade técnica.

O blog serviu de ponta pé inicial para que eu começasse a dar a cara a tapa na comunidade, em novembro do ano passado, descobri via lista de discussão  que teria em Minas Gerais, mais específico em Uberlândia um evento voltado exclusivamente para testes de software o UaiTest. Foi quando tomei coragem e submeti uma palestra, após alguns dias recebo um email do João Júnior me informando que minha palestra tinha sido escolhida e lá estava eu, feliz e começando a me preparar para meu primeiro evento.

Chegando em Uberlândia conheci pessoalmente pessoas que sempre acompanhava via blog, twitter e listas como Stefan, Daniel Amorim e o próprio JJ. Como quase toda primeira vez, fiquei um pouco nervoso ao falar para um número maior de pessoas, acabei gastando um pouco a menos de tempo do previsto, mas a sensação de ouvir aplausos e ser elogiado ao descer do palco, sinceramente não tem dinheiro que pague. Naquela tarde ainda fui surpreendido por pessoas me parando com perguntas sobre minhas skills e pessoas interessadas na minha carreira.

"De lá para cá" perdi bastante parte da vergonha que tinha, graças há uma oportunidade do GUTS-RS em específico o Gabriel Oliveira pude participar de um Hangout ao vivo para todo país e poder contribuir um pouco com minha experiência.

Agora irei participar de mais um Hangout já aproveito para deixar um convite, o tema é bastante interessante além de ser uma novidade para muito testers.

Indo mais além, encontrei duas pessoas mineiras(Samantha e Mateus)  :) corajosas e juntos estamos tentando realizar um sonho que tínhamos em comum, fazer um evento de testes de software em Belo Horizonte a nível nacional. O evento promete, o Call4Papers está bastante movimentado e já apareceram bastante pessoas interessadas, tanto para ir no evento, quanto para apoiar e/ou patrocinar.

A intenção é realmente fortalecer a comunidade de teste de Minas Gerais, que há tempos anda meio parada e eu sei que aqui como em outras partes do país, temos bastante pessoas que podem contribuir para este crescimento. Aproveitando o post, para os mineiros e para quem animar vir em BH, montei um grupo no MeetUp onde vamos ter frequentemente encontros presenciais para discutir quaisquer temas que a comunidade julgar interessante.

Você que ainda não tem um blog, FAÇA um, compartilhe seus conhecimentos, frequente as listas e grupos de discussão, compareça a eventos e tente dar a cara a tapa e sinta a gratidão de um elogio!!

Por hora é isso, nos vemos em breve!

Abraços e voltem sempre!   

Bem vindo 2015! Já estamos em fevereiro e vamos lá para o primeiro post do ano e concluir esta série sobre "Como você anda testando sua Api Rest?"

Justificando o porque que escolhi os módulos Chai, SuperTest e Mocha para esta série de posts é porque atualmente trabalho num time que desenvolve Api Rest usando NodeJs como backend e estamos utilizando estes módulos para criar nossa suite de testes e até o momento tem nos atendido bem.

Eu adicionei na Api PhoneBook alguns arquivos e diretório que irei explicar de forma detalhada em seguida. Para auxiliar na preparação dos nossos cenários de teste eu criei um diretório denominado "db" com uma arquivo db.js como conteúdo, mas de forma específica o que faz este arquivo?

Utilizei o Mongoose que é um biblioteca do Nodejs que proporciona uma solução baseada em esquemas para modelar os dados da sua aplicação.

"Mongoose fornece um mapeamento de objetos do MongoDB similar ao ORM (Object Relational Mapping), ou ODM (Object Data Mapping) no caso do Mongoose. Isso significa que o Mongoose traduz os dados do banco de dados para objetos JavaScript para que possam ser utilizados por sua aplicação."  

Utilizando o mongoose eu criei três métodos públicos: drop, init e disconnect. Os nomes já são sugestivos para a responsabilidade de cada um dos métodos, o "drop" é justamente responsável por dropar(deletar) a collection, o init tem a responsabilidade de iniciar a conexão com o banco e o disconnect  para desconectar.

Estes métodos compõem a preparação de cada cenário de teste da nossa Api, criei também um diretório denominado test contendo dois arquivos: get-contacts.js e post-contacts.js, que respectivamente agrupam alguns cenários de testes dos verbos HTTP GET e POST.

Veja abaixo um exemplo da utilização dos métodos que criei do mongoose:

 Assim como no Junit geralmente usado no Selenium + Java o Mocha nos permite preparar nossos testes com os verbos before, beforeEach, after e afterEach. No exemplo acima antes de cada teste nos iremos deletar a collection "contacts" e ainda antes de executar todos os testes iremos conectar no banco e após a execução de todos os testes desconectaremos do banco. O que ganhamos com isso?
Garantimos que um a execução de um teste não influencia na execução do próximo.

Achei um figura legal que trás um comparativo interessante entre a terminologia entre Sql e Mongo para que posam entender melhor os termos do mongo como collection e document.

Bom o que eu tinha para trazer de informação neste ultimo post da série era isto, mostrar um exemplo de como estruturar seus testes junto ao código da sua Api, deixarei para vocês clonar a a nova versão da Api PhoneBook e executar na sua máquina os testes. Os testes ainda não contemplam todos os verbos HTTP que a Api oferece, fiquem a vontade para aumentar a cobertura e fazer um Pull Request no github me ajudando a aumentar a cobertura dos testes e ao mesmo tempo exercitando um pouco dos conceitos aqui apresentados.

Espero ter ajudado a esclarecer algumas possíveis dúvidas sobre automação de testes de Api, assim como utilização de NodeJs em conjunto com MondoDB e ainda a utilização do git. O que ando aplicando nos projetos que valem a pena dar uma olhada é:

• Formato HAL
• Extensão Postman
• Json API
• HATEOAS

Estou disponível sempre para conversamos sobre quaisquer dúvidas que se fizerem necessárias e no mais obrigado pela visita.

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 é:

"A 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: 

1. http://www.rodrigocalado.com.br/o-que-e-rest-um-resumo-do-assunto-caracteristicas-conceitos-vantagens-e-desvantagens-prefiro-dizer-que-e-uma-rapida-introducao-ao-assunto/
2. http://www.caelum.com.br/apostila-vraptor-hibernate/rest/#11-1-o-que-e-rest
3. http://www.infoq.com/br/articles/rest-introduction

Entres outros que vocês podem encontrar com uma rápida pesquisa no google. 

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:

• git clone https://github.com/fredmoreira/PhoneBook.git

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".

• http://docs.mongodb.org/manual/tutorial/install-mongodb-on-windows/

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...