Gherkin: o dia em que entendi que estava escrevendo errado.

Published in

Revista eQAlizando (antiga Revista TSPI)

9 min readMay 4, 2020

Fonte da Capa (parte dessa imagem foi utilizada para montagem)

Quem está iniciando no mundo do teste de software, vai se deparar, com um tempo, a uma quantidade de assuntos infindáveis. É muita coisa, mesmo! E nesse ínterim, você irá conhecer algumas ferramentas de apoio para o seu dia a dia. No meu caso, quero compartilhar nesse post, um pouco da minha experiência com a linguagem Gherkin (o “idioma” do Cucumber) e qual percepção tive ao me deparar que estava no caminho errado, após entender seu real propósito.

MAS ANTES… UM BREVE APANHADO SOBRE O GHERKIN

O QUE É GHERKIN?

Disponível para mais de 37 idiomas, é uma poderosa linguagem natural desenvolvida para que humanos possam a utilizar como forma de entendimento e compreensão acerca das especificações levantadas a partir da perspectiva do stakeholder.

Uma de suas características é, justamente, não necessitar dos detalhes de implementação para que funcione, pois mais a frente, você entenderá sua finalidade.

Seu uso pode se dar através do Cucumber (uma ferramenta que aplica o conceito de BDD — Behavior-Driven Development).

QUANDO, POR QUE E PARA QUÊ FOI CRIADO?

Seu criador, Aslak Hellesøy, estava incomodado como os requisitos eram escritos, de forma ambígua e mal compreendida. Em 2003, Aslak soube da existência de um grupo de pessoas que buscavam maneiras de como o TDD poderia ser melhor aplicado (Test Driven Development). A ideia era conseguir combinar testes de aceitação automatizados (ATDD — Acceptance Test Driven Development), requisitos funcionais e outros artefatos de software em um formato que fosse compreendido por qualquer pessoa. Após muitas tentativas e erros, enfim, nasce, em 2008, o Cucumber e sua linguagem Gherkin.

Ainda nesse contexto, Gojko Adzic resolveu dar um nome melhor ao BDD (o chamando de Especificação por Exemplo), pois muitas pessoas associavam o acrônimo a uma ferramenta (um problema comum até os dias de hoje). Basicamente, esse processo é bifurcado nas atividades conhecidas como:

Specification Workshops (Three Amigos)
Diz respeito às reuniões curtas e frequentes, com no mínimo três representantes de cada área pertencente ao time (Analista de Negócio ou Product Owner, Testador e Desenvolvedor). A ideia é discutirem sobre uma ou mais features a serem implementadas. Os “Três Amigos” exercitam e conversam sobre exemplos que ilustram as regras de negócio e os critérios de aceitação, como à aplicação deve se comportar para uma possível utilização dos cenários no Cucumber.
Outside-In Development
Após a especificação, os programadores traduzem o entendimento de cada cenário para a linguagem Gherkin, a qual, ao ser executada (através do Cucumber), retornará o que precisa ser implementado (nesse caso, métodos serão criados automaticamente).
Essa técnica é chamada de Outside-In (“de dentro para fora”), pois os programadores geralmente começam com a funcionalidade que está mais próxima possível à interface do usuário. A medida em que percebem outras necessidades, avançam até chegar no que consideram o esperado.

Para um melhor entendimento, seguem dois exemplos ilustrativos, fazendo um paralelo com e sem o uso do Ghekrin.

SEM O GHERKIN

Discussão segregada sobre uma regra de negócio (Fonte da imagem)

COM O GHERKIN

Quando o entendimento é geral (Fonte da imagem)

UM POUCO DE SINTAXE

Gherkin usa um conjunto de palavras-chave para dar significado às especificações junto ao Cucumber. Existe uma forma padrão de escrita, porém, a ideia aqui não é aprofundar, mas sim, apenas mostrar sua estrutura básica e alguma variação.

Como havia dito, cada identificador (nas ilustrações, serão apresentados em negrito) presente na linguagem é traduzido em vários idiomas, no nosso caso, utilizaremos o português para facilitar o entendimento.

EXEMPLO 1

EXEMPLO 2

Variação com reuso e acréscimo de outros conectivos

QUANDO UTILIZÁ-LO?

Se você faz parte de um time ágil, provavelmente já é familiarizado com o assunto, caso contrário, é quase certeza que será cobrado na hora de uma entrevista de emprego. Mas de modo geral, seu uso dependerá muito do negócio e a maneira de como a empresa atua.

UMA BREVE RECAPITULAÇÃO DA PIRÂMIDE DE TESTE

É importante relembrar um pouco sobre o que a Pirâmide de Teste pode nos ensinar quanto ao processo de automatização.

A figura abaixo ilustra os diferentes níveis de camadas de teste e suas diferenças quanto ao ganho e proporcionalidade. Uma possível leitura seria: quanto mais testes unitários existirem, menor será o custo ao projeto e possíveis dores de cabeça? Sim! Contudo, lembremos que, em hipótese algum, devemos pensar nessa pirâmide ao contrário, pois o ônus seria alto em todos os sentidos.

Procure, sempre que possível, respeitar a linha vertical hierárquica. Mas para que isso funcione, é extremamente importante que o time coopere, além de possuir uma maturidade suficiente que garanta o funcionamento do processo.

Dica preciosa: não desperdice o seu tempo tentando automatizar ao máximo na camada de Interface (end-to-end) simplesmente por fazer, mas sim, seja coerente e automatize somente aqueles cenários considerados de suma importância, segundo sua expertise, combinado com os mais utilizados pelo usuário final, que, necessariamente, podem não ser os mesmos que você elencou.

Obs.: há quem use o Cucumber no nível de teste de integração, porém, não posso opinar a respeito, pois não cheguei a me aprofundar nesse estudo.

PREFIRA SER DECLARATIVO A IMPERATIVO

Uma das premissas do Gherkin é criar cenários de forma clara e objetiva, conforme as recomendações do BDD. Contudo, ao escrevê-los, há uma separação de conceitos comportamentais de como e o que devemos aplicar numa escrita, respectivamente chamados de cenários imperativo e declarativo.

CENÁRIO IMPERATIVO (COMO)

Creio que deu para captar os passos desnecessários e irrelevantes, certo? Perceba o quão maçante é ter que ler uma quantidade grande de linhas. Concorda, também, que essa forma acaba sendo mais evidente a ter um usuário cadastrado com sucesso, que é o objetivo? O nível de detalhamento é alto a ponto de ser confundido até com um caso de teste (muita informação e de difícil manutenção). E ainda vou mais além, imagine alguém do time (ou até de outro) que queira verificar esse ou outro cenário, que segue esse mesmo raciocínio, e lhe causar a seguinte dúvida: isso é um caso de teste, uma user story ou qualquer outra coisa?

CENÁRIO DECLARATIVO (O QUE)

Perceba que os atributos, descritos no primeiro exemplo, foram removidos, ficando assim, um cenário mais enxuto e menos verboso. Isso facilita, caso venha a ocorrer alguma alteração em um campo da tela que possa impactar nesse ou em até outros cenários. É bem mais interessante realizar qualquer alteração na implementação de uma classe step, a fazer alterações na feature.

Obs.: mais adiante, discutiremos que é um erro comum escrever cenários em primeira pessoa do singular.

O INÍCIO DA MINHA JORNADA

CONTEXTUALIZANDO

Quando iniciei nesse mundo da automatização, comecei me enganando com o record and play do Selenium, achando que isso era automatizar. É duro dizer, mas talvez seja uma situação comum a muitos no começo, porém, foi o que conheci na época. Como era a minha primeira experiência, então já fui logo entendendo como funcionava o processo de criação dos scripts.

Apesar da minha menção em judiá-lo, confesso que no início me ajudou bastante, pois estava em um período que era necessário realizar vários testes de regressão e, portanto, não podia perder tempo ficando somente nos testes manuais. Entretanto, no decorrer da caminhada, fui percebendo mais desvantagens que propriamente vantagens do seu uso. Então, resolvi pesquisar maneiras mais eficientes de trabalhar e o que estava na “moda”. Foi aí que encontrei o Cucumber na minha vida.

Nesse período, trabalhei com um colega (Pedro p Pinheiro, que mais tarde, se tornou um amigo) que entendia do assunto e pedi que me explicasse o funcionamento. No início, achei um pouco confusa a dinâmica — talvez por não gostar de programar nesse tempo — mas depois a ficha foi caindo e comecei a compreender.

E, por conta disso, forçadamente, tive que voltar a estudar programação e enfrentar esse obstáculo, senão o Cucumber seria um alvo bem distante para mim.

Além de rever lógica e programação Java, busquei por cursos que abordassem, de forma intuitiva, o “kit básico” de um futuro “javeiro” testador: Cucumber com Selenium WebDriver.

QUANDO DESCOBRI QUE ESTAVA NO CAMINHO ERRADO

Antes de dar continuidade à minha jornada, vale abrir um parêntese e ressaltar que esse post nasceu por conta de uma das sessões de mentoria com o grande Júlio de Lima, por meio do seu curso #TSPI (Teste de Software Para Iniciantes). Mostrei como estava escrevendo meus cenários em Gherkin e ele me alertou para vários erros cometidos. Também, sugeriu que eu buscasse mais a respeito do tema e pudesse, de alguma forma, compartilhar com a comunidade, meus erros e acertos (aqui eu fecho o parêntese).

Continuando… após ter aprendido o “kit básico”, a cada descoberta, era uma conquista. Me sentia super bem quando a integração rodava. Mas com o tempo, algo começou a me incomodar. E nesse questionamento, pesquisei maneiras de como a galera escrevia cenários. Algumas escritas pareciam bastantes com as minhas, já outras, bem diferentes. E nessa confusão em saber se o que estava fazendo era o certo ou errado, me deparei com o blog do criador do Cucumber. Foi uma surpresa e alívio ao ler alguns dos seus artigos, tendo a certeza do quão errado eu estava. Creio que deva ser um senso comum a todo testador iniciante que deseja automatizar.

A forma como escrevemos cenários está ligado à nossa percepção intrínseca, pois enveredamos por um caminho que faz uso de um linguagem natural para escrever o teste. E esse é um pensamento errado. Devemos separar texto de código, sempre. A ideia, de um lado é, codificar, aplicando conhecimentos de um ou mais desing pattern e, do outro, criar cenários independentes do código. Em poucas palavras, não transformar texto em código, simples como tampar uma caneta.

MEU CENÁRIO NA FORMA ERRADA

Utilizei outros recursos que o Gherkin dispõe para facilitar na hora de automatizar o meu cenário. O quê? Foi isso mesmo que pensei e fiz. Estava tão empolgado com a “ferramenta” que acabei fazendo uso da forma incorreta.

Consegue identificar algo de errado? Com ou sem certeza? Bom… é possível perceber que apliquei um anti-pattern, ou seja, vários erros cometidos e que vão na contra mão das boas práticas. Vamos pontuá-los:

Não tem a menor relevância esse cenário, a não ser que o intuito fosse puramente para automatizar e ignorar qualquer comportamento, o que, ainda sim, vai contra os princípios de BDD;
Tentei deixá-lo o mais genérico possível, na tentativa de reutilizá-lo e, explicitamente, com a intenção de transformar o texto em código;
Por conta do uso de tabela, sempre consideramos uma perda no tempo de execução;
Problema de manutenção, pensando nos futuros cenários que poderão ser executados;
Linhas 6, 8, 9, 10 e 11: não é um boa prática escrever cenários em primeira pessoa, mas em terceira, pois é uma forma de expressar, genericamente, que tipo de ator estará em contexto;
Linha 9: o conectivo “e” deveria ser considerado em uma nova linha e não a continuação da mesma;
Linhas 13–18: a utilização de tabelas de exemplo deveria servir apenas para facilitar a colaboração entre os stakeholders.

FAZENDO DA FORMA CORRETA

Perceba que, mesmo não sendo um cenário que considero como essencial (estou apenas expondo com base no meu caso real), ainda sim podemos considerar uma grande melhora e uma visão comportamental mais concisa.

Nesse cenário, é possível identificar a utilização do pronome pessoal na terceira pessoa;
Linha 1: vamos aceitar, hipoteticamente, que o comportamento deve ser esse;
Linhas 2–4: Não precisei expor o como, mas sim o que;
Linha 4: resultado conforme comportamento esperado

FINALIZANDO…

É sempre importante compreender os conceitos e fundamentos de algo que se está aprendendo. Mais ainda, buscar ajuda quando necessário e, posteriormente, poder compartilhar o conhecimento, apresentando casos reais, que poderão, de alguma forma, ajudar outras pessoas que estão passando pelo mesmo problema.
Espero que, nesse post, o entendimento sobre o Gherkin e seu uso, tenha sido bastante esclarecedor.