BDD a saga — Parte I

E aí pessoal, tudo bem com vocês?
 Venho hoje trazer um pouco de um momento que venho passando como profissional. Acho que muitos de vocês já ouviram pelo menos alguma vez as palavras BDD, Cucumber, Calabash ou algo do tipo. Mas você sabe o que esses caras siginificam? Chegaram a dar uma olhada por ai? Acredito que acharam pouca coisa em português e muito menos que fizesse sentido para o seu momento de pesquisa. Eu fiz uma pesquisa bem grande nos últimos meses a respeito do assunto. Pois estou precisando estruturar isso em um modelo que seja apresentável para uma grande mudança dentro da empresa que estou hoje. Não apenas para criação de testes automatizados. Mas usar o conceito como um todo.

Com isso, fui atrás de muita coisa e agora vou compartihar com vocês um pouco do que descobri até agora.

Antes demais nada, você sabe o que é BDD?
 Behavior Driven Development (BDD ou ainda uma tradução Desenvolvimento Guiado por Comportamento) é uma técnica de desenvolvimento Ágil que encoraja colaboração entre desenvolvedores, setores de qualidade e pessoas não-técnicas ou de negócios num projeto de software.

Ai você deve ta se perguntando, “uma técinica de desenvolvimento Ágil”? Tá maluco? Só vejo o pessoal falando de automação e bla bla bla bla. Calma jovens, chegaremos lá. Continuando…

Algumas das práticas do BDD são:

  1. Envolver as partes interessadas no processo
  2. Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código
  3. Automatizar os exemplos para prover um feedback rápido e testes de regressão
  4. Usar deve (should em inglês) na hora de descrever o comportamento de software para ajudar esclarecer responsabilidades e permitir que funcionalidades do software sejam questionadas
  5. Usar simuladores de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos
Fonte: Wikipedia

Bacana, vimos que dos 5 itens cidatos, apenas o item 3 e 5 falam de testes. Então vamos com calma ao falar de BDD como um coneito voltado somente para testes automatizados. Mas você QA que está tentando ir para Automação de Testes, isso na verdade pouco importa pra você, é mais pra conhecimento.

Dando continuidade…

Vamos falar agora do Gherkin, você sabe o que é?

Gherkin é a linguagem que o implementa os conceitos do BDD. Permite descrever o comportamento do software sem detalhar como esse comportamento é implementado. Ela tem a capacidade de remover detalhes da lógica de programação e focar no comportamento que uma funcionalidade deve ter. Um arquivo Gherkin é estruturado da seguinte maneira:

  1. Título da funcionalidade.
  2. Descrição da funcionalidade.
  3. Cenários, compostos por uma sequência de passos, que descrevem uma interação entre um usuário e o sistema.
Fonte: Cucumber Wiki

Bom, acho que ficou claro que o Gherkin é o cara que faz o meio de campo entre o conceito BDD e o Cucumber. Falando em Cucumber você sabe o que é Cucumber? Não vale falar que é pepino, hahaha.

O Cucumber é uma ferramenta que traduz os comportamentos descritos utilizando a linguagem Gherkin diretamente para o código que irá executar os testes. Garantindo um dos princípios do BDD, que é melhorar a qualidade do software e reduzir os custos de manutenção por meio da execução automática de testes. Cucumber executa especificações executáveis escritas em linguagem simples e produz relatórios indicando se o software se comporta de acordo com a especificação ou não. Cucumber reduz o esforço para manter as especificações de requisitos, testes e documentação em sincronia — com cucumber todos os documentos são os mesmos — uma única fonte de verdade para todos na equipe.

Bacana né? Com o Cucumber conseguimos garantir o conceito do BDD inteiro, vide imagem a seguir.

Espero que com essas dicas você consiga entender melhor o que é cada um desses caras que conversamos e que você consiga também falar sobre eles em uma entrevista ou em um bate papo com sua equipe caso vocês não utilizem nada para guiar o desenvolvimento de vocês 🙂.

Minha saga continua contando um pouco do que venho passando nesses meses. Isso que estou falando pra vocês vai entrar em prática em um lugar que não tinha nada referente a testes automatizados. Minha ideia agora é trazer como estruturar bem sua feature falando como funciona cada detalhe da feature e para que serve. Talvez eu traga algo diferente. Mas se for demorar muito vou compartilhar no modo texto mesmo 🙂.

Espero que isso ajude vocês. Até a próxima pessoal.


Originally published at gist.github.com.