Como escrever cenários melhores conhecendo anti-padrões de Cucumber
Muitas empresas estão elencando o Cucumber como requisito para as vagas de QA. Pesquisando no Linkedin, podemos encontrar mais de 3.000 mil oportunidades pelo mundo. Fica claro que é um framework consolidado e, por isso, queremos compartilhar nossas experiências para te ajudar a estar sempre atualizado com o mercado!
Há 5 meses trabalho na Resultados Digitais como Quality Assurance Engineer. Durante esse tempo, usei muito o Cucumberno meu dia-a-dia. Sei que é um período curto, mas foi o suficiente para entender que ao aprender uma nova tecnologia, além de nos preocupar com as boas práticas, também é preciso saber o que não fazer.
Olhar para o que está errado ao escrever os cenários é uma ótima forma de aprender. Nesse post, vou compartilhar os nossos anti-padrões favoritos de Cucumber e sugerir alternativas que utilizamos aqui na RD. Com isso, tenho certeza que você vai passar a escrever cenários ainda melhores.
1. Usar elementos da interface do usuário
Quando comecei a trabalhar com Cucumber, lembro-me de usar os elementos da interface do usuário como base para descrever todo e qualquer cenário. Se você também faz isso, fique tranquilo(a), pois ao realizar uma busca rápida no Google, encontraremos muitos exemplos com essa mesma abordagem.
Para que possamos identificar os erros e sugerir melhorias usarei alguns cenários que encontrei no famoso motor de busca. Mãos à obra!
Ao analisar o cenário abaixo, devemos focar nas palavras chaves, as quais evidenciam a interface do usuário: username textbox, password textbox, click e button.
O problema aqui é que, se no futuro a interface do sistema for alterada, teremos o retrabalho de atualizar a descrição no arquivo de feature e posteriormente no arquivo de step.
Ao alterar a interface de modo que não altere o comportamento do sistema a descrição do cenário deve continuar igual e, se necessário, as mudanças devem ser implementadas apenas no arquivo de step.
Certo, mas como podemos reescrever esse cenário? É simples, basta escrever em um nível superior de abstração, removendo e/ou substituindo as palavras que referenciavam a interface do usuário.
Podemos observar que o cenário ainda não está escrito da melhor forma possível, porém vamos nos ater a corrigir apenas o anti-padrão em questão. E isso servirá para os demais casos.
2. Mais de uma regra de negócio no mesmo cenário
Outra dificuldade comum ao elaborar cenários é saber até onde vai o seu escopo. Não devemos ter mais de uma regra de negócio no mesmo cenário, visto que esse seria o critério base para separá-lo. Vejamos o exemplo:
Parece estar tudo certo não é mesmo? Errado! Ao ler o cenário estamos testando as operações de adição e subtração ao mesmo tempo. Se a operação de soma estiver com problema, não será possível verificar se a subtração está funcionando.
Com os cenários devidamente separados, obedecemos o princípio de responsabilidade única, aumentamos a confiabilidade e não deixamos espaço para dúvidas.
3. Cenários com nome ruim
O nome dos cenários ajuda, e muito, a entender o comportamento de uma determinada parte do sistema. Lembrando que o Cucumber tem como principal função a chamada documentação viva, precisaremos sempre nos preocupar em fornecer um nome expressivo para quem está lendo.
Ao observar o cenário abaixo com o nome Take out money without success, sabemos que não foi possível retirar o dinheiro, mas o motivo somente fica claro ao ler o resultado esperado.
Ao alterar o nome para algo como Requested amount greater than the balance é mais fácil de entender logo no início qual o comportamento que o cenário vai simular.
Particularmente, inúmeras vezes tive problema em nomear os cenários, mas com o tempo criei o hábito de escolhe-lo apenas no final da descrição. O motivo é que podemos usar a ação (When) e/ou o resultado esperado (Then) como base para o nome do cenário.
4. Descrever cenários como teste
Muitas vezes nos acostumamos a escrever os cenários passo a passo, como se tivéssemos realizando um teste manual no sistema. Contudo, conforme vamos evoluindo o conhecimento no framework, percebemos que o mais importante do cenário é o que ele pretende validar e não como vai validar.
Detalhes em excesso não são sustentáveis e causam confusão na hora da leitura. Observe o cenário abaixo:
Analisando o cenário, é possível verificar que ele está com muitos detalhes desnecessários, os quais não contribuem para a validação da regra do negócio.
Informar que vai submeter o formulário ou que o formulário deve ser exibido novamente, são informações que devem ficar implícitas na descrição e se necessário, farão parte da construção do step.
Ao remover os passos que não contribuem para a documentação temos um cenário mais objetivo.
5. Confusão com as palavras reservadas Given, When e Then
Apesar do Cucumber não fazer distinção entre as palavras reservadas Given, When e Then, gostamos de usá-las em nossos cenários para facilitar a leitura. Contudo, frequentemente, encontramos cenários onde as palavras foram usadas da forma incorreta.
Antes de exemplificar essa situação, é interessante relembrarmos o conceito. O Given deve ser usado como contexto e massa de dados, o When refere-se a ação ou evento e o Then diz respeito ao resultado esperado após os passos anteriores serem executados.
Podemos considerar o Given como passado, o When como presente e o Thencomo um futuro próximo.
No cenário de exemplo, o When não está empregado no passo correto visto que ter uma empresa na base e visitar a página de edição de empresa são pré-condições (Given) para realizar a ação de alterar o nome e o email da empresa.
Após essa pequena alteração, temos um cenário mais legível onde a ação mais importante do cenário é iniciada com a palavra reservada When.
Conclusão
Se você se identificou com alguns desses erros, é porque está no caminho certo! Nós também já cometemos esses deslizes e aprendemos muito. Construir cenários como documentação é uma tarefa desafiadora e posso afirmar que a melhor forma de evoluir é praticando.
Se você usa Cucumber para criar seus testes de aceitação, compartilhe nos comentários seus anti-padrões favoritos! Ah, caso goste da ferramenta e queira ocupar uma daquelas oportunidades incríveis que eu comentei no início do texto, temos um espaço esperando por você :)
Referências recomendadas
Livros:
- Cucumber e Rspec (Hugo Baraúna)
- Especificação por Exemplo (Gojko Adzic)
- The Cucumber Book (Matt Wynne, Aslak Hellesoy, Steve Tooke)
Curso:
