Automação Web — Cypress e Cucumber — Parte 3: Cucumber e Gherkin

Continuando a documentação de meu aprendizado no curso ‘Automação Web — Cypress e Cucumber’, neste artigo veremos sobre ‘Cucumber’, ‘Gherkin’ e BDD, ‘classe Feature’ e ‘classe Steps’.

Fonte: Gemini.

Cucumber

O Cucumber no Cypress transforma a especificação do seu produto (o que ele deve fazer) diretamente em testes automatizados, garantindo que a documentação do comportamento da aplicação esteja sempre atualizada com o código de teste.

BDD e Classe Feature

agora, vamos criar a classe ‘feature’, onde desenvolveremos o Gherkin, a qual é a linguagem que o Cucumber entende.

No diretório ‘features’, vamos criar o arquivo ‘login.feature’, iniciando com a palavra-chave ‘Feature’(Funcionalidade) e o título (Login):

Palavra-chave: Feature:

A palavra-chave Feature: (Funcionalidade) é o elemento de nível mais alto em qualquer arquivo Gherkin (.feature).

O que é? É a primeira palavra-chave em cada arquivo ‘.feature’. Ela define o escopo do arquivo.

O que faz?

• Agrupamento: Serve para agrupar cenários (Scenarios) relacionados sob um único objetivo de negócio ou área funcional do sistema.
• Documentação: É a principal forma de documentar a funcionalidade que está sendo testada.
• Contexto: O texto que segue o Feature: (incluindo as linhas opcionais logo abaixo) é a descrição da funcionalidade. Isso oferece o contexto de negócio de alto nível para os testes que estão por vir. É a resposta à pergunta: “O que estamos tentando fazer/testar aqui?”

Agora, após a descrição que estará na linha 2. Na 4 teremos nosso primeiro ‘Scenario’ com o título ‘Login com sucesso’

Vamos ao 1º cenário com Gherkin:

Essa é uma forma simples de escrever em Gherking, que pode ser utilizada em nossos steps.

Temos apenas o cenário Login com sucesso. Mas, se quiséssemos ter, por exemplo, além deste, cenários alternativos, poderíamos usar ‘examples’, onde teríamos uma massa de teste com mais de uma credencial e situação.

Podemos manipular examples para testar n casos de teste.

O esquema de cenários funciona com variáveis, usadas na própria feature, que serão lidas pena classe de steps, fazendo a variação dos nossos cenários. Passa esse nosso cenário que servirá como um template, usaremos a palavra-chave ‘Scenario Outline’ com o título ‘Login’:

Exemplo:

Veja! Temos um cenário com login com sucesso, onde poderíamos ter o cenário anterior e outras variações. Pois, podemos usar diferentes massas de teste com outras credenciais, cuja mensagem também poderá ser personalizada conforme a função da credencial.

Então, através de nossa palavra-chave ‘examplos’ teremos a massa de teste:

• Login com sucesso;
• Senha incorreta.

Classe Steps

É uma boa prática, quando formos usar Cucumber, não criarmos steps duplicado, como no exemplo:

Se começarmos a escrever outros steps iguais, o Cucumber poderá se perder.

Entendido isso, criaremos o arquivo ‘login_steps.js’, onde futuramente criaremos a classe ‘step’:

Agora, vamos voltar no arquivo ‘login.feature’, selecionar os steps do caso de teste ‘Login com sucesso’, clicar com o lado direito do mouse e selecionar a opção “Generate Step Definition: Copy To Clipboard”:

Depois, vamos colar clicando no scroll do mouse no arquivo ‘login_steps.js’:

O quê aconteceu foi a conversão automática dos passos (Steps) escritos em linguagem natural (Gherkin, no arquivo .feature) para o código executável (JavaScript, no arquivo login_steps.js).

• A extensão do VS Code ( Cucumber (Gherkin) Support) identificou os Steps no arquivo login.feature.
• Ao usar a função “Copy To Clipboard” ou equivalente, ela gerou os Step Definitions (Definições dos Passos) correspondentes.
• Essas Step Definitions são a “cola” que liga cada linha do cenário Gherkin (ex: When eu inserir meu login e senha) ao código JavaScript que realmente executará a ação (ex: digitar login, senha e clicar no botão).

Explicação do Código Gerado (Step Definitions)

O código no login_steps.js é composto por uma série de funções, onde cada função mapeia um Step específico do seu arquivo .feature.

Vejamos a estrutura geral de um Step Definition:

Palavra-Chave Gherkin (Given, When, Then)

• Função: Elas definem o tipo do passo.
• Given: Define o contexto inicial ou pré-condição.
• When: Define a ação que o usuário realiza.
• Then: Define o resultado esperado ou a verificação.

2. Expressão Regular (Regex)

• O que é: O texto entre as barras inclinadas (/^…$/) é uma Expressão Regular (Regex).
• Função: Ela serve para encontrar e casar o texto exato do Step no arquivo .feature.
• ^: Indica o início da string.
• $: Indica o fim da string.
• /…/: Delimitadores da expressão regular.
• Exemplo: O Regex /^que eu queira acessar o sistema$/ garantirá que o código só seja executado quando a linha no Gherkin for exatamente Given que eu queira acessar o sistema. Se a linha fosse, por exemplo, Given que eu agora queira acessar o sistema, o Cypress/Cucumber não encontraria a função correspondente e falharia.

3. Função de Retorno (() => { … })

• O que é: É a função callback de JavaScript (uma arrow function, neste caso) que será executada quando o Step Gherkin for correspondido.
• Função: Este é o corpo do teste. É aqui que escreveremos o código Cypress real para interagir com a aplicação.
• No código gerado: return true; é apenas um placeholder (marcador de lugar) padrão. Ele apenas indica que o passo “passou” com sucesso (retornou true sem erros), mas não realiza nenhuma ação real de teste.

Agora, vamos fazer o mesmo para o ‘Scenario Outline’:

Agora, como dito lá no começo: “Como uma boa prática, não podemos ter steps com a mesma descrição”. Então, vamos remover o 2º, o qual é o 1º step do Scenario Outline:

Também vamos excluir o 2º step ‘clicar no botão Entrar’:

Agora, vamos entender melhor a Expressão Regular (Regex) gerada para o Scenario Outline. Esta é a parte crucial que permite a parametrização dos testes, ou seja, usar diferentes “massas de teste” (dados) da tabela Examples.

O segredo está no uso de grupos de captura dentro do Regex.

Explicando o Step Definition Parametrizado

Vamos usar como exemplo a Step Definition que lida com o login, pois ela ilustra a captura de duas variáveis:

O Step correspondente no arquivo .feature é: When eu inserir meu login “<login>” e senha “<senha>”:

1. A Estrutura Básica

Como antes, temos a função When, delimitadores /^…$/ para início e fim, e o texto estático:

• Início e Fim: /^ e $/ garantem que a expressão casa com a linha completa.
• Texto Estático: eu inserir meu login “ e e senha “ e “ são o texto fixo que precisa aparecer na linha do Gherkin.

*2. O Segredo: O Grupo de Captura ([^”])**

A porção que você realmente precisa entender é o trecho que substitui as variáveis <login> e <senha>:

Este é um Grupo de Captura e é a chave para o trabalho com Scenario Outline. Vamos desmembrá-lo:

Em Linguagem Simples:

O Regex está dizendo: “Procure o texto exato eu inserir meu login “. Depois disso, capture tudo o que vier até encontrar a próxima aspa dupla (“), e passe o que foi capturado como um argumento para a função.”

3. Mapeamento dos Argumentos

Graças ao grupo de captura *‘([“])’, o valor extraído é passado em ordem para a função de *callback***:

Veja que nos steps 1 &2, 3 & 4 temos os mesmos objetivos, mas são steps diferentes. Portanto, eles ficam:

Enquanto no step 1 vamos passar o parâmetro diretamente no método que vamos herdar do arquivo ‘login_pages.js’:

Ja o 2º step:

E como funciona esses steps?

Quado tivermos steps escrito da mesma maneira, mesmo que em features diferentes — desde que estejam implementadas em um mesmo lugar -, podemos reaproveitar os mesmos comportamentos.

Mais pra frente veremos como implementar os métodos, a partir da ‘login_pages.js’:

Em nossos steps:

Implementando a classe de step

Vamos implementá-la, fazendo uma ASSERTION, que é uma verificação programática que inseriremos no código de teste para validar se o estado atual da aplicação corresponde ao estado esperado. Ela é o componente chave que transforma um passo em um teste.

Vamos começar fazendo o import da classe ‘loginPage’:

Depois do import da classe para dentro do step, vamos instanciar o objeto login:

Mas, para acessarmos temos que exportar a classe ‘pageLogin’:, no arquivo ‘login_pages.js’:

Agora, sim, em nossos steps podemos acessar os métodos:

1. acessarHomePage;
2. preencherDadosNaTela;
3. clicarNoBotaoEntrar.

Para começar, no step ‘Given’, onde temos ‘return true’:

vamos substituir pela invocação do método ‘acessarHomePage()’ no objeto ‘pageLogin’, que por sua vez é uma instância da classe ‘loginPage’:

Agora, no step When:

Invocaremos o método ‘preencherDadosNaTela’ no objeto ‘pageLogin’:

Por fim, o método ‘clicarNoBotaoEntrar()’:

Não implementamos o step ‘Then’ para validar que o user acessou com sucesso, mas podemos fazê-lo mais para frente.

Recapitulação do que fora feito até então

No arquivo ‘login.js’ mapeamos os elementos da página (campo de login, senha e botão Enter) na classe ‘loginElements’:

Depois, exportamos a classe, para podermos criarmos ações em cima dos elementos no arquivo ‘login_pages’:

1. Já no arquivo ‘login_pages.js’, importamos a classe ‘loginElements’.
2. Instanciamos o objeto ‘el’ baseado na classe ‘loginElements’.
3. Criamos a classe ‘loginPage’.
4. Acessando a página de login
5. Usando os comando ‘cy.get’ para acessar os campos de login e senha, invocando os métodos da classe pai ’inputEmail’ e ‘inputPass’ no objeto ‘el’. Depois inserindo login e senha com os comando ‘type’.
6. Encontrando o botão Enter e efetuando o click.
7. Exportando a classe ‘loginPage’ para termos acesso as ações em cima dos elementos na

Por fim, fomos aos steps, chamando cada um desses testes para ser executado:

1. Importa a classe ‘loginPage’ para termos acessos aos funções interagindo com os elementos através métodos “.acessarHomePage()”, “.preencherDadosNaTela()” e “.clicarNoBotaoEntrar()”.
2. A partir da classe ‘loginPage’, instanciamos o objeto ‘pageLogin’.
3. A partir do objeto ‘loginPage’, invocamos o método “.acessarHomePage()”, que só será retornado se a equivalência exata de ‘que eu queira acessar o sistema’ for encontrada pelo Regex. Da mesma forma será para os dois steps ‘when’, nos pontos 4 e 5.

Até o próximo encontro!