Não é novidade para ninguém que a modalidade "teste automatizado" tem crescido rapidamente no mercado de qualidade de software atual. Na esteira dessa nova realidade, termos como Gherkin ganham notoriedade, mas você já se perguntou o porquê?

O teste automatizado, como o próprio nome diz, automatiza rotinas repetitivas de teste para que o testador não precise gastar tanto tempo fazendo todo o fluxo manualmente. Com isso, bastante tempo é economizado, de modo que possa ser utilizado para focar em outras tarefas mais específicas.

Sendo tempo um recurso importantíssimo e irrecuperável, principalmente na correria que vivemos nos tempos atuais, dispensamos a necessidade de exaltar mais ainda a importância da automatização.

Mas você deve estar se perguntando, onde o "Gherkin" entra nisso? O Gherkin tem sido uma opção muito forte na automação atualmente, pois se trata de um formato que podemos utilizar para padronizar, documentar, e até reciclar código e funcionalidades.

O que é o Gherkin?

O Gherkin é um dos elementos principais quando se trata de BDD em automação. Sua função é padronizar a forma de descrever especificações de cenários, baseado na regra de negócio.

Leia mais: o que é BDD?

Ele também serve para deixar nossos testes automatizados super fáceis de se ler, inclusive, para uma pessoa totalmente leiga no assunto. A programação vai "por trás", já que, literalmente, o tester vai escrever um código para executar, na prática, o que o Gherkin descreve.

O Gherkin segue alguns padrões, afinal, ele deve ser focado na regra de negócio. Ele é escrito em forma de "steps" (ou "passos"), os quais especificam cada etapa de interação do usuário com o sistema a ser testado.

Sendo assim, se trata de literalmente de uma descrição da regra de negócio do sistema, em forma passo-a-passo, simples assim. Por exemplo, para fazer um login na aplicação XPTO, teríamos os passos definidos na mão, mais ou menos, da seguinte forma:

1. Pré condição: Possuir uma conta no sistema
2. Acessar a página de login
3. Preencher credenciais
4. Clicar no botão de login
5. Esperar o login ser completado

Simples, certo? Agora, vamos converter esse fluxo para o padrão Gherkin.

O padrão Gherkin

Antes disso, é preciso entender que no Gherkin existem "keywords" (ou "palavras-chave") a serem utilizadas para especificar a forma como cada step interage com o sistema. Dentre todas, as essenciais nesse momento são:

• Given (pt: Dado): Utilizado para especificar uma pré condição, dentro desse step é feita a validação de uma condição antes de se prosseguir para os próximos passos. Por se tratar de uma pré condição, normalmente vem escrito no passado;
• When (pt: Quando): Utilizado quando será executada uma ação de que se espera uma reação vinda do sistema, que será validada no step "Then". Este passo vem escrito no presente;
• Then (pt: Então): Valida se o esperado aconteceu. Segue sempre um passo do tipo "Quando", pois aqui é validada a reação da ação recebida. Por se tratar do resultado esperado, normalmente vem escrito na forma de futuro próximo;
• And (pt: E): Caso seja necessário mais uma interação com o sistema para complementar um fluxo, mas que não necessariamente se trata de uma ação ou reação, se utiliza "And";
• But (pt: Mas): No geral serve a mesma funcionalidade do "And", porém é normalmente utilizado após uma validação negativa depois do "Then";

Sabendo disso, podemos traduzir a nossa etapa de login no sistema XPTO para:

1. Dado que "Fulano" possui uma conta no sistema
2. E ele acessa a página de login
3. E ele preenche suas credenciais válidas
4. Quando ele aciona a opção de realizar login
5. Então ele deve ser redirecionado para a página inicial logado

Utilização de personas

Também é importante notar que estamos descrevendo uma ação que uma terceira "pessoa" está executando. Portanto, utilizar o nome de um "Fulano" é sempre interessante, afinal, esse “Fulano” é uma das personas que irá interagir com o nosso sistema, e pode ter qualquer nome.

Utilizar personas é um padrão quando se trata de user stories, e a descrição feita no Gherkin é, de certa forma, um user story. Essa prática na automação é interessante para, por exemplo, as interações ficarem mais legíveis e, também, na geração de um report ao final de cada execução, assim como em logs de Jenkins e/ou Docker.

Até aí tudo bem, mas aonde iremos escrever/programar/desenvolver isso tudo? Tudo que temos até agora é puro texto!

É verdade, por esse motivo então vamos agora entender as "Features" (ou Funcionalidades).

As features do Gherkin

O arquivo no formato .feature é o que contém os Gherkins. Em uma feature existem outras keywords, que descrevem características da funcionalidade descrita ali, diferente das keywords de steps. Essas keywords são:

• Feature (pt: Funcionalidade): Serve para nomear a funcionalidade a ser testada nesta feature;
• Background (pt: Contexto): Quando existem mais cenários em uma feature que possuem a mesma pré condição, essa pré condição pode ser definida dentro de um único contexto para ser executada sempre antes da execução de qualquer cenário da feature, reaproveitando o mesmo passo em vários cenários diferentes;
• Scenario (pt: Cenário): Também chamado de exemplo. Descreve o comportamento esperado (Then) dado as pré condições (Given) e ação (When) especificada.

Adicionalmente, mas que não iremos utilizar agora, temos:

• Scenario Outline (pt: Esquema do Cenário): São cenários de negócio que possuem mais de um exemplo. Serão executados na mesma quantidade de linhas que existem na tabela de exemplos, cada vez utilizando as informações da próxima linha. Ou seja, um mesmo cenário, que possui o mesmo fluxo, mas que precisa utilizar/validar informações diferentes;
• Examples (pt: Exemplos): Segue sempre o esquema de cenário, pois aqui é especificada a tabela com os dados a serem utilizados para a execução do mesmo. Um esquema de cenário será executado a mesma quantidade de vezes de linhas que existirem na tabela de exemplo, cada vez utilizando os dados da próxima linha.

Arquivos de feature

Pode parecer confuso na teoria, mas na prática é mais fácil entender. Agora, vamos pegar nosso caso simples de login e colocar em um arquivo de feature. Ficaria assim:

Note que após a keyword feature, além de dar um nome para a funcionalidade, fazemos um pequeno resumo explicativo do que se refere a funcionalidade em três linhas. Para deixar de uma forma compreensível (lembre-se sempre que a função principal do Gherkin é ser fácil de entender para qualquer tipo de usuário, seja ele técnico ou não) podemos separar essas três linhas da seguinte forma:

• Quem ele é -> Usuário do sistema XPTO;
• O que ele quer fazer -> Completar o login;
• O porquê ele quer fazer -> Acessar funcionalidades restritas ao usuário logado.

Após a descrição da funcionalidade de forma geral, vêm os cenários de negócio. Caso exista um contexto (uma pré condição a ser verdadeira para todos os cenários dessa feature), ele é o primeiro step a vir dentro da feature, mas fora de qualquer cenário específico.

Após posicionar corretamente a funcionalidade, o contexto, e o cenário em si, podemos dizer que temos a feature pronta. A partir daqui, podemos adicionar novos cenários nessa mesma feature, uma vez que esteja dentro do mesmo contexto, por exemplo:

Programação de steps

E voilà, temos nossa feature! Agora, o que resta fazer é programar o que cada step irá executar por trás, como preenchimento de campos, cliques, validações, etc.

Essa programação será feita dentro dos "step definitions", arquivos que terão seu formato diferente dependendo da linguagem que será utilizada.

A seguir, temos um exemplo de step definition escrito em Typescript:

Aqui vemos a forma como o "step" funciona. Pegamos o texto do Gherkin e escrevemos o que deve ser feito quando aquele step for executado. Aqui, será executado o método de preencher os campos de login, com credenciais válidas.

Porém também existe o Esquema do Cenário que pode ser utilizado ao invés do Cenário, como já explicado previamente. Nesse caso, precisamos de uma tabela de informações que vem depois da keyword “Exemplos”.

Aplicando um esquema de cenário no nosso exemplo, teríamos:

Dessa forma, o cenário será executado no mesmo fluxo, porém utilizando informações diferentes em cada execução, evitando repetição de código.

Tags

Os cenários de uma feature também podem ser separados por tags. Tags podem ser incluídas na funcionalidade toda, para dar aquela tag à todos os cenários contidos ali, ou podem ser colocadas separadamente de cenário em cenário ou até mesmo em tabelas de exemplos.

As tags servem para organizar os cenários utilizando os critérios mais diversos possíveis, como por exemplo prioridade do teste, se é negativo ou positivo, etc. Essas tags podem ser especificadas na hora da execução dos testes, para que todos os cenários que possuam a tag mencionada sejam executados. Também é possível negar uma tag, para não executar os cenários que possuem uma tag XPTO.

Para isso, basta adicionar o parâmetro de tags na hora da execução dos testes:

-- tags @tag-desejada or @segunda-tag-desejada and not @tag-nao-desejada

Serão executados todos os cenários que contenham ou a tag @tag-desejada, ou a @segunda-tag-desejada, e nenhum que possua a tag @tag-nao-desejada.

Qualquer tag pode ser colocada nos cenários, de acordo com a necessidade do usuário. Para exemplificar, vamos colocar tags na nossa feature de exemplo:

A tag quando colocada na funcionalidade, será aplicada para todos os cenários existentes naquela feature. Também vale lembrar que um único cenário pode possuir diferentes tags, como por exemplo, @regressão, @smoke, etc.

Conclusão

Finalmente, podemos dizer que a especificação da nossa história utilizando Gherkin está completa!

Incrivelmente fácil, não é? O Gherkin, além de não ser difícil de se aprender, é totalmente legível para qualquer leitor, economiza tempo na reutilização de steps, além de servir como uma documentação da regra de negócio do sistema sendo testado!

Apesar das explicações um pouco longas, após um tempo e com prática não será mais necessário a consulta a nenhum material externo para a construção de novos cenários Gherkin.

Caso queira se aprofundar mais no assunto, consulte a documentação oficial do Gherkin para mais informações.

Perguntas frequentes sobre Gherkin

O que é Gherkin e qual sua principal função?
Gherkin é uma linguagem para descrever especificações de cenários de teste, baseada na regra de negócio. Sua principal função é padronizar a documentação e tornar os testes automatizados fáceis de ler, mesmo para pessoas sem conhecimento técnico.

Qual a relação entre Gherkin e BDD?
O Gherkin é um dos elementos centrais do BDD (Behavior-Driven Development). Ele permite que as especificações de comportamento de um sistema sejam escritas de forma clara e compreensível, servindo de ponte entre as áreas de negócio e a equipe de desenvolvimento.

Quais são as palavras-chave essenciais (keywords) do Gherkin?
As keywords essenciais são:
Given (Dado): Para pré-condições.
When (Quando): Para a ação que será executada.
Then (Então): Para o resultado esperado.
And (E) / But (Mas): Para complementar as interações nos passos anteriores.

O que são arquivos .feature no Gherkin?
Arquivos com a extensão .feature são os que contêm os cenários Gherkin. Eles usam keywords como Feature, Background e Scenario para organizar os testes de forma clara, descrevendo as funcionalidades e os comportamentos esperados do sistema.

Como as tags são usadas no Gherkin?
As tags são usadas para organizar cenários de teste com base em critérios como prioridade, tipo de teste (ex: regressão, smoke), ou qualquer outra categorização necessária. Elas permitem que você selecione quais cenários executar durante o processo de automação.

Artigo revisado por Grace Libânio
Atualizado em: 19/08/2025

Tem dúvidas sobre o conteúdo?

Fale com um especialista da Sofist