Conversando com alienígenas, uma breve introdução ao Gherkin

#productivity

Olá, pessoal! Espero encontrar todos bem. Hoje vocês aprenderão a se comunicar com uma espécie muito curiosa e intrigante que vive sobre a superfície do nosso pálido ponto azul - ou planeta Terra se você não for tão íntimo.

Mas, antes de começarmos, preciso esclarecer uma coisa: se você começou a ler esse artigo esperando aprender a conversar com alienígenas de verdade, e talvez pensou que Gherkin fosse alguma máquina maluca de tradução de linguagens intergalácticas, detesto te desapontar, mas esse artigo não é bem sobre isso. Mas não desista de ler ele agora, prometo que esse material pode ser útil para você (mesmo se você realmente estiver querendo falar com aliens).

Certo, então qual é a espécie intrigante a qual eu me referi no começo do artigo? E sobre o que é esse material afinal?

No contexto deste artigo, quando falo em alienígenas, faço uma brincadeira com as pessoas da categoria a qual pertenço, me refiro a programadores e programadoras (devs) que em geral tem uma forma muito peculiar de interpretar o que as pessoas falam - darei exemplos e deixarei a analogia mais clara adiante. Esse artigo faz uma introdução a uma sintaxe, um modo de escrever determinado contexto, que elimina termos que possam não ser conhecidos por todos os interlocutores fazendo-o de uma forma declarativa, deste modo todos são capazes de compreender o contexto e qual é a mensagem a ser transmitida, aumentando assim a eficiência da comunicação entre os membros de um time em um ambiente de desenvolvimento de software, e claro, tornando mais fácil para nós desenvolvedores entender o que precisa ser feito. E o nome dessa estrutura mágica é Gherkin.

Problemática

Vamos fazer o seguinte experimento mental: imagine que uma nave alienígena pouse na sua frente, dela sai um homenzinho verde com clara capacidade de manter uma comunicação complexa, mas você não entende um único som que esse visitante espacial emite, e ele também não possui nenhum conhecimento prévio sobre sua língua e cultura. O que você faria para tentar compreender o que nosso visitante está dizendo e como você ensinaria a ele nossa língua para que ele pudesse nos entender?

A ideia de trazer esse experimento é causar a reflexão sobre como podemos nos comunicar com pessoas que não possuem o mesmo background que nós, que possuem outras ideias, onde aquilo que é óbvio para nós não é óbvio para nossos ouvintes. Nessa analogia, o homenzinho verde são os devs, e a questão é como um analista de negócio, gerente de produto ou qualquer outro estabelece contato conosco e nos solicita o desenvolvimento de uma nova funcionalidade. É claro que os papéis de marciano e terrestre podem ser facilmente invertidos, e que essa reflexão não vale apenas para comunicações onde devs estão envolvidos, mas também com qualquer pessoa, lembre-se que não é porque você fala a mesma linguagem que alguém, que não existirão ruídos na comunicação.

Mais uma historinha

Talvez você já tenha ouvido a piada onde alguém pede para um dev ir ao mercado com a seguinte instrução "Compre uma caixa de leite, e se tiver ovos traga dois" e assim o dev compra duas caixas de leite ao invés de uma caixa de leite e dois ovos como o solicitante queria. A piada pode ser engraçada, mas não é nada divertido quando essas confusões acontecem durante o desenvolvimento de um software, e a feature implementada não faz o que o solicitante esperava.

Por essa razão, o modo como uma funcionalidade deve ser descrita é muito importante, não só para o programador, mas para que todos os envolvidos no processo de construção de um software tenham o mesmo entendimento do que deve ser feito.

Só para constar, acho totalmente aceitável comprar duas caixas de leite considerando a instrução fornecida.

Falando sobre Gherkin

Gherkin é um dos elementos presentes no BDD (Behavior Driven Development) e basicamente consiste em escrever cenários de forma padronizadas, baseadas nas regras de negócio e usando palavras-chave para compor os passos que devem ser seguidos até uma conclusão, sendo sempre escritas na terceira pessoa.
Apesar de descrever as regras de negócio, o uso de palavras e termos que pertencem ao negócio deve ser evitado, é ideal que qualquer pessoa consiga ler e interpretar o que deve ser feito, mesmo que não possuam conhecimento de negócio. Em igual medida, termos técnicos e exemplo de codificação devem ser omitidos, essa especificação é o ponto onde todos os envolvidos na construção do software se encontram, sendo assim não pode haver termos que só um dos lados entenda.

Além do motivo supracitado para não acrescentar códigos na solicitação de uma demanda, existe outra boa razão para não fazer isso, o maior valor que um desenvolvedor entrega não é quanto código ele escreve, mas os problemas que ele resolve, somos bons em resolver problemas e gostamos disso, entregar o problema resolvido para "apenas" escrever o código elimina a maior entrega de valor que podemos dar, além de nos matar vagarosamente.

Os arquivos com a estrutura Gherkin são normalmente salvos com a extensão feature e possuem notações iniciadas com cerquilha # para indicar por exemplo a linguagem das palavras-chave usadas naquele arquivo, a indentação do conteúdo é estruturado com espaços e quebra de linha, deste modo o aninhamento do conteúdo e as palavras-chave são identificadas. Essas especificações são especialmente importantes se você for manter esses conteúdos escritos em arquivos, mas nada o impede de usar a caixa de texto de algum sistema para manter esse conteúdo, a fim de usar a ideia e as palavras-chave do Gherkin nas definições de suas demandas no software de gerenciamento de projetos que sua empresa já usa.

Palavras-chave

A lista abaixo apresenta as palavras-chave do Gherkin com uma breve descrição sobre seu objetivo

Feature: Descreve em níveis mais altos o propósito da funcionalidade e agrupa os diferentes cenários que podem existir;
Background: É o contexto, um conjunto inicial de steps que se repetem em todos os cenários da feature;
Scenario ou Example: Descreve um exemplo concreto sobre a regra de negócio e é ou não seguido por steps, é possível incluir quantos steps desejar;
Scenario Outline: Usado para descrever um cenário que se repete alterando as entradas e saídas;
Examples: Usado para construir um conjunto de exemplos de entrada e saída para usar dentro do Scenario Outline;
Step Given: Descreve a condição inicial do cenário;
Step When: Descreve um evento que normalmente causa uma mudança;
Step Then: Descreve o resultado esperado após o evento;
Step And: Pode ser usado para concatenar de forma positiva sentenças dos steps anteriores;
Step But: Pode ser usado para acrescentar uma negativa de forma subsequente a um dos steps superiores;

Casos de testes escritos com Gherkin

Para entendermos melhor a diferença entre simplesmente escrever a funcionalidade e escrevê-la usando Gherkin, que tal observamos um exemplo simples de login de usuário escritos das duas maneiras?

Simplesmente descrevendo:
Quando eu acessar o site e ir até a página de login e preencher o login a senha e clicar no botão de iniciar sessão, uma requisição a api do site deve ser feita transmitindo os dados preenchidos, se o resultado enviado pela api for positivo, uma mensagem de login efetuado com sucesso deve ser apresentada e o site deve me redirecionar para a página inicial do site mantendo minha sessão na memória do navegador.

Usando o Gherkin:

Feature: Login de usuário

  Scenario: Login de usuário válido
    Given que o usuário possua uma conta no site
    And acesse a página de login
    And preencha corretamente os dados de acesso
    When ele acionar o botão de entrar no sistema
    Then uma mensagem de sucesso deve ser apresentada
    And ele deve ser direcionado logado a página inicial do site

Como se pode observar, o modelo escrito com Gherkin é muito mais claro e omite qualquer detalhe técnico do desenvolvimento. Que tal darmos uma olhada em outro exemplo, agora usando as palavras-chave faltantes?

Feature: Café da tarde

Background:
  Given que os escritores de artigos sentem fome

Scenario Outline: Comendo fatias de bolo
  Given que existe <inicial> fatias de bolo
  When for comido <comido> fatias de bolo
  Then deve restar <restante> fatias de bolo

  Examples:
    | inicial | comido | restante |
    |    10   |    3   |     7    |
    |     5   |    5   |     0    |

Apesar dos exemplos modestos, acredito que seja possível compreender a ideia geral. Alguém poderia dizer que esse modelo adiciona mais trabalho na escrita dos cenários, ou mesmo que essa divisão parece infantil e que um texto corrido teria o mesmo efeito. Qualquer quantia de tempo acrescido na criação das descrições das atividades seria recuperada, uma vez que seria poupando tempo de manutenção e correções por conta do desentendimento quanto ao objetivo da função. Quanto a divisão parecer infantil, pense que você está escrevendo cenários para pessoas que não tem o mesmo conhecimento de negócio que você, imagine aquele marciano na sua frente e tente explicar para ele o que precisa ser feito...

Conclusão

Escrever os cenários com Gherkin é incrivelmente simples, o fato de ter poucas palavras-chave torna o modelo muito fácil de ser aprendido, e após escrever poucos cenários não é mais necessário pesquisar exemplos para se basear.

Além de ser fácil, esse modelo fornece uma estrutura de escrita que quando é bem usada, diminui consideravelmente os ruídos e mal-entendidos entre o que o solicitante precisar e o que é implementado de fato.

Por hoje é tudo pessoal, espero que tenham se divertido com a leitura e tenham se interessado por aprender um pouco mais sobre Gherkin, não deixe de conferir as fontes deste material.

Ah, e se encontrar um alien por aí, diga que eu mandei um "Oi!".