Escrevendo seu primeiro cenário Cucumber

Previamente postei neste blog alguns artigos a respeito do que é BDD, para que serve e como aplicá-lo. Veja exemplos aqui: artigos-bdd-ciclosw

Hoje vamos dar continuidade aos estudos sobre implementação do BDD como método de ATDD, ou seja, a utilização dele para o processo de escrita de cenários de aceite. O foco aqui estará para os testes automatizados implementados pela figura do QA em um contexto de entrega incremental, onde as funcionalidades de um sistema de UI é separado por casos de uso.

Eu também descrevi aqui como implementar seu primeiro cenário de teste automatizado  com BDD utilizando a ferramenta SpecFlow e código C#. Mas hoje quero dar ênfase à escrita de uma feature, que vem a ser a parte de negócio da implementação BDD através do Cucumber, com base na sintaxe Gherkin.

 

Origem do Cucumber

Segundo a documentação do cucumber.io: “Cucumber é uma ferramenta que suporta Desenvolvimento guiado a comportamento (BDD, na tradução livre) – um processo de desenvolvimento de software que visa melhorar a qualidade do software e reduzir custos de manutenção.”.

Essa ferramenta foi criada em 2008, por Aslak Hellesøy, que foi desenvolvedor na ThoughtWorks e em 2014 fundou a empresa Cucumber Ltd. De acordo com suas palavras à uma entrevista da InfoQ: “Eu fui consultor por 10 anos antes de criar a ferramenta Cucumber. Nos primeiros 5 anos de minha carreira, todos os projetos nos quais trabalhei tinham os mesmos problemas:

  • Eu muitas vezes não sabia se tinha entendido todos os requisitos;
  • Eu achei difícil confiar no resultado daquilo que estávamos construindo
  • Eu tinha medo de mudar código pré-existente, sem saber o que poderia quebrar com as mudanças
  • Nós estávamos constantemente atrasados com as entregas

E continua: “Com o BDD, * todos * os testes são testes de aceitação do cliente, escritos em linguagem simples (humana) para que os interessados ​​não técnicos possam compreendê-los. Então, o Cucumber combina especificações de requisitos, testes automatizados e documentação viva em um único formato chamado Gherkin, que é simplesmente inglês com um pouco mais de estrutura.”.

 

Como escrever sua primeira feature

É importante salientar que, tecnicamente, existem diversas ferramentas que podem ser utilizadas para implementar BDD: Cucumber, SpecFlow, JBehave, RSpec, Jasmine, Cucumber-js, Lettuce, Lettuce, etc. E que BDD é um processo maior que a automação de testes!!!

Mas, considerando o cenário que utiliza automação de testes, como citado acima, o fluxo de desenvolvimento BDD pode ser ordenado da seguinte forma:

1. Descrever funcionalidades      2. Implementar cenários   3. Executar cenários

Na etapa Descrever Funcionalidades é a qual: entendemos requisitos e prioridades; listamos cenários de uso, seus fluxos e resultados esperados.

Na etapa Implementar Cenários é a qual: escrevemos os cenários de ATDD com gherkin; implementamos seus steps e page-objects; gravamos os cenários em uma ferramenta de controle de versão.

Na etapa Executar Cenários é a qual: organizamos os cenários em suítes de testes; configuramos variáveis de ambiente, drivers e runners dos testes para a execução dos cenários; integramos os cenários a uma  ferramenta de  integração contínua, caso necessário.

 

 

Agora vamos para a parte prática!

Continuar lendo

Por quê aplicar BDD?

Behavior Driven Development, ou simplesmente BDD, é uma metodologia para desenvolvimento de produtos que foi criada como técnica para atender às demandas que o TDD não conseguiu suprir. Ela surgiu como proposta ao contexto da codificação de software. A diferença entre as duas técnicas, TDD e BDD, foi explicada aqui: diferenca-entre-tdd-e-bdd/

Hoje, enxergo o BDD como prática colaborativa, porque sua aplicação efetiva é proveniente da interação entre pessoas, com propósito na melhoria da comunicação entre elas. Ou seja, esta é uma ferramenta que não está mais restrita ao âmbito técnico da construção do produto, porque passa por diversas camadas anteriores ao seu desenvolvimento: entendimento das necessidades do cliente e domínio de negócio por toda a equipe desenvolvedora do produto.

Benefícios

O BDD é uma ferramenta que detalha a camada do negócio e chega à área técnica para a correta implementação de comportamentos do produto. Isso porque ela:

  • Facilita o entendimento do negócio;
  • Descreve o resultado esperado pelo cliente;
  • Promove a discussão do negócio;
  • Delimita escopo do produto;
  • Previne a ocorrência de falhas no produto.

Todos os benefícios listados acima contam com esta origem: especificação por exemplos, ferramenta que deve participar nas conversas com o cliente. Assim, quando em sua aplicação, o negócio passa a ser especificado em formato de pequenos exemplos de uso: cenários, contando com critérios de aceite bem definidos: comportamento do produto, o cliente tem sua visão entendida e detalhada para a equipe técnica que irá construir seu produto. E isso resulta em qualidade na entrega do produto, já que ele contará com as funcionalidades desejadas por quem o solicitou.

Como aplicar?

Continuar lendo