Desenvolvimento baseado em comportamento - Gherkin
Gherkin é uma linguagem usada para escrever Features, Scenarios, and Steps. O objetivo do Gherkin é nos ajudar a escrever requisitos concretos.
Para entender o que queremos dizer com requisitos concretos, considere o seguinte exemplo -
Os clientes devem ser impedidos de inserir dados inválidos de cartão de crédito.
Se um cliente inserir um número de cartão de crédito que não tenha exatamente 16 dígitos, ao tentar enviar o formulário, ele deverá ser exibido novamente com uma mensagem de erro avisando sobre o número correto de dígitos.
Este último não tem ambigüidades e evita erros e é muito mais testável.
O Gherkin foi projetado para criar requisitos mais concretos. No Gherkin, o exemplo acima se parece com -
Feature
Feedback ao inserir detalhes de cartão de crédito inválido Feature Definition
Em testes de usuário, vimos muitas pessoas que cometem erros. Documentação
Background True for all Scenarios Below
Given Eu escolhi um item para comprar,
And Estou prestes a inserir o número do meu cartão de crédito
Scenario - Número do cartão de crédito muito curtoScenario Definition
When Eu insiro um número de cartão com menos de 16 dígitos
And todos os outros detalhes estão corretos
And Eu envio o formulárioSteps
Then o formulário deve ser mostrado novamente
And Devo ver uma mensagem informando sobre o número correto de dígitos
Formato e sintaxe do Gherkin
Os arquivos Gherkin são arquivos de texto simples e têm a extensão .feature. Cada linha que não estiver em branco deve começar com uma palavra-chave Gherkin, seguida de qualquer texto que você desejar. As palavras-chave são -
Feature
Scenario
Dado, quando, então e, mas (etapas)
Background
Esboço do cenário
Examples
"" "(Strings Doc)
| (Tabelas de dados)
@ (Tag)
# (Comentários)
*
Característica
o FeatureA palavra-chave é usada para descrever um recurso de software e para agrupar os cenários relacionados. Um recurso tem três elementos básicos -
A palavra-chave - recurso.
O nome do recurso, fornecido na mesma linha da palavra-chave do recurso.
Uma descrição opcional (mas altamente recomendada) que pode abranger várias linhas, ou seja, todo o texto entre a linha que contém a palavra-chave Característica e uma linha que começa com Cenário, Plano de Fundo ou Contorno do Cenário.
Além de um nome e uma descrição, os recursos contêm uma lista de cenários ou contornos de cenários e um plano de fundo opcional.
É convencional nomear um .featurearquivo pegando o nome do elemento, convertendo-o em minúsculas e substituindo os espaços por sublinhados. Por exemplo,
feedback_when_entering_invalid_credit_card_details.featurePara identificar recursos em seu sistema, você pode usar o que é conhecido como “modelo de injeção de recursos”.
Descrições
Algumas partes dos documentos Gherkin não precisam começar com uma palavra-chave.
Nas linhas que seguem um recurso, cenário, esboço de cenário ou exemplos, você pode escrever o que quiser, desde que nenhuma linha comece com uma palavra-chave. Esta é a maneira de incluir Descrições.
Cenário
Para expressar o comportamento do seu sistema, você anexa um ou mais cenários a cada recurso. É comum ver 5 a 20 cenários por recurso para especificar completamente todos os comportamentos em torno desse recurso.
Os cenários seguem o seguinte padrão -
Descreva um contexto inicial
Descreva um evento
Descreva um resultado esperado
Começamos com um contexto, descrevemos uma ação e verificamos o resultado. Isso é feito com etapas. Gherkin fornece três palavras-chave para descrever cada um dos contextos, ações e resultados como etapas.
Given - Estabelecer contexto
When - Executar ação
Then - Verifique o resultado
Essas palavras-chave fornecem legibilidade do cenário.
Example
Scenario - Retire dinheiro da conta.
Given Tenho $ 100 em minha conta.
When Eu solicito $ 20.
Then $ 20 devem ser dispensados.
Se houver vários Given ou When etapas abaixo umas das outras, você pode usar And ou But. Eles permitem que você especifique cenários em detalhes.
Example
Scenario - Tentativa de retirada com cartão roubado.
Given Tenho $ 100 em minha conta.
But meu cartão é inválido.
When Eu solicito $ 50.
Then meu cartão não deve ser devolvido.
And Eu deveria ser informado para entrar em contato com o banco.
Ao criar cenários, lembre-se de que 'cada cenário deve fazer sentido e pode ser executado independentemente de qualquer outro cenário' '. Isso significa -
Você não pode ter a condição de sucesso de um cenário dependendo do fato de que algum outro cenário foi executado antes dele.
Cada cenário cria seu contexto particular, executa uma coisa e testa o resultado.
Esses cenários fornecem os seguintes benefícios -
Os testes serão mais simples e fáceis de entender.
Você pode executar apenas um subconjunto de seus cenários e não precisa se preocupar com a quebra de seu conjunto de teste.
Dependendo do seu sistema, você pode executar os testes em paralelo, reduzindo o tempo necessário para executar todos os seus testes.
Esboço do cenário
Se você tiver que escrever cenários com várias entradas ou saídas, pode acabar criando vários cenários que diferem apenas por seus valores. A solução é usar o esboço do cenário. Para escrever um esboço do cenário,
As variáveis nas etapas do esboço do cenário são marcadas com <e>.
Os vários valores para as variáveis são fornecidos como exemplos em uma tabela.
Example
Suponha que você esteja escrevendo um recurso para adicionar dois números em uma calculadora.
Feature - Adicionar.
Scenario Outline: Add two numbers.
Given the input "<input>"
When the calculator is run
Then the output should be <output>"
Examples
| input | output |
| 2+2 | 4 |
| 98+1 | 99 |
| 255+390 | 645 |Uma seção de esboço de cenário é sempre seguida por uma ou mais seções de exemplos, que são um contêiner para uma tabela. A tabela deve ter uma linha de cabeçalho correspondente às variáveis nas etapas de esboço do cenário. Cada uma das linhas abaixo criará um novo cenário, preenchendo os valores das variáveis