Você já Tentou Automatizar um Cenário do Gherkin?

No fundo, não é uma tarefa tecnicamente difícil, e por incrível que pareça, o mais difícil mesmo é ter um bom cenário para começar (mas essa é uma história para outro dia).

Vamos focar no problema, que é converter cenários Gherkin em testes de aceitação automatizados. Para entender como eles funcionam nós precisamos voltar um pouco no passado, esses cenários evoluiram dos Unit Tests utilizados pelas equipes que praticaram TDD (Test-Driven Development).

O que são Unit Tests, testes unitário em Português? Bom, no TDD eles são usados para guiar o processo de desenvolvimento. Existem padrões que definem a estrutura de um bom Unit Test, o padrão AAA por exemplo, sugere que eles devem ser estruturados em três partes:

Arrange (o código para preparar e configurar o contexto)

Act (a execução do código a ser testado)

Assert (comparar o resultado final com o resultado esperado)

Observe o exemplo abaixo de um teste unitário escrito em Java que testará a funcionalidade de "depositar" de um componente chamado BankAccount.

Imagine que você é um business stakeholder (ou cliente do projeto) sem conhecimento técnico, o exemplo acima faria sentido para você?

O programador fez um ótimo trabalho escrevendo o código de maneira compreensível, ele utiliza os nomes não-técnicos da área do negócio bancário como: bank account, deposit, get balance, current balance, actual balance. Até o nome do teste é "deposit_amount_into_account", ou seja sem linguajar técniquês.

O criador do BDD, Daniel North, gostou deste conceito de especificação via testes, mas o documento ainda é complicado para pessoas sem conhecimento de programação. Será que, existe a possibilidade de separar a documentação e especificação do código?

Anatomia de um Teste Unitário

Um teste unitário consiste de duas partes amarradas em uma única função:

Documentação/Especificação: Nome do teste, nomes usados nas variáveis e componentes.

O código de teste mostrando como a funcionalidade deve se comportar.

Que tal refatorar esse código e extrair a documentação/especificação disso aí?

Engines BDD/Motor BDD

Unit Testes dependem da uma engine (motor em inglês) que execute os testes e retorne os resultados, no exemplo acima foi usado o JUnit 5. A arquitetura de uma framework de testes unitários é bem simples.

A engine de BDD (como Cucumber para a plataforma Java) tem o comportamento parecido, a diferença mais chamativa são os componentes, que são separados em três partes:

A documentação/especificaçao é chamada de Feature File

O código de teste é movido para arquivos chamados de Step Definition ou Glue code

O código de produção que implementa a funcionalidade

Confira o exemplo abaixo:

A Arquitetura de uma Engine BDD

Existem várias implementações das engines BDD para diferentes plataformas. A primeira implementação, jBehave, foi escrita em Java, mas hoje em dia a implementação mais usada do Java é o Cucumber. Existem implementações para outras plataformas, como por exemplo o SpecFlow para Dotnet.

É assim que a engine amarra os componentes de um cenário.

Quando os testes forem executados, a engine vai ler os cenários escritos em Gherkin contidos no feature file(1). Eles serão lidos e interpretados de cima para baixo, para cada linha do cenário (um step) a engine vai encontrar a parte do código de teste no arquivo step definition correspondente (2).

O código de teste atrelado à linha do cenário é então executado, e é aqui onde o código vai interagir com o produto que está sendo testado. Assim como um teste unitário, o código do teste vai configurar um contexto, depois executar a funcionalidade e verificar os resultados

O código do teste geralmente é criado pelo próprio desenvolvedor ou às vezes por um testador com experiência em programação.

So agora o desenvolvedor vai então implementar a funcionalidade do produto (3). O desenvovimento estára pronto quando o teste passar. No fim, a engine irá criar uma documentação (4) baseada no Feature File, incluindo todos os resultados dos cenários.

Como Implementar a Funcionalidade de um Cenário?

Na tradição do TDD, o desenvolvimento propriamente dito começa com um teste que falha, validando o próprio teste.

Vamos criar o teste primeiro

Começando com o cenário Gherkin, você precisa criar código de teste que é mapeado para cada linha do seu cenário. O mapeamento depende da linguagem da sua plataforma, em Java, isso é feito com anotações.

Você deveria ter agora uma classe que contem todos os métodos que serão chamados quando o cenário for executado pela engine BDD. Esse arquivo é chamado de glue code ("código cola") porque ele faz a conexão entre o cenário Gherkin e o código de teste. As engines de BDD podem ajudar com essa etapa inicial gerando o esqueleto deste arquivo automaticamente.

Executar o cenário pela engine deveria produzir um cenário que falha, consistido de três etapas (baseado no exemplo acima).

Depois de ter o cenário pronto com o teste falhando, agora é hora de fazer ele passar!

A abordagem geral se chama outside-in ("de fora para dentro"), onde introduzimos passo a passo os componentes da aplicação com a necessária funcionalidade. Igual a abordagem do TDD, imaginamos a interface da aplicação como se ela já existisse, é a visão de fora. Ela precisa permitir três coisas:

Preparar o contexto da aplicação

Executar a funcionalidade dentro da aplicação

E por último mas não menos importante, verificar o estado dentro da aplicação depois da execução.

Criar essa API é essencialmente uma atividade de design.

Em BDD, os cenários apontam para uma camada externa da sua aplicação, definindo uma interface de alto nível. BDD não é tão adequado para definir o comportamento de componentes internos (ou técnicos).

É neste momento que o BDD passa a bola para TDD. Como o TDD trata disso, é uma história para outra hora.