Posted onFeb 12, 2023

Gherkin and Robot Framework

#testing #gherkin #robotframework #python

Greetings! They say all good things must come to an end, and with this post, so it is with my series of posts coveringRobot Framework.

This post builds on what was covered in previous posts. If you haven't checked out theother posts in the series, please do.

Robot Framework and Gherkin

In the last post we built a Robot test to validate some functionality of the ToDo app. The test accessed the ToDo page, added a ToDo, and verified it was successfully added. (The repo for the app and the tests can be foundhere).

This is what our current Robot test looks like:

***TestCase***AddanewToDoitemOpenBrowser${URL}${BROWSER}PageShouldNotContainElement//section[@class='main']Inputtextclass:new-todoFinishThisBlogPostPressKeysclass:new-todoRETURNPageShouldContainElement//section[@class='main']${actual_count}=SeleniumLibrary.GetElementCount//ul[@class='todo-list']/li${expected_count_number}=ConvertToNumber1ShouldBeEqual${expected_count_number}${actual_count}

There are at least a couple issues with this test:

Page locators are not reusable. Following this pattern, if I wanted to create another test (or 100 tests) that needs the count of ToDo items, I would probably just copy/paste that locator,//ul[@class='todo-list']/li every time I needed it. A better strategy would be to define the locator in a single place. If the locator ever needs to change, I have one place to go to make my update.
To my eyes, the test is hard to read. This is a pretty basic test, but It's not super clear what's going on. Also, this pattern requires knowledge of the Robot syntax. Product owners and BAs are not going to be interested in reading this, and probably no one else will be either.

Let's address these 2 issues.

As a reminder, this is what that test is actually doing:

- open the ToDo page- verify there are no ToDos- add a ToDo- verify the ToDo text matches what was added- verify there is 1 ToDo

I want my test to look a lot like this, without all the implementation details in my way.

Gherkin and Robot Framework

In the real world, the above is a good example of an acceptance test. It defines some basic functionality and describes how the application should react. Automating the testing of the requirements is useful as a component ofAcceptance Test Driven Development (ATDD). I usually see this go hand-in-hand withBDD and the gherkin syntax. In that example our gherkin-syntax test could look something like this:

Whenthe User accesses the Home pageThenthe ToDo count is  0Whenthe user enters new ToDo  learn RobotThenthe ToDo item is added to the to the list  learn Robot  1Andthe ToDo count is  1

So how does Robot Framework facilitate our ability to write tests like this?

First of all, remember Robot is a keyword-driven framework. The first line of our testWhen the User accesses the Home page is just a keyword to Robot. As discussed inprevious posts, we can easily hide the implementation details of this keyword in a Robot resource file. Defining this keyword in a resource file could be as simple as:

***Keywords***theUseraccessestheHomepageOpenBrowserhttp://localhost:8888chrome

Here I have created a custom keywordthe User accesses the Home page, which uses the built-in keywordOpen Browser. Note that my custom keyword does NOT begin with the wordWhen. That's because if no match is found for the full keyword, Robot will ignore the prefixes "Given", "When", "Then", "And", "But" . This allows Robot to easily facilitate our ability to build tests using the Gherkin syntax.

Also, since we can pass parameters with Robot keywords, we're doing that with the stepWhen the user enters new ToDo learn Robot. We are passing the text of the ToDo, "learn robot". The implementation of that step in the resource file can look something like this:

***Keywords***theUserentersnewToDo[Arguments]${todo_to_enter}Inputtextclass:new-todo${todo_to_enter}PressKeysclass:new-todoRETURN

The full resource file, including other examples, can be foundhere, with the gherkin testhere.

To run these tests, just be sure to first start the app locally (npm start). If you can't open the app manually, the Robot test won't be able to either.

Wrap-up

So that's it. We had 2 goals for cleaning up that test:

facilitate reuse
make it readable

With reusable and parameterized gherkin steps, I feel we've accomplished our goal:

Whenthe User accesses the Home pageThenthe ToDo count is  0Whenthe user enters new ToDo  learn RobotThenthe ToDo item is added to the to the list  learn Robot  1Andthe ToDo count is  1

I hope this series of posts has helped someone learn more about Robot Framework. Of course I have barely scratched the surface, and the links below should help you continue your Robot journey!