GHERKIN – Imperativo X Declarativo

Na área de qualidade de software, um dos conteúdos importantes de se aprofundar é a escrita dos cenários de testes. Uma escrita bem planejada é a garantia de que o software será entregue com qualidade. Vamos abordar nesse artigo a linguagem Gherkin que é muito usada na escrita dos cenários, mas antes de falar sobre a linguagem Imperativa X Declarativa, precisamos falar brevemente sobre o BDD – Behavior-Driven Development.

O BDD é uma ferramenta de desenvolvimento ágil que tem como principal objetivo integrar regras de um negócio à linguagem de programação, a fim de aprimorar o comportamento de um software. Ele é usado para criar casos de testes onde sua lógica permite um maior e mais fácil entendimento para todos. A criação dos cenários no BDD é feita através da “quebra” de um requisito dentro do contexto e necessidade de gerar cenários de teste que darão o resultado esperado. Esse processo geralmente é usado tendo como base a Sintaxe de Gherkin, que é uma espécie de linguagem que apoia essa lógica de escrita e aplicação do processo BDD.

Dicas de como fazer a especificação por exemplos no BDD

Usa-se uma indentação lógica com as palavras Dado, Quando, Então e, ocasionalmente, Deve, para então, dentro de um determinado contexto, gerar um cenário.
Mantenha seus cenários livres de detalhes de implementação. Incluir detalhes de implementação, por exemplo, botões de uma interface gráfica, vai dificultar a manutenção de cenários e funcionalidades.
Uma forma de fazer isso é manter um estilo mais declarativo ao invés de imperativo ao escrever cenários com a linguagem Gherkin.

Agora sim vamos falar um pouco sobre GHERKIN

Gherkin é uma poderosa linguagem natural desenvolvida para ser utilizada como forma de entendimento e compreensão acerca das especificações levantadas a partir da perspectiva do stakeholder. Tem a capacidade de remover detalhes da lógica de programação e focar no comportamento que uma funcionalidade deve ter. Uma das premissas do Gherkin é criar cenários de forma clara e objetiva, conforme as recomendações do BDD.

Um arquivo Gherkin é composto basicamente por:

Funcionalidade;
Descrição da funcionalidade;
Cenários: compostos por uma sequência de passos, que descrevem o comportamento do sistema.

Vamos entender melhor:

DADO, QUANDO, ENTÃO
GIVEN, WHEN, THEN
(PASSADO, PRESENTE, FUTURO)

Dado (Given) é uma precondição. * Muitas vezes começamos a escrever o dado como uma ação.

Quando (When) é uma ação.
Então (Then) é um resultado esperado.
E (And) visa complementar qualquer uma das palavras chaves citadas anteriormente
Mas (But) é a forma negativa do “Então”, quando o resultado esperado NÃO DEVE ocorrer.

Exemplos:

1. Dado número A
E número B
Quando somar A+B
E dividir por C
Então resultado deve ser D

2. Dado número A
E número B

Quando somar A+B
E dividir por C
Então resultado deve ser exibido
Mas não deve ser igual a D

Abordagem Imperativa:

Você descreverá “como” você faz alguma coisa.

Por exemplo, respondendo de forma Imperativa:

_“Vejo que a mesa próxima a TV está vazia. Minha companhia e eu vamos andando até lá e
nos sentaremos”.

O estilo imperativo usa Steps altamente reutilizáveis ligados à grande parte da interface do usuário e requer mais decisões de design. Se um novo campo for adicionado, você deverá atualizar o cenário para refleti-lo, mesmo que o objetivo do cenário não tenha mudado.

Vamos ver um cenário Imperativo (como):

Abordagem Declarativa:

Você descreverá “o que” você faz.

Por exemplo, respondendo de forma Declarativa:

“Mesa para dois, por favor”.

O estilo declarativo está mais alinhado com as histórias do usuário. O número de Steps é menor que o estilo imperativo, que tende a produzir Cenários com muitos Passos. Com o estilo declarativo, o objetivo do Cenário permanece claro. Quando uma nova Etapa é adicionada, ele não precisa ser modificado.

Vamos ver um cenário Declarativo (o que):

Após entendermos um pouco sobre o estilo Imperativo e o Declarativo, qual devemos escolher?

Um dos fatores mais importantes para decidir qual estilo usar (além da manutenção ou duplicação do código) é o cliente. Os recursos destinam-se a facilitar a comunicação entre o negócio, o desenvolvedor e o testador sobre o valor comercial e a funcionalidade.

Caso a necessidade dos interessados esteja nos campos de um formulário, ela é indicada no cenário para que haja confiança no sistema (pelos clientes), utilizando assim o estilo imperativo. Se as especificações precisam ser compreendidas por um público mais amplo do que os desenvolvedores, para alcançar um entendimento entre todas as partes interessadas, então usaremos um estilo declarativo.

Para isso, como na maioria das áreas de desenvolvimento de software, não existe uma resposta correta, no final depende apenas da situação. Agora que você já aprofundou um pouco seu conhecimento nas duas abordagens de escrita de cenários, saberá qual a melhor usar em cada circunstância.

Por Marina Alice Schreiner e Eliana Santos Cardoso. ✍🏻💬