Elemar DEV

Tecnologia e desenvolvimento

BDD na prática – parte 3 – Gherkin

Olá pessoal. Tudo certo?!

Meu post anterior, nessa série, gerou uma boa discussão, nos comentários, sobre os benefícios da utilização de BDD. Pessoalmente, estou convencido de sua utilidade e da compensação de sua adoção. Entretanto, recomendo que você leia todos os argumentos e, se possível, colabore.

Nesse post, dou uma retomada em fundamentos explicando melhor a sintaxe da linguagem Gherkin.

Por que usar Gherkin?!

A maior dificuldade na construção de um software é entender exatamente o que precisa ser feito. Uma das formas de reduzir essa dificuldades é usar exemplos concretos para ilustrar o que se deseja que o software faça.

Cenários de uso são mais eficientes, na comunicação, do que descrições (por mais detalhadas que sejam) de como ferramentas funcionam.

Utilizar exemplos reais para descrever o comportamento desejado para um sistema nos mantem conectados com a visão dos nossos stakeholders.

Usar cenários de uso para descrever sistemas é um exercício de empatia.

Quando nos comunicamos usando cenários de uso reais, conseguimos fazer com que nossos clientes (e demais stakeholders) “visualizem” o uso. Dessa forma, conseguimos obter algum feedback útil (e, até, algums boas idéias) ANTES de escrever uma linha de código.

Faço isso há anos usando protótipos. Percebo também que posso aperfeiçoar essa mesma coisa usando Gherkin.

O que Gherkin entrega, afinal?

Usando Gherkin, temos uma maneira estruturada de descrever cenários reais de uso. Veja o exemplo:

#language: pt-br

Funcionalidade: Feedback quando cliente ultrapassa limite de crédito

	Observando o comportamento de clientes em nossa loja, observamos que, 
	muitas vezes, eles ultrapassam limites de crédito pré-acordados.
	Nesse cenário, precisamos ser cordiais, prestativos e respeitosos
	evitando desapontamento que possam fazer com que percamos esse cliente.

	Contexto: 
		Dado que já selecionei os produtos que desejo comprar
		E estou logado no sistema
		E estou no formulário de pagamento

	Cenário: Crédito foi ultrapassado
		Quando informo que desejo fazer a compra a crédito
		E submeto minha compra para aprovação
		E meu limite está ultrapassado
		Então o formulário deve ser reapresentado
		E deve ser apresentada uma mensagem RESPEITOSA indicando que meu limite foi ultrapassado.

Perceba:

  • Através de uma linguagem simples, foi descrito um cenário real de uso da aplicação;
  • O respeito a uma sintaxe básica permite a geração de testes automatizados de aceitação;
  • Cada linha do descritivo está vinculada a um possível teste de unidade, útil, para o domínio;

Importante destacar que, usando SpecFlow, no Visual Studio temos “code completion” e “syntax highlighting”.

Gherkin é globalizado

Uma característica interessante da Gherkin é que ela não está presa a nenhum idioma.

Cada uma das palavras-chave do Gherkin foi traduzida para mais de quarenta idiomas, e é perfeitamente válido utilizar qualquer uma delas.

Expressões-chave

Gherkin possui um conjunto bastante pequeno de expressões-chave que orientam sua sintaxe. São elas:

  • Funcionalidade
  • Contexto
  • Cenário
  • Dado
  • Quando
  • Então
  • E
  • Mas
  • Esquema de cenário
  • Exemplos

 

Funcionalidade (Feature)

Funcionalidades são descritas e armazenadas em arquivos com extensão .feature.

Na prática, não afeta significativamente os testes que iremos escrever depois. Seu propósito é oferecer um texto descritivo sobre o grupo de testes que segue (cenários).

Veja:

Funcionalidade: Feedback quando cliente ultrapassa limite de crédito

	Observando o comportamento de clientes em nossa loja, observamos que, 
	muitas vezes, eles ultrapassam limites de crédito pré-acordados.
	Nesse cenário, precisamos ser cordiais, prestativos e respeitosos
	evitando desapontamento que possam fazer com que percamos esse cliente.

 

Perceba:

  • O texto imediato, na mesma linha da palavra-chave, corresponde ao nome da feature;
  • As linhas que seguem funcionam como uma espécie de descrição;

Cenário (Scenario)

Cenários descrevem um comportamento desejado para o sistema. Cada Funcionalidade pode conder diversos cenários. Cada cenário é um exemplo concreto de como o sistema deveria se comportar em uma determinada situação.

Cada Funcionalidade, tipicamente, tem entre cinco e vinte cenários, cada um descrevendo formas diferentes de funcionamento conforme determinada circunstância.

Cenários seguem sempre um mesmo padrão:

  1. Colocam o sistema em um determinado estado;
  2. Fazem alguma ação sobre o sistema (provocação);
  3. Examinam o novo etado.

Dado (Given), Quando (When) e Então (Then)

No Gherkin, usamos estas palavras chaves para identificar uma das três etapas que formam o cenário:

  1. Dado – Colocam o sistema em um determinado estado;
  2. Quando – Fazem alguma ação sobre o sistema (provocação);
  3. Então – Examinam o novo estado.

E (And) e Mas (But)

Cada linha de um cenário é conhecida como etapa (step). Para não sobrecarregar um step, podemos usar recursos de particionamento E e Mas. Observe:

	Cenário: Crédito foi ultrapassado
		Quando informo que desejo fazer a compra a crédito
		E submeto minha compra para aprovação
		E meu limite está ultrapassado
		Então o formulário deve ser reapresentado
		E deve ser apresentada uma mensagem RESPEITOSA indicando que meu limite foi ultrapassado.

 

Mais tarde, isso facilitará a escrita de testes mais próximos da unidade.

Contexto (Background)

Quando todos os cenários compartilham o mesmo estado inicial, podemos facilitar o trabalho promovendo a expressão “Dado” (Given)  para o bloco contexto. Veja:

	Contexto: 
		Dado que já selecionei os produtos que desejo comprar
		E estou logado no sistema
		E estou no formulário de pagamento

Bacana, não?!

Esquema de cenário (Scenario Outline)  e Exemplos (Examples)

Por fim, Gherkin oferece uma alternativa simples para que possamos testar diferentes resultados possíveis com cenários de uso semelhantes. Veja:

#language: pt-br

Funcionalidade: Adição
	Para evitar enganos
	Enquanto alguém com dificuldades em matemática
	Eu gostaria de facilitar a soma de dois números

Contexto: Eu tenho uma calculadora

Esquema do Cenário: Adicionar dois números
	Dado que informei "" para a calculadora
	E que informei "" para a calculadora
	Quando Eu pressionar "Add"
	Então o resultado deverá ser "".

	Exemplos: 
		| valor1 | valor2 | resultado |
		| 70     | 50     | 120       |
		| -48    | -27    | -75       |

Acho que você pegou a idéia.

Quem escreve em Gherkin?

Penso que o trabalho de escrita do arquivo Gherkin possa ser feita em conjunto pelo time de desenvolvimento e pelo pessoal de negócio. Assim, formamos documentos com a “língua” do pessoal de negócio (especialistas no domínio), mas estruturada suficientemente para facilitar a escrita do código de testes.

Por hoje, era isso.

4 comentários em “BDD na prática – parte 3 – Gherkin

  1. Olá Elemar.

    Complementando com um exemplo meu comentário feito no post Parte 2, e tendo como base o seu cenário descrito:
    Cenário: Crédito foi ultrapassado
    Quando informo que desejo fazer a compra a crédito
    E submeto minha compra para aprovação
    E meu limite está ultrapassado
    Então o formulário deve ser reapresentado
    E deve ser apresentada uma mensagem RESPEITOSA indicando que meu limite foi ultrapassado.

    A dificuldade que tivemos e acabamos não insistindo no assunto por enquanto foi que o analista de negócio não quer gastar tempo com o detalhe de cada passo, por exemplo, no nosso caso ele quer simplesmente definir: “caso o credito foi ultrapassado, uma mensagem respeitosa seja mostrada ao usuário.”. Até mesmo porque, a escrita deste passo a passo requer um pouco de raciocínio de lógica, mas natural para o pessoal de TI.
    Outra questão, é que o analista de negocio no nosso caso não usa o Visual Studio, então não teria alguns facilitadores como o code completation dos vocabulários já existentes.

    O trabalho de transformar essa frase curta do analista de negocio para a especificação testável ficou a cargo do analista de sistemas, que também está próximo do programador que fará a etapa final de implementação dos testes.

  2. Pingback: BDD na prática – parte 4 – Partindo do TDD « Elemar DEV

  3. Enaldo
    11/06/2013

    Parabéns pelo post. Confesso que de todos os que vi, este foi o mais bem explicado e exemplificado. Nunca pare.

    Parabéns

  4. Leandro
    13/10/2013

    Oi, supondo que eu já tenha as features do Gherkin construídas, quem deve codar os teste do Gherkin? Testadores ou os Implementadores?

    Outra coisa, os testes que são realizados por ele são “unitários” ou eles devem simular um usuário real manipulando a interface?
    Obrigado, muito bom o post.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Informação

Publicado às 12/04/2012 por em Post e marcado , .

Estatísticas

  • 628,324 hits
%d blogueiros gostam disto: