Gherkin: Padronização de escrita de cenário de teste

Eloisa Potrich
Qualidade de Software
4 min readOct 27, 2022
Imagem 1: Logo do Gherkin

O que é Gherkin?

"Gherkin é um conjunto de regras gramaticais que torna o texto simples estruturado o suficiente para o Cucumber entender." [1]

Em outra palavras, o Gherkin tem como função padronizar a forma de descrever especificações de cenários de teste, baseado na regra de negócio. Logo, sempre é necessário haver uma documentação de regra de negócio antes do Gherkin para que aja uma agilidade na escrita desses cenários.

Para entender mais como funciona o Cucumber, irei criar um artigo para falar mais sobre. Assim que eu o tiver, atualizarei este artigo.

Qual o propósito do Gherkin em um projeto?

Dentre tantos propósitos que existem, acabei pegando o que o próprio site trás pois acredito que sejam os mais importantes.

Os propósitos, são:

  • "Especificação executável inequívoca;
  • Testes automatizados usando o Cucumber;
  • Documente como o sistema realmente se comporta."[2]

Como é a extensão desse arquivo?

"Os documentos do Gherkin são armazenados em arquivos de texto com extensão em .featuree normalmente são versionados no controle de origem junto com o software."[3]

Dicionário do Gherkin

O Gherkin utiliza palavras-chaves para especificar a forma como cada step irá interagir com o sistema. Abaixo listei todas as palavras-chaves utilizadas:

  • Feature(Funcionalidade): É a funcionalidade principal dos conjuntos de cenários, ou seja, aqui será onde você irá nomear a funcionalidade que será testada;
  • Scenario(Cenário): É a funcionalidade especifica de cada cenário.
  • Scenario Outline(Esquema do Cenário): É utilizado para cenários que possuem mais de um exemplo.
  • Exemples(Exemplo): É informado os exemplos em forma de tabela.
  • Background(Contexto): É utilizado quando se tem mais de 1 cenário de teste para uma mesma funcionalidade.
  • Tags: É utilizado para organizar os cenários.
  • Given(Dado que): É uma pré condição. O tempo dessa linha costuma-se escrever no passado.
  • When(Quando): É uma ação que se espera vinda do usuário. O tempo dessa linha costuma-se escrever no presente.
  • Then(Então): É a validação do que foi feito nos passos anteriores, aconteceu. O tempo dessa linha costuma-se escrever no futuro.
  • And(E): É adicionado está palavra-chave quando é necessário adicionar mais um interação para complementar o fluxo no sistema.
  • But(Mas): É utilizada após uma validação negativa escrita depois do Então. Eu particularmente evito de utilizar essa palavra-chave, preferindo criar um novo cenário.

Como é a estrutura?

Aqui, irei mostrar como seria a estrutura completa de cenários de login escrito em Gherkin.

Primeiro, você deverá criar um arquivo em sua máquina com da seguinte maneira: <nomequepreferir>.feature

Iremos iniciar com a tag, indicando qual seria o nosso cenário de teste. Neste caso, seria: @login.

Em seguida, iremos colocar a funcionalidade, contexto e cenário.

Só um lembrete, aqui irei escrever tudo em português pois preferencia minha mas você pode definir essa questão de linguistica com o seu time.

Continuando…

Exemplo de Funcionalidade

@login
Funcionalidade
: Login
Sendo um usuário do sistema X
Quero completar o Login
Para que eu possa ter acesso às funcionalidade dentro do sistema.

Veja no exemplo acima que, em dentro de funcionalidade eu criei uma contextualização breve do objetivo desse teste. Eu sempre utilizo uma base de história de usuário para escrever. Veja que eu coloquei sendo, quero, para que, pois eu vejo que é muito efetivo esse tipo de escrita.

Exemplo de Cenário

@login
Funcionalidade
: Login
Sendo um usuário do sistema X
Quero completar o Login
Para que eu possa ter acesso às funcionalidade dentro do sistema.
Cenário:Login válido
Dado que o usuário possui uma conta no sistema
E ele acesse a página do Login
E ele preenche seus credenciais válidas
Quando ele clicar em "Acessar"
Então ele deverá ser direcionado para a página principal

Agora, em Cenários, adicionei um "passo a passo" de sucesso do que o usuário deverá realizar dentro do sistema.

Exemplo de Contexto

@login
Funcionalidade
: Login
Sendo um usuário do sistema X
Quero completar o Login
Para que eu possa ter acesso às funcionalidade dentro do sistema.
Contexto:
Dado que
o usuário possui uma conta no sistema
Cenário:Login válido
E ele acesse a página do Login
E ele preenche seus credenciais válidas
Quando ele clicar em "Acessar"
Então ele deverá ser direcionado para a página principal
Cenário:Login inválido
E ele acesse a página do Login
E ele preenche uma das credenciais inválidas
Quando ele clicar em "Acessar"
Então ele deverá ser direcionado para a página principal

Como iremos adicionar vários cenários de teste para uma mesma tela, utilizaremos o Contexto para que não fique muito repetitivo sempre a mesma linha.

E para finalizar, adicionaremos tags para cada cenário, ficando:

@login
Funcionalidade
: Login
Sendo um usuário do sistema X
Quero completar o Login
Para que eu possa ter acesso às funcionalidade dentro do sistema.
Contexto:
Dado que
o usuário possui uma conta no sistema
@positivo
Cenário
:Login válido
E ele acesse a página do Login
E ele preenche seus credenciais válidas
Quando ele clicar em "Acessar"
Então ele deverá ser direcionado para a página principal
@negativo
Cenário
:Login inválido
E ele acesse a página do Login
E ele preenche uma das credenciais inválidas
Quando ele clicar em "Acessar"
Então ele deverá ser direcionado para a página principal

Extensão do VS Code

Você pode utilizar o apoio de uma extensão do VS Code para escrever seus testes devido a indentação.

Segue: https://marketplace.visualstudio.com/items?itemName=alexkrechik.cucumberautocomplete

Eu particularmente, utilizo o próprio google docs para escrever.

Referências

[1][2][3] Cucumber. Smartbear. Disponível em: https://cucumber.io/docs/guides/overview/ Acessado em: 27 out. 2022

Projeto

Ebook

--

--

Eloisa Potrich
Qualidade de Software

Engenheira de Software, entusiasta de direito, cybersecurity, psicologia e forense.