BIGtheme.net http://bigtheme.net/ecommerce/opencart OpenCart Templates
25/07/2017 - 4:29 AM

Cucumber: Estrutura de Escrita de Cenários

Olá pessoal!

Hoje vamos falar um pouco sobre BDD e a estrutura de escrita de histórias de usuários utilizando o Cucumber.

Para começar, vamos esclarecer o que é BDD.

Behavior Driven DevelopmentBDD ou Desenvolvimento Guiado por Comportamento, é uma técnica do mundo ágil, que permite desenvolver softwares descrevendo o seu comportamento a partir da perspectiva dos stakeholders do projeto. A utilização dessa técnica encoraja colaboração entre desenvolvedores, testadores, clientes e pessoas não-técnicas ou de negócios que fazem parte da equipe de projeto.

A ideia principal por trás do BDD é construir o sistema incrementalmente com base no seu comportamento esperado (de fora para dentro). Diferente do TDD, que constrói o sistema a partir dos testes gerados, o BDD procura analisar os comportamentos esperados do software (foco no negócio) e então iniciar a construção do sistema.

Acredito que a grande vantagem em se utilizar BDD, está no fato de que esses comportamentos podem ser testados e automatizados com o auxilio de frameworks para BDD como o Cucumber.

O Cucumber não é uma simples ferramenta de teste! (Na verdade ele nem foi concebido para ser uma ferramenta de testes!) Ele une a facilidade de comunicação e interação entre os membros da equipe que vem do BDD, com a possibilidade de automatizar seu processo e ter um feedback muito mais rápido sobre o que está sendo desenvolvido/testado.

Lembrando que por mais benefícios que o BDD, o Cucumber ou qualquer outra técnica ou  ferramenta proporcione, é preciso avaliar as características e necessidades do seu projeto e equipe para decidir o que utilizar no desenvolvimento. Nem todas as melhores técnicas e ferramentas são adequadas a sua necessidade. 😉

O Cucumber utiliza uma linguagem própria para escrita dos critérios de aceite (caso de teste), o Gherkin, que foi projetada para ser não-técnica e facilmente compreensível para qualquer pessoa que leia.

A sintaxe do Gherkin é bem simples e de fácil entendimento, abaixo segue um exemplo da estrutura de uma história de usuário (caso de uso) e critérios de aceite (casos de teste) escritos em português .

Funcionalidade: <descrição da funcionalidade>

Como um <usuário>
Eu quero <realizar uma ou mais ações no sistema>
De modo que <eu consiga alcançar meu objetivo>

Cenário: <descrição do caso de teste>
Dado <um estado conhecido do sistema>
Quando <um determinado evento ocorrer>
Então <isso deve ocorrer ou o sistema deve responder dessa forma>

Cenário: <descrição do caso de teste 2>
Dado <um outro estado conhecido do sistema>
Quando <um outro determinado evento ocorrer>
Então <o sistema deve responder dessa forma>

As palavras em negrito definem a estrutura básica que deve ser seguida, elas são as palavras reservadas do Cucumber e qualquer história de usuário ou critério de aceite escrito deve seguir pelo menos essa estrutura. Existem outras palavras reservadas que podem ser utilizadas, lembrando que o Gherkin é traduzido para diversos idiomas e os exemplos aqui utilizados são todos em português.

  • Funcionalidade
  • Contexto
  • Cenário
  • DadoQuandoEntãoEMas (Steps)
  • Esquema do Cenário
  • Exemplos

O arquivo base do Cucumber é o .feature, cada arquivo desse, deve conter uma única funcionalidade do sistema ou uma característica em particular. A utilização da palavra chave Funcionalidade, não altera o comportamento do Cucumber, uma vez que ela é utilizada mas para fins de documentação, ou seja, é altamente recomendado utilizar essa palavra chave para documentar aspectos importantes da funcionalidade, como uma breve explicação ou uma lista de regras de negócio (critérios de aceitação em geral).

Um Cenário é um exemplo concreto que ilustra uma regra de negócio (caso de teste ou critério de aceitação). É constituído por uma lista de steps. O Cucumber não limita a quantidade de steps dentro de um mesmo cenário, mas o ideal é ter em 3-5 steps por cenário, mais que isso significa que sua descrição do cenário provavelmente não está muito boa e talvez seja necessário dividi-lá em mais cenários. Na pratica além de ser uma especificação e documentação do sistema, o cenário é também um teste, sendo assim, os cenários são uma especificação executável do sistema.

Uma boa prática na escrita de cenários é seguir o padrão:

Descrever um contexto inicial (Dado)
Descrever um evento (Quando)
Descrever um resultado esperado (Então)

Um step normalmente começa com Dado, Quando ou Então. Se houver vários steps iguais podemos usar E ou Mas. O Cucumber não diferencia entre essas palavras-chave, mas essa pratica ajuda a manter a boa legibilidade do critério de aceitação.

Dado é usado para descrever o contexto inicial do sistema. Geralmente é algo que aconteceu no passado.

Ex: Dado que estou logado no sistema

Quando é usado para descrever um evento ou uma ação, seja ela de uma pessoa que interage com o sistema, ou pode ser um evento desencadeada por um outro sistema.

Ex: Quando acesso o menu de usuários

Então é utilizado para descrever um resultado ou resultado esperado.

Ex: Então é apresentada a tela de edição de usuários do sistema

 

Bom, é isso galera! Com esse post de hoje quis apresentar um pouco do BDD e da estrutura que o Cucumber utiliza para descrever os critério de aceitação, caso tenha ficado alguma dúvida, comente! Não me aprofundei muito nos assuntos, pois, minha ideia era apresentar uma visão geral. Nos próximos posts vou começar a falar da montagem do ambiente e mostrar algum código.

Demorei muito mais do que gostaria para escrever esse terceiro post, mas vou tentar manter a regularidade. Até a próxima!!

 

Primeiro post da série: http://quatest.com.br/Portal/cucumber/

Segundo post da série: http://quatest.com.br/Portal/configurando-o-cucumber-no-eclipse/

 

Referências:

https://cucumber.io/docs

https://pt.wikipedia.org/wiki/Behavior_Driven_Development

https://en.wikipedia.org/wiki/Test-driven_development

https://dannorth.net/introducing-bdd/

 

Sobre Rafael Amaral

Rafael Amaral
Profissional apaixonado por tecnologia, atuando a quase cinco anos com Software Testing e Quality Assurance. Trabalhando atualmente com Automation Testing e management.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *