5 boas práticas para uso de Cucumber

Publicado por Ana Paula Vale no dia qa

boa prática cucumber

No ShipIt sempre contamos para você como testamos nossas features aqui na Resultados Digitais e quais ferramentas usamos para isso. Como exemplo, tivemos posts sobre boas práticas em testes de aceitação e sobre como pensar em testes no início do processo de qualidade dentro do seu time ágil com Cucumber.

Adotamos Cucumber para criar nossos testes de aceitação e aplicamos algumas práticas de uso para mantermos a qualidade do código de teste e como reutilizá-lo. Vou trazer algumas dessas práticas para te ajudar a saber usar da melhor forma essa ferramenta.

1. Use Background e seja DRY

Quando começamos a aprender a escrever Gherkin a nossa tendência é sair escrevendo todos os cenários e, não sei você, mas em algum momento eu já repeti alguns passos que eram utilizados por todos os demais cenários que eu estava descrevendo naquela Feature.

Até que um dia descobri que existe uma palavra reservada do Gherkin conhecida como Background (“Contexto” quando descrevemos a feature em pt-BR). Ao escrevermos usando um contexto, podemos adicionar passos que se repetem em todos os cenários, evitando acoplamento de responsabilidades e retrabalho caso ocorra alguma mudança na feature.

Um exemplo é a funcionalidade de criar usuários numa aplicação:

Sem Background

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@create_users @javascript
Feature: Create new users
In order to create new users
As a App user
I want to have access to the App

  Scenario: Show success message when create user with all information filled
    Given I have logged in
    And I have access to the Create Users App
    And I am on create new user page
    And I insert all of user information
    When I click on save button
    Then I should see a success message

  Scenario: Show error message when try to create user without email
    Given I have logged in
    And I have access to the Create Users App
    And I am on create new user page
    When I do not fill the email
    And I insert all of other user information
    And I click on save button
    Then I should see a error message

Com Background

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@create_users @javascript
Feature: Create new users
In order to create new users
As a App user
I want to have access to the App

  Background:
    Given I have logged in
    And I have access to the Create Users App

  Scenario: Show success message when create user with all information filled
    And I am on create new user page
    And I insert all of user information
    When I click on save button
    Then I should see a success message

  Scenario: Show error message when try to create user without email
    And I am on create new user page
    When I do not fill the email
    And I insert all of other user information
    And I click on save button
    Then I should see a error message

Sim, o Background é tipo um Before do Rspec usado no código. Se existir Before hooks e Background no seu teste, o Before do hooks é executado primeiro.

2. Saiba mais sobre os chamados Scenario Outline

Veja a situação a seguir:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Scenario: Show a sum result when I execute a sum operation
  Given I am on the calculator
  When I press the number 4
  And I press the number 2
  And I choose the sum operation
  Then I should see the 6 as result

Scenario: Show a subtraction result when I execute a subtraction operation
  Given I am on the calculator
  When I press the number 4
  And I press the number 2
  And I choose the subtraction operation
  Then I should see the 2 as result

Scenario: Show a multiplication result when I execute a multiplication operation
  Given I am on the calculator
  When I press the number 4
  And I press the number 2
  And I choose the multiplication operation
  Then I should see the 8 as result

Scenario: Show a divide result when I execute a divide operation
  Given I am on the calculator
  When I press the number 4
  And I press the number 2
  And I choose the divide operation
  Then I should see the 2 as result

Observando a situação acima, perceba que os 4 cenários criados têm a mesma validação para o resultado e praticamente os mesmos passos. Além disso, pense que agora você quer fazer cenários para mais operações existentes na calculadora. Não parece algo legal, não é mesmo? Visto que não escala e dificulta a manutenção.

Sendo assim, o Cucumber traz para nós uma maneira de organizar esses cenários e mantê-los da melhor forma que são os Scenario Outlines, ou se você quiser chamar em português, os Esquemas de cenário.

Quando você usa Scenario Outlines, cria uma tabela de exemplos em que cada linha dela irá representar um cenário. Voltando para os 4 cenários apresentados acima, é como se criasse variáveis para os valores que se alteram em cada cenário e as utilizasse na tabela. Fica assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
Scenario: Show a right result when I execute a operation on calculator
  Given I am on the calculator
  When I press the number <number_one>
  And I press the number <number_two>
  And I choose the <operation> operation
  Then I should see the <result> as result

  Examples:
    | number_one | number_two |    operation   | result |
    |     4      |      2     |      sum       |   6    |
    |     4      |      2     |   subtraction  |   2    |
    |     4      |      2     | multiplication |   8    |
    |     4      |      2     |     divide     |   2    |

A primeira linha da tabela representa as variáveis escritas assim <variavel> que você usa no cenário e as outras linhas são os exemplos para execução dos testes com seus respectivos resultados esperados.

Viu como fica mais fácil de escrever e manter os cenários? Além de serem mais legíveis também.

3. Escreva mais cenários declarativos e menos imperativos

Segundo Hugo Baraúna em seu livro Cucumber e Rspec, o Cucumber é mais uma ferramenta de documentação do que uma de automação de testes. Além disso, escrever testes de aceitação em Gherkin nos exige como principal objetivo a clareza.

É por isso que a maioria das dicas que listo aqui têm sempre a intenção de facilitar o entendimento do que transpomos no nosso arquivo Gherkin. A próxima tem relação com a relevância que damos em alguns cenários para passos com muitos detalhes desnecessários.

Para esses cenários damos o nome de imperativos, ou seja, que descrevem como deveria ser o comportamento do cenário e não exatamente o que ele quer. Por exemplo:

1
2
3
4
5
6
7
8
9
10
11
Scenario: Show success message when create new user
  Given I am on the Create Users App
  When I click on the "Create" button
  And I fill in the "Name" field with "user 1"
  And I fill in the "Email" field with "test@test.com.br"
  And I fill in the "Password" field with "password"
  And I fill in the "Phone" field with "123456"
  And I fill in the "City" field with "City"
  And I fill in the "Country" field with "My country"
  And I click on "Submit" button
  Then I should see "User saved"

Observe que existem vários passos com muitos detalhes que não são relevantes para a pessoa que vai ler este cenário. São muitos campos, como: nome, email, senha, telefone, cidade, país e tudo isso pode tirar o foco do que realmente importa: a criação com sucesso de um novo usuário na base.

Refatorando o Gherkin, teríamos algo como abaixo, conhecido por cenário declarativo, que descreve o que é realmente válido para a compreensão do que está sendo validado, melhorando sua legibilidade:

1
2
3
4
5
Scenario: Show success message when create new user
  Given I am on the Create Users App
  When I fill user information
  And I click on submit button
  Then I should see "User saved"

Você pode observar que aqueles detalhes referentes ao nome, email, telefone e outras informações do usuário, foram removidas e ficou mais claro o que o nosso cenário quer mesmo validar. Dessa forma, podemos escalar quando houver mudança em algum campo da tela, visto que, será necessário alterar somente a implementação nos steps definitions e não o arquivo .feature e a descrição dos steps definitions.

Tudo certinho com nossos cenários e já sabemos que uma boa prática é deixarmos os testes mais declarativos a ponto de todos que lerem a documentação que você criou, entendam o que está descrito e o que deve ser validado no teste.

Porém, devemos ter cuidado no seguinte caso:

1
2
3
4
Scenario: Show success message when create new user
  Given I have logged in
  When I fill all information
  Then I should see a message

Perceba o quanto este cenário está genérico, sem muita indicação do que será validado e sem regras do negócio, o que acarreta que ele não será utilizado como documentação ou para automação.

4. Faça uso de And e But

Já encontrei vários casos de pessoas que usavam as palavras reservadas Given, When e Then mais de uma vez nos seus testes. Não é errado repetir, porém pode se tornar bem confuso e incoerente para quem vai ler o cenário.

Observe o exemplo abaixo:

1
2
3
4
5
6
7
8
Scenario: Show error message when try to create user without email
  Given I have logged in
  Given I have access to the Create Users App
  Given I am on create new user page
  When I do not fill the email
  When I insert all of other user information
  When I click on save button
  Then I should see a error message

As palavras Given e When são repetidas diversas vezes no teste e dessa forma podem facilmente serem trocadas para And no cenário acima. Assim:

1
2
3
4
5
6
7
8
Scenario: Show error message when try to create user without email
  Given I have logged in
  And I have access to the Create Users App
  And I am on create new user page
  When I insert all of other user information
  But I do not fill the email
  And I click on save button
  Then I should see a error message

Os And e But que você venha a alterar terão o mesmo comportamento dos Given e When repetidos. Se você perceber quando for convertê-los para steps-definitions, eles terão a mesma nomenclatura, mas a descrição da sua funcionalidade será mais fácil de ler e entender.

5. Considere o uso de Tags

Agora imagine que você tem vários cenários especificados, de diversas features e existe tanta especificação que quando você vai executar os testes no terminal com o Cucumber, não consegue ter noção se era para determinado teste ser executado, se houve algum atraso causado por algum teste muito lento ou se um teste que não estava codificado conseguiu fazer com que a sua suíte de testes toda falhasse?

Parece difícil de resolver, mas não é quando você começa a usar as tags que o Cucumber te proporciona. Para usar uma tag você cria uma palavra que significa algo referente ao contexto que você quer diferenciar dos outros cenários e prefixa essa palavra com um @, adicionando ela antes das palavras reservadas Feature e Scenario (Funcionalidade e Cenário se o idioma que você estiver usando for pt-BR). Assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@create_users @wip
Feature: Create new users
In order to create new users
As a App user
I want to have access to the App

  Background:
    Given I have logged in
    And I have access to the Create Users App

  @basic_user  
  Scenario: Show success message when create user with all information filled
    And I am on create new user page
    And I insert all of user information
    When I click on save button
    Then I should see a success message

Explicando as tags que adicionei: a @create_users é referente à feature que está descrita e indica que todos os testes estão relacionados com a criação de usuários no sistema e essa tag será herdada por todos eles. A tag de @wip indica o “work in progress” e nos ajuda aqui no chapter de QAs a não executar testes que ainda não estejam prontos e possam vir quebrar toda a suíte de testes.

A última tag @basic_user foi adicionada apenas para o cenário que tem a pré-condição do usuário logado no sistema ser do perfil basic, que possui poucos privilégios, mas necessários para que consiga realizar o cenário. Além disso, existe a possibilidade de você adicionar tags para Scenario Outlines e para os Examples deles.

Aqui no nosso time de QAs usamos bastante as tags, pois somos divididos em times para cada funcionalidade que desenvolvemos e, dessa forma, nós produzimos muitos cenários que ficariam bem desorganizados quando quiséssemos executar todos os testes na nossa suíte. Sendo assim, decidimos aderir às tags com os nomes de cada time que facilita a nossa maneira de executar, como também reportar falhas do sistema.

Conclusão

Tudo o que falei são dicas e recomendações das melhores práticas que utilizamos aqui na Resultados Digitais, com o objetivo de ajudar você a produzir uma documentação mais clara e coesa. Algumas dicas são bastante relevantes, porém não são todas e, por isso, resolvi dividir esse post em duas partes. Na próxima você aprenderá mais sobre como escrever melhores Steps Definitions e como fazer bom uso deles, além de unir às dicas que passei relacionadas à escrita do Gherkin.

Você usa Cucumber para criar seus testes de aceitação? Já usou algumas das dicas acima? Me conta nos comentários.

O que usei de referência e recomendo bastante

Ana Paula Vale

Ana Paula Vale

Quality Assurance

Comentários