Escrevendo cenários em Gherkin - Blog 4ALL Tests
Carregando:

Escrevendo cenários em Gherkin

Escrevendo cenários em Gherkin

Escrevendo cenários em Gherkin

O Gherkin serve como documentação do seu projeto, bem como para testes automatizados.



Escrevendo features

Behat é uma ferramenta para testar o o comportamento de sua aplicação, utilizando uma linguagem especial chamada Gherkin. Gherkin é uma Business Readable, Domain Specific Language criada especificamente para a descrição de comportamentos. Isto lhe dá a habilidade de remover detalhes lógicos dos testes de comportamento.


sintaxe gherkin

Bem como YAML e Python, Gherkin é uma linguagem orientada a espaços, ela usa indentação para definir a estrutura. Os fins de linha encerram as declarações (denominados etapas) e espaços ou tabs também podem ser usados para indentação (nós sugerimos a você usar espaços para melhor portabilidade). Finalmente, a maioria das linhas em Gherkin iniciam com uma palavra chave especial:

# language: pt 

Funcionalidade: Algum texto descritivo conciso do que é desejado
A fim de realizar um valor de negócio Como ator explicito do sistema
Eu quero ganhar algum resultado benéfico que promova a meta
Texto adicional...

Cenário: Uma determinada situação de negócios
Dado uma pré condição
E uma outra pré condição
Quando uma ação é feita pelo ator
E uma outra ação
E outra ação diferente
Então um resultado testável é alcançado
E outra coisa que possamos verificar também acontece


Cenário: Uma situação diferente
...

O analisador divide a entrada em funcionalidades, cenários e etapas. Vamos analisar o exemplo:

.

# Funcionalidade: Algum texto descritivo conciso do que é desejadoinicia a feature e lhe dá um título. Aprenda mais sobre Funcionalidades na seção “`Features`_

”..# As próximas três linhas (A fim de ..., Como um ..., Eu quero...)dão um contexto para as pessoas que leem a sua funcionalidade e descreve o valor do negócio derivada da inclusão da funcionalidade em seu software. Estas linhas não são analisadas pelo Behat e não requerem uma estrutura..

# Cenário: Uma determinada situação de negócios inicia o cenário econtêm uma descrição do cenário. Aprenda mais sobre cenários na seção “`Scenarios`_“.

# As próximas 7 linhas são etapas do cenário, cada uma das quais é comparadacom um padrão definido em outro lugar. Aprenda mais sobre etapas na seção “`Steps`_

.

# Cenário: Uma situação diferente inicia o próximo cenário e assim por diante.

Quando você está executando a funcionalidade, a porção da direita de cada etapa (após as palavras chaves como Dado, E, Quando, etc) coincide com um padrão, que executa uma função callback do PHP. Você pode ler mais sobre etapas de coincidências e execução em Definindo Ações Reutilizáveis.

Funcionalidades

Todos arquivos *.feature convencionalmente consistem em uma funcionalidade única. Linhas iniciando com a palavra chave Funcionalidade: seguido de três linhas identadas iniciam uma funcionalidade. Usualmente uma Funcionalidade contém uma lista de Cenários. Você pode escrever qualquer coisa que você precise até o primeiro cenário, que inicia com Cenário: (ou o seu equivalente) em uma nova linha. Você pode usar tags para agrupar Funcionalidades e Cenários, independente da estrutura do seu arquivo e diretório.

Todos cenários consistem em uma lista de etapas, que devem iniciar com uma das palavras chaves Dado, Quando, Então, Mas ou E. O Behat trata eles do mesmo modo, mas você não deve fazer isto. Aqui temos um exemplo:

# language: pt 
Funcionalidade: Servir café
A fim de ganhar dinheiro
Os clientes devem ser capazes de comprar café a todo momento
Cenário: Compra último café
Dado que tenha 1 café sobrando na máquina
E eu tenha depositado 1 real
Quando eu pressionar o botão de café
Então eu deveria ser servido de um café

Além do básico Cenário, uma funcionalidade pode conter Esquema do Cenário e Contexto.

Cenário

Cenários são uma das principais estruturas do Gherkin. Todo cenário deve iniciar com a palavra chave Cenário: , opcionalmente seguido de um título de cenário. Cada funcionalidade pode ter um ou mais cenários e todo cenário consiste em uma ou mais `etapa`_.

Os cenários seguintes tem cada um 3 etapas:

Cenário: Wilson posta em seu blog   
Dado que eu estou logado como Wilson
Quando eu tento postar "A terapia cara"
Então eu devo ver "Seu artigo foi publicado."

Cenário: Wilson falha ao postar algo no blog de outra pessoa
Dado que eu estou logado como Wilson
Quando eu tento postar "Greg esbraveja contra impostos"
Então eu devo ver "Hey! Este não é o seu blog!"

Cenário: Greg posta em blog cliente
Dado que eu estou logado como Greg
Quando eu tento postar "Terapia Cara"
Então eu devo ver "Seu artigo foi publicado."

Esquema do cenário

Copiar e colar cenários para usar diferentes valores pode ser muito tedioso e repetitivo:

Cenário: Comer 5 em cada 12   
Dado que tenho 12 pepinos
Quando eu comer 5 pepinos
Então eu devo ter 7 pepinos

Cenário: Comer 5 em cada 20
Dado que tenho 20 pepinos
Quando eu comer 5 pepinos
Então eu devo ter 15 pepinos

Os Esquemas do Cenários nos permitem formular estes exemplos com maior precisão através da utilização de um modelo com espaços reservados:

Esquema do Cenário: Comendo   
Dado que tenho <antes> pepinos
Quando eu comer <come> pepinos
Então eu devo ter <depois> pepinos
Exemplos:
| antes | come | depois |
| 12 | 5 | 7 |
| 20 | 5 | 15 |

As etapas do Esquema do Cenário fornecem um modelo que nunca é executado diretamente. Um Esquema do Cenário é executado uma vez para cada linha na seção de exemplos abaixo dela (exceto para a primeira linha que é o cabeçalho).

O Esquema do Cenário utiliza espaços reservados, que estão contidos < > nas etapas de saída do Cenário. Por exemplo:

Dado <Eu sou um espaço reservado e estou ok> 

Pense em um espaço reservado como uma variável. Isto pode ser substituído por um valor real das linhas da tabela de Exemplos:, onde o texto entre os < > de espaço reservado corresponde ao cabeçalho da coluna da tabela. O valor substituído pelo espaço reservado muda a cada execução subsequente do Esquema do Cenário, até que o fim da tabela de Exemplos seja alcançado.

Você também pode usar os espaços reservados em Argumentos Multilineos.

Sua etapa de definições nunca terá que coincidir com o próprio texto do espaço reservado, mas sim os valores terão que substituir o espaço reservado.

Então quando executamos a primeira linha do nosso exemplo:

Esquema do Cenário: Comer   
Dado que temos <antes> pepinos
Quando eu comer <come> pepino
Então teremos <depois> pepinos
Exemplos:
| antes | come | depois |
| 12 | 5 | 7 |

O cenário que realmente é executado é:

Cenário: Comer   # <antes> é substituído por 12:   
Dado que temos 12 pepinos # <come> é substituído por 5:
Quando eu comer 5 pepino # <depois> é substituído por 7:
Então teremos 7 pepinos

Contexto

Contexto permite a você adicionar algum contexto a todos os cenários em um único recurso. Um Contexto é como um Cenário sem título, que contém uma série de etapas. A diferença ocorre quando ele é executado: o contexto será executado antes de cada um de seus cenários, mas depois dos seus hooks BeforeScenario (Hooking no Processo de Teste).

# language: pt 
Funcionalidade: Suporte a múltiplos sites
Contexto: Dado um administrador global chamado "Greg"
E um blog chamado "Greg esbraveja contra impostos"
E um cliente chamado "Wilson"
E um blog chamado "Terapia Cara" de propriedade de "Wilson"
Cenário: Wilson posta em seu próprio blog
Dado que eu esteja logado como Wilson
Quando eu tentar postar em "Terapia Cara"
Então eu devo ver "Seu artigo foi publicado."
Cenário: Greg posta no blog de um cliente
Dado que eu esteja logado como Greg
Quando eu tentar postar em "Terapia Cara"
Então eu devo ver "Seu artigo foi publicado"

Etapas

Funcionalidades consistem em etapas, também conhecidas como Dado, Quando e Então.

O Behat não faz distinção técnica entre estes três tipos de etapas, contudo, nós recomendamos fortemente que você faça! Estas palavras foram cuidadosamente selecionadas para o seu propósito e você deve saber que o objetivo é entrar na mentalidade BDD.

Robert C. Martin escreveu um ótimo post sobre o conceito de BDD Dado-Quando-Então onde ele pensa neles como uma máquina de estados finitos.

dado

O propósito da etapa Dado é colocar o sistema em um estado conhecido antes do usuário (ou sistema externo) iniciar a interação com o sistema (na etapa Quando). Evite falar sobre a interação em Dado. Se você trabalhou com casos de uso, Dado é a sua pré condição.

Exemplos de Dado

Dois bons exemplos do uso de Dado são:

  • Para criar registros (instâncias de modelo) ou de configuração do

banco de dados:

Dado que não tenha usuários no site Dado que o banco de dados esteja limpo 
  • Autenticar um usuário (uma exceção a recomendação de não-interação

Coisas que “aconteceram antes” estão ok):

Dado que eu esteja logado como "Everzet" 

Tudo bem chamar a camada de “dentro” da camada de interface do usuário aqui (no Symfony: falar com os modelos).

Usando Dado como massa de dados:

Se você usa ORMs como Doctrine ou Propel, nós recomendamos a utilização de uma etapa Dado com o argumento `tabela`_ para configurar registros em vez de objetos. Neste caminho você pode ler todos os cenários em um único lugar e fazer sentido fora dele sem ter que saltar entre arquivos:

Dado estes usuários: 
| username | password | email |
| everzet | 123456 | everzet@knplabs.com |
| fabpot | 22@222 | fabpot@symfony.com |

quando

O propósito da etapa Quando é descrever a ação chave que o usuário executa (ou, usando a metáfora de Robert C. Martin, a transição de estado).

Exemplos de Quando

Dois bons exemplos do uso de Quando são:

  • Interagir com uma página web (a biblioteca Mink lhe dá muitas etapas

Quando web amigáveis):

Quando eu estiver em "/alguma/pagina" 
Quando eu preencho o campo "username" com "everzet"
Quando eu preencho o campo "password" com "123456"
Quando eu clico em "login"
  • Interagir com alguma biblioteca CLI (chama comandos e grava saída):

    Quando eu chamo "ls -la" 

então

O propósito da etapa Então é observar saídas. As observações devem estar relacionadas com o valor/benefício de negócios na sua descrição da funcionalidade. As observações devem inspecionar a saída do sistema (um relatório, interface de usuário, mensagem, saída de comando) e não alguma coisa profundamente enterrado dentro dela (que não tem valor de negócios e ao invés disso faz parte da implementação).

Exemplos de Então

Dois bons exemplos do uso de Então são:

  • Verificar algo relacionado ao Dado + Quando está (ou não) na saída:

    Quando eu chamo "echo hello" 
    Então a saída deve ser "hello"
  • Checar se algum sistema externo recebeu a mensagem esperada:

    Quando eu enviar um email com:   """   ...   """ 
    Então o cliente deve receber um email com: """ ... """

Embora possa ser tentador implementar etapas Então para apenas olhar no banco de dados - resista à tentação. Você deve verificar somente saídas que podem ser observadas pelo usuário (ou sistema externo). Se a base de dados somente é visível internamente por sua aplicação, mas é finalmente exposta pela saída do seu sistema em um navegador web, na linha de comando ou uma mensagem de email.

e, mas

Se você tem várias etapas Dado, Quando ou Então você pode escrever:

Cenário: Múltiplos Dado   
Dado uma coisa
Dado outra coisa
Dado mais outra coisa
Quando eu abrir meus olhos
Então eu verei qualquer coisa
Então eu não verei qualquer outra coisa

Ou você pode usar etapas E ou Mas, permitindo uma leitura mais fluente do seu Cenário:

Cenário: Múltiplos Dado   
Dado uma coisa
E outra coisa
E mais outra coisa
Quando eu abrir meus olhos
Então eu verei qualquer coisa
Mas eu não verei qualquer outra coisa

O Behat interpreta as etapas iniciando com E ou Mas exatamente como as outras etapas, não faz distinção entre elas - Mas você deve!

argumentos multilineos

A linha única etapas permite ao Behat extrair pequenas strings de suas etapas e recebê-los em suas definições de etapas. No entanto, há momentos em que você quer passar uma estrutura de dados mais rica a uma definição de etapa.

Para isto foram projetados os Argumentos Multilineos. Eles são escritos nas linhas que seguem imediatamente uma etapa e são passadas para o método definição de etapa como um último argumento.

Etapas de Argumentos Multilineos vem em dois modos: tabelas ou pystrings.

tabelas

As tabelas são etapas de argumentos úteis para a especificação de um grande conjunto de dados - normalmente como entrada para uma saída de Dado ou como espera de um Então.

Cenário:   Dado que as seguintes pessoas existem:     
| nome | email | fone |
| Aslak | aslak@email.com | 123 |
| Joe | joe@email.com | 234 |
| Bryan | bryan@email.org | 456 |

Não confunda tabelas com `Esquemas do cenário`_ - sintaticamente eles são idênticos, mas eles tem propósitos diferentes. Esquemas declaram diferentes valores múltiplos ao mesmo cenário, enquanto tabelas são usadas para esperar um conjunto de dados.



Este artigo foi tirado da ferramenta Behat e seve tanto para sua escrita em qualquer framework, quanto para o próprio Behat.
Compartilhe :
   
Tags :
Testes   Análise   Conceitos   Estudar  

João Júnior

QA, Gestor de Projetos, inovador, criador do 4ALL Tests, COPA TI e organizador de vários eventos na área de Tecnologia.