Gherkin e Cucumber — Mapeando os testes automatizados

Já pensou em definir e mapear suas automações de teste de um jeito bem simples e intuitivo para todos os stakeholders entenderem.

Neste artigo iremos identificar os cenários de teste e definir o escopo de automação levando em consideração o negócio do cenário de exemplo.

E por favor, lembre-se que

Automação de testes não é bala de Prata.

Iremos abordar também uma biblioteca muito interessante chamada: cucumber, um método de desenvolvimento chamado BDD e também o Gherkin.

Cucumber: é uma ferramenta que suporta Behavior Driven Development (BDD), que consiste em descrever o comportamento de um sistema.

Gherkin: Sua função é padronizar a forma de descrever especificações de cenários, baseado na regra de negócio.

BDD: É uma técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando no comportamento do software.

No processo de desenvolvimento de um sistema, temos vários eventos para definir um escopo ou produto. Dentre eles, podemos citar: o Refinamento funcional, o Refinamento técnico da solução e o Refinamento dos cenários de teste.
O Refinamento dos cenários de testes é uma prática pouco utilizada, mas já tive o prazer de participar, e acabou sendo muito produtivo identificamos cenários e comportamento de negócio que não tinhamos identificado antes e a partir disso, virou rotina alinhar os cenários de teste.

Um pouco sobre a experiência

Refinamento dos cenários: Neste momento em conjunto com seu time, ou somente o PO, vocês projetam os cenários de testes a partir de cada funcionalidade, levando tudo que foi discutido no refinamento funcional, ou qualquer outro evento que de origem as especificações do sistema como ponto importante.

Neste evento podemos contar com o BDD, com ele conseguimos definir de maneira simples os critérios de aceite das Funcionalidade.

Exemplo:

// historia do usuario
Eu como "proprietario" de uma casa inteligente
No processo de "fazer café".
E para agilizar o meu tempo fazendo outras atividades
Quero pode receber notificacao sobre o "status do cafe"
Para eu poder tomar um "cafe quentinho"



//Funcionalidade 1: Enviar Notificação
Funcionalidade: Notificacao do café no celular

Cenarios:

Cenário - Criar notificacao 201
Dado que o usuario ligou a maquina de cafe
Quando via metodo POST enViar informacao de iniciado para o path "/iniciarServicoCafe"
Então deve retornar o status 201
E um id de transicao

Cenário - Verificar processo de fala erro maquina 400
Dado que o usuario ligou a maquina de cafe
Quando via metodo POST enViar informacao de iniciado para o path "/iniciarServicoCafe"
Então deve retornar o status 400
E maquina nao ligou corretamente

Cenário - Servico teve erro ao se comunicar 500
Dado que o usuario ligou a maquina de cafe
Quando via metodo POST enViar informacao de iniciado para o path "/iniciarServicoCafe"
Então deve retornar o status 500
E erro no servico, tire e coloque na tomada.


//Funcionalidade 2: Mecanismo de monitroamento do status da maquina de cafe

Funcionalidade: Monitorar status  maquina de cafe

Cenários:

Cenário - Retorno do status do cage
Dado que foi acionado a maquina de cafe
E o procedo de cafe foi iniciado
Quando via metodo GET precisamos retornar o status do processo no  path "/retornoStatusCafe" 
Entao o status deve retornar 200
E STATUS deve ser os valores entre: "Pendente", "Fazendo", "Pronto", "Erro"

Cenário - Retorno de erro na funcionalidade
Dado que foi acionado a maquina de cafe
E o procedo de cafe foi iniciado
Quando via metodo GET precisamos retornar o status do processo no  path "/retornoStatusCafe" 
E deu algum erro no processo de cafe
Entao o status deve retornar 400
E retornar descrisao do erro

Cenário - Erro no serviço
Dado que foi acionado a maquina de cafe
E o procedo de cafe foi iniciado
Quando via metodo GET precisamos retornar o status do processo no  path "/retornoStatusCafe" 
E aconteceu algum erro no servidor
Entao o status deve retornar 500
E retornar descrição do erro



// São cenários ilustrativos!

Agora temos nossas histórias e nos cenários de testes, podemos dizer também que temos nossos critérios de aceite.

Definir cenários automatizados

Dado que todos os cenarios levantados acima são passiveis de automação, podemos utilizar o recurso do cucumber chamado tag.
Ele ajuda a mapear todos os seus testes a partir de tags, e no exemplo abaixo iremos definir 3 níveis de tagueamento.

@escopo_sistema: Teste para executar todas as funcionalidades

@feature: Definir o escopo para executar somente os testes de uma funcionalidade específica.

@tag_case_test: Definir o testes que será executado por caso de teste.

Funcionalidade 1

#Nivel 1
@sistema

#Nivel 2
@feature1
Funcionalidade: Notificacao do café no celular

#Nivel 3
@criarNotificacao
ct - Criar notificacao 201

Dado que o usuario ligou a maquina de cafe
Quando via metodo POST enviar informação de iniciado para o path "/iniciarServicoCafe"
Então deve retornar o status 201
E um id de transicao

@verificarErroNegocioNoti
ct - Verificar processo de fala erro maquina 400

Dado que o usuario ligou a maquina de cafe
Quando via metodo POST enViar informacao de iniciado para o path "/iniciarServicoCafe"
Então deve retornar o status 400
E maquina nao ligou corretamente 

@verificarErroServidorNoti
ct - Servico teve erro ao se comunicar 500

Dado que o usuario ligou a maquina de cafe
Quando via metodo POST enViar informação de iniciado para o path "/iniciarServicoCafe"
Então deve retornar o status 500
E erro no servico, tire e coloque na tomada.

Funcionalidade 2

#Nivel 1
@sistema

#Nivel 2
@feature2 
Funcionalidade: Monitorar status  maquina de cafe

#Nivel 3
@sucesoCafeMoni
ct - Retorno do status do café

Dado que foi acionado a maquina de café
E o procedo de cafe foi iniciado
Quando via metodo GET precisamos retornar o status do processo 
no path "/retornoStatusCafe" 
Entao o status deve retornar 200
E STATUS deve ser os valores entre: "Pendente", "Fazendo", "Pronto", "Erro"

@erroNegocioMoni
ct - Retorno de erro na funcionalidade

Dado que foi acionado a maquina de cafe
E o procedo de cafe foi iniciado
Quando via metodo GET precisamos retornar o status do processo 
no path "/retornoStatusCafe" 
E deu algum erro no processo de cafe
Entao o status deve retornar 400
E retornar descrisao do erro

@erroServidorMoni
ct - Erro no serviço

Dado que foi acionado a maquina de cafe
E o procedo de cafe foi iniciado
Quando via metodo GET precisamos retornar o status do processo no  
path "/retornoStatusCafe" 
E aconteceu algum erro no servidor
Entao o status deve retornar 500
E retornar descrição do erro

A partir desse momento definimos como iremos executar todos os cenários de testes do nosso sistema “@sistema”.
Possível execução após liberação de uma versão do sistema (CI/CD)

Identificamos também as funcionalidades, fazendo com que seja mais prático o usuário executar os testes a partir de uma atualização especifica, ou seja, alguma funcionalidade “@feature1” “@feature2”.
Possível execução de liberação de Release, ou Hotfix.

E por fim identificamos os cenários pontualmente, fazendo com que o usuário tenha a possibilidade de executar testes pontuais Testes exploratório.
Possível execução após erro de alguns casos de testes específicos.

Execução do sistema por tag.

Para fazer a execução por tag existem várias maneiras e você pode encontrar na documentação do Cucumber Cucumber tags.

Iremos abordar a execução pelo Maven

// Escopo Sistema
mvn test -Dcucumber.filter.tags="@sistema"

// Escopo funcionalidade
mvn test -Dcucumber.filter.tags="@feature1"

//escopo Cenário de teste
mvn test -Dcucumber.filter.tags="@sucesoCafeMoni"

Conclusão

Com isso, conseguimos identificar as funcionalidades do sistema em conjunto com o time. Identificamos os cenários de testes, mapeamos os testes automatizados por escopo e por fim identificamos em qual cenário executar cada escopo, seja ele uma esteira de desenvolvimento, liberação, correção do hotfix ou até mesmo executar testes exploratórios.