Desmistificando o uso do Gherkin

4 dicas para escrever cenários de forma surpreendente

Published in

Revista DTAR

6 min readApr 22, 2021

Quem nunca pegou um cenário escrito em Gherkin e teve a ligeira sensação de estar lendo um caso de teste tradicional, cheio de passo a passo e pré-condições? Pois bem, nesse artigo irei compartilhar 4 dicas para a escrita de cenários em Gherkin que vão gerar maior valor para o produto e para o seu time.

Antes, precisamos esclarecer alguns conceitos que são facilmente confundidos quando falamos de temas como Gherkin, BDD e Cucumber. Vejamos de forma simples e direta o que cada um representa:

Gherkin: Disponível para mais de 37 idiomas, é uma poderosa linguagem natural desenvolvida para que humanos possam a utilizar como forma de entendimento e compreensão acerca das especificações levantadas a partir da perspectiva do stakeholder.

BDD: Da sigla Behavior Driven Development, é uma excelente metodologia de desenvolvimento ágil, que envolve membros do time trabalhando de forma colaborativa em conjunto com o PO, para descobrir e refinar os requisitos usando conversas estruturadas sobre exemplos de uso e comportamento de um sistema ou funcionalidade, buscando o entendimento compartilhado do contexto.

Cucumber: É uma ferramenta usada para executar testes de aceitação automatizados que foram criados sob a metodologia do BDD. Um de seus recursos mais destacados é a capacidade de realizar descrições funcionais de texto simples (escritas na linguagem Gherkin) como testes automatizados.

Resumidamente, a prática do BDD gera o Gherkin que por sua vez é utilizado por algumas ferramentas, a exemplo do Cucumber.

Representação da integração entre BDD, Gherkin e Cucumber

Como e onde usar Gherkin…

O Gherkin tem por finalidade auxiliar na escrita de critérios de aceitação de uma User Story, identificando os cenários mais importantes e gerando uma documentação viva e de valor para o negócio, tudo isso de forma colaborativa. Para isso, existem algumas práticas que podem facilitar essa comunicação entre usuários, desenvolvedores, testadores, especialista em negócios (product owner, gerente de produto ou analista de negócios). O Three Amigos é uma delas, uma maneira poderosa de construir um entendimento compartilhado sobre histórias, funcionalidades e como eles se encaixam no produto.

O Gherkin segue uma sintaxe que possui algumas palavras chaves, as essenciais nesse momento são:

Dado: (Given) O “Dado” seria basicamente as pré-condições do cenário.

Exemplos:
Dado que o usuário tem acesso ao sistema
Dado que o usuário tem acesso à área administrativa
Dado que o usuário está logado

Quando (When) O “Quando” serve para descrever as ações chave que o usuário executa, ou seja, qualquer ação de interação do usuário com o sistema.

Exemplos:
Quando o usuário realiza login
Quando o usuário cadastra um novo produto
Quando o usuário altera uma publicação

Então (Then) O “Então” visa mostrar as saídas, os resultados das ações executadas, os resultados esperados.

Exemplos:
Então os dados do usuário logado devem ser exibidos
Então o produto é alterado com sucesso
Então a publicação é cadastrada com sucesso

Veja um exemplo completo de como seria um cenário escrito em Gherkin:

Dado que o usuário está logado
Quando o usuário exclui uma postagem no blog
Então a postagem é excluída com sucesso

Parece fácil, não? É exatamente nessa “facilidade” que mora o perigo e onde surgem diversas formas de interpretação do Gherkin.

É comum nos depararmos com cenários escritos em Gherkin que são praticamente uma transcrição de casos de teste tradicionais, com passo a passo enormes de validação de tela, de forma imperativa, quebrando totalmente o conceito de comportamento de usuário. Veja no exemplo abaixo o que você nunca deve fazer ao escrever um cenário em Gherkin.

Dado que acesso ao site
Quando estou logado
E busco um produto na página principal
E seleciono um produto
Então deve ser direcionado para a página do produto
E deve ter o navigation
E deve ter a opção de zoom
E deve ter as imagens do produto
E deve ter a descrição do produto
E deve ter o título do produto
E deve ter a marca do produto
E deve ter a avaliação do produto
E deve ter o preço do produto
E deve ter Botão “Adicionar no Carrinho”

Não, esse cenário não é uma ficção para exemplificar o que não devemos fazer, ele existe, fruto dessa grande confusão que foi criada na forma de como utilizar o Gherkin. O resultado é um cenário que mais parece um caso de teste tradicional, cheio de passo a passo para ser validado.

4 dicas para melhorar a escrita de cenários em Gherkin

1 — Procure sempre escrever os cenários em terceira pessoa:

A perspectiva de terceira pessoa é inteiramente genérica e pode nomear expressivamente qualquer usuário ou componente do sistema. A primeira pessoa limita semanticamente a cobertura expressiva de uma etapa, forçando presunções de quem está escrevendo.

Forma recomendada:
Dado que o usuário está logado
Quando o usuário exclui uma postagem no blog
Então a postagem é excluída com sucessoForma não recomendada:
Dado eu estou logado
Quando eu excluo uma postagem no blog
Então devo ver que a postagem é excluída com sucesso

2 — Escreva cenários declarativos, não imperativos

Os cenários devem ser escritos como um usuário os descreveria. Cuidado com cenários que possuem muitos detalhes que não são relevantes para a pessoa que vai ler, por exemplo, clicar em links e preencher campos de formulário.

Forma recomendada:
Dado que o usuário possui credenciais válidas
Quando o usuário faz o login
Então ele tem acesso aos seus dadosForma não recomendada:
Dado que o usuário está na tela de login
Quando ele digita o usuário "admin"
E digita a senha "admin"
E clica em "Logar"
Então o usuário deve visualizar a sua tela inicial com os seus dados
E deve ver a mensagem "Bem-vindo Admin"

Escrever cenários de forma imperativa tem algumas desvantagens, como podemos ver no exemplo acima. Dado o nível de detalhamento, acaba sendo necessário escrever 5 linhas para comunicar a ideia de que o usuário tem acesso aos seus dados. Além disso, criar cenários dessa forma demanda um tempo maior de todos os envolvidos. Por fim, a manutenção desse tipo de cenário se torna mais custosa e difícil.

3 — Insira uma narrativa

As narrativas descrevem em cerca de uma frase o que um recurso faz. Eles também fornecem uma breve visão geral do recurso para que outras pessoas tenham uma compreensão aproximada do que se trata.

Exemplos:
Cenário: Exibir dados pessoais do usuário
Cenário: Cadastrar um novo produto com sucesso
Cenário: Realizar login do usuário com sucesso

4 — Evite passos conjuntivos

Ao encontrar uma etapa que contém duas ações em conjunto com um “e”, você provavelmente deve dividi-la em duas etapas. No entanto, não é uma regra geral, pois podem haver razões para etapas conjuntivas, mas, na maioria das vezes, é melhor evitá-las.

Esse seria o exemplo de um cenário escrito em Gherkin utilizando as boas práticas:

Forma recomendada:
Cenário: Cadastrar um novo produto com sucesso
  Dado que o usuário tem permissão para cadastrar produtos
  Quando ele preenche as informações corretamente
  E envia os dados
  Então o produto deve ser cadastrado com sucessoForma não recomendada:
Cenário: Cadastrar um novo produto com sucesso
  Dado que o usuário tem permissão para cadastrar produtos
  Quando ele preenche as informações corretamente e envia os dados
  Então o produto deve ser cadastrado com sucesso

Concluindo

Lembre-se, quando você domina a sintaxe do Dado, Quando e Então, é muito mais fácil e produtivo escrever cenários em Gherkin. Além disso há maior facilidade no entendimento dos cenários, quando lido por qualquer pessoa, e podemos reutiliza-los para a construção de testes automatizados. Outro ponto é que a manutenção destes testes se torna mais fácil, por usarmos uma linguagem mais clara.

Então, vocês já aplicavam as boas práticas na escritas de cenários em Gherkin? Utilizam mais alguma estratégia para melhorar e padronizar o entendimento dos cenários? Fique à vontade para comentar e deixar sua opinião!

Esse post foi resultado de uma discussão que surgiu em uma mentoria no #DTAR, onde pude contar com o grande apoio e parceria do Júlio de Lima na revisão do conteúdo. Espero que essa colaboração seja útil e esclarecedora para toda a comunidade.