Como escrever cenários melhores conhecendo anti-padrões de Cucumber

Publicado por Danielle Moreira Alexandre no dia qa

anti-padrões 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 Cucumber no 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.

1
2
3
4
5
6
Scenario: Login successfully
  Given the login page is opening
  When I input username into the username textbox
    And I input valid password into the password textbox
    And I click Login button
  Then I am on the Home page

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.

1
2
3
4
5
6
Scenario: Login successfully
  Given the login page in opening
  When I input username
    And I input valid password
    And I login in the system
  Then I am on the Home page

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:

1
2
3
4
5
Scenario: A calculator
  Given a calculator I just turned on
  When I add 4 and 5
    And I subtract 3
  Then the result is 6

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.

1
2
3
4
5
6
7
8
9
Scenario: Addition
  Given a calculator I just turned on
  When I add 4 and 5
  Then the result is “9

Scenario: Subtraction
  Given a calculator I just turned on
  When I add 5 from 9
  Then the result is “4

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.

1
2
3
4
Scenario: Take out money without success
  Given that I have an account
  When I take out 100 reais
  Then I see the message "Balance unavailable"

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.

1
2
3
4
Scenario: Requested amount greater than the balance
  Given that I have an account
  When I take out 100 reais
  Then I see the message "Balance unavailable"

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:

1
2
3
4
5
6
7
8
Scenario: Credit card number too short
  Given I have chosen some items to buy
    And I am about enter my credit card details
  When I enter a card number that’s only 15 digits long
    And all the other details are correct
    And I submit the form
  Then the form should be redisplayed
    And I should see a message advising me of the correct number of digits

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.

1
2
3
4
Scenario: Credit card number too short
  Given I have chosen some items to buy
  When I enter a card number that’s only 15 digits long
  Then I should see a message advising me of the correct number of digits

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 Then como um futuro próximo.

1
2
3
4
5
6
Scenario: Edit the company
  Given I have logged in
  When I have companies in my base
    And I visit the company edit page
    And I change the company name and email
  Then I see a message notifying that company it's saved with success

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.

1
2
3
4
5
6
Scenario: Edit the company
  Given I have logged in
    And I have companies in my base
    And I visit the company edit page
  When I change the company name and email
  Then I see a message notifying that company it's saved with success

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:

Curso:

Danielle Moreira Alexandre

Danielle Moreira Alexandre

Quality Assurance Engineer

Comentários