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:
- Colocam o sistema em um determinado estado;
- Fazem alguma ação sobre o sistema (provocação);
- 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:
- Dado – Colocam o sistema em um determinado estado;
- Quando – Fazem alguma ação sobre o sistema (provocação);
- 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.
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.
Pingback: BDD na prática – parte 4 – Partindo do TDD « Elemar DEV