Writing easy-reading tests with cucumber

Cucumber is a well known framework in the world of BDD (Behavior Driven Development) which allows you to define automated tests using natural language, from a user/customer’s perspective. It’s considered a powerful tool because you can write tests, and document what your software should do, at the same time.
Now, let’s go through some points that may help you write better and more reusable tests definitions.
If you are not familiar with what cucumber is or what it does, you can check the official page here.

Tip N° 1

Describe the feature that the test scenarios in your feature file will cover as clearly as possible.

Feature: User Login.  

It could be improved using something like:

Feature: As a user who is not logged in yet, I want to log in to the application.  
    I can log in introducing the correct username and password.
    I cannot log in if I leave the username or password blank.
    I cannot log in if the username/password combination is wrong.
    If I cannot log in, there should be a message showing that something went wrong.

Now, that is a way better feature description, since you can figure out how the login works only by reading this, without having to read every test scenario included in the feature file.

Tip N° 2

Make your test scenarios from the user’s perspective whenever possible.

Following the previous example, a possible test scenario could be something like:

Scenario: Test correct login  
    Given The login page is open
    When The username field is filled with TEST_USER in the login page
    And The password field is filled with TEST_PASSWORD in the login page
    And The login button is pressed in the login page
    Then The user should be in the home page

This scenario is correct; anyone can read it and know what it does. However, it could be much better if we write it from the user’s perspective instead of doing it from our own.

Scenario: As a user who is not logged in, I want to log in providing a correct username and password.  
    Given I navigate to the login page
    When I introduce my correct username in the username field in the login page
    And I introduce my correct password in the password field in the login page
    And I click the login button in the login page
    Then I should be in the home page

This way the scenario gets even more descriptive and if there were different user roles involved, they would be noticeable there.

Tip N° 3

Use Backgrounds whenever possible to avoid steps repetition.

In the example we have taken in the previous tip, we have at least one step that will be repeated in every test case and that is the step that opens the login page. What we can do is to remove that step from every scenario in the feature and add it to the Background section.

Eg.:

Background:  
Given I navigate to the login page  

Now, this step is going to be executed before each scenario. Besides, you can add as many steps as you want in the background.

Tip N° 4

Use Examples when needed.

In certain cases we need to repeat the same test with different parameters or configurations. Let’s take a look at the following example from our login feature.
Imagine that we want to test what happens when the user forgets to fill any of the two fields (username or password). We can write two different scenarios (one where the user doesn’t fill the username field and another in which they don’t fill the password field). Here is where ‘examples’ comes in handy.

Scenario Outline: As a user who is not logged in, I want to login but I forget to fill a field leaving it blank.  
    When I introduce <username> in the username field in the login page
    And I introduce <password> in the password field in the login page
    And I click the login button in the login page
    Then I should be in the home page.
Examples:  
| username      |  password     |
| TEST_USER |      blank        |
|       blank        | TEST_PASS |

Pretty simple, isn’t it? What will happen here is that the same scenario will be executed as many times as examples we have, with the parameters we have specified there.

Tip N° 5

Keep your test scenarios as short as you can.

If you want your tests to be useful as documentation, you should keep your scenarios as short as possible, that’s no more than six steps.

Let’s recap what we have for our login feature so far.

Feature: As a user who is not logged in yet, I want to log in to the application.  
    I can log in introducing the correct username and password.
    I cannot log in if I leave the username or password blank.
    I cannot log in if the username/password combination is wrong.
    If I cannot login, there should be a message showing that something went wrong.

Background:  
Given I navigate to the login page

Scenario: As a user who is not logged in, I want to log in providing a correct username and password.  
    When I introduce my correct username in the username field in the login page
    And I introduce my correct password in the password field in the login page
    And I click the login button in the login page
    Then I should be in the home page.

Scenario Outline: As a user who is not logged in, I want to log in but I forget to fill a field, leaving it blank.  
    When I introduce <username> in the username field in the login page
    And I introduce <password> in the password field in the login page
    And I click the login button in the login page
    Then I should be in the home page.
Examples:  
| username  |  password     |
| TEST_USER |  blank        |
|  blank    |  TEST_PASS    |

Conclusion

We’ve seen through this article what cucumber can do for us. If we use this powerful tool properly, we will end up having good documentation and a reliable set of integration tests for our software, and having these two things together is both money and time saving in any project, while improving quality simultaneously.