https://twitter.com/adrian_yorke/status/1420168659729854466?s=20

This blog describes how I explored the Robot Framework CookBook open source project, which is a curated list of delicious Robot Framework recipes that will help you develop new test automation scripts faster created by Adrian Yorke with other contributors.
In the different sections, I will mention my general finding with a focus on what is more useful from my perspective and also what’s accessible from my local machine 🙂 some sections are skipped as the test aren’t .robot format.

Section 01: Logging and Looping

Starting with the basics, in this section we will explore different ways of logging and looping

Log Variables: Logs all variables in the current scope with given log level.

  • I wonder how the output is ordered ? I supposed by the order of variables but it seems there is another strategy.
  • I was expecting only variables to be printed

Back to the log with option console activated allow you to have the output displayed in the console, but when using Log To Console, we can’t find a displayed output in the log file.

  • Log Hello ${name}!    console=yes
  • Log To Console    Hello World again, this time only output to the console.

For loops, I don’t have a special comment to add. There are 3 recipes to use loops

  • Exit For Loop If: Stops executing the enclosing for loop if the condition is true.

The only comment I have, can we organize the console so that we fill the whole sentense without cutting the documentation and adding an extraline before starting the loop output

Section 02: Lists

All the recipes in this section use collection which is a test library providing keywords for handling lists and dictionaries (+ BuiltIn default one)

Create List Returns a list containing given items.

In the first test suite, we saw the creation of lists and the difference between $ and @ 

*** Test Cases ***
Log Lists

   ${a} =    Create List    a
   @{bc} =    Set Variable    b    c
   Log ABC    ${a}    @{bc}

*** Keywords ***
Log ABC
   [Arguments]    ${a}    @{bc}
   Log   ${a}
   Log   ${bc}[0]
   Log   ${bc}[1]

Testing list of numbers and letters are simple recipes that allows you to create lists then manipulate them (adding new values to the list using Append To List, sorting them using Sort List, deleting values from the list using Remove Values From List    ${letters}    a    c)

There is also “Dictionary Testing” test case that tests the creating, the update of dictionaries and the assetion of what the dictionary contains from values or keys side (Dictionary Should Contain Value, Dictionary Should Not Contain Key)

I learned this new command Pop From Dictionary it pops the given key from the dictionary and returns its value.

Section 03: Handling Dates

When dealing with time in robot framework use the library DateTime

we can set the display of format by simply adding

  • result_format=verbose
    The verbose format uses long specifiers day, hour, minute, second and millisecond, and adds s at the end when needed

And there are 2 test cases that shows how to manipulate time, days and years.

Section 04: Working with File System

In those tests, OperatingSystem is the test library used, its role is to provide keywords for OS related tasks. It enables various operating system related tasks to be performed in the system where Robot Framework is running.

as an example List Directory returns and logs items in a directory, optionally filtered with pattern.

Section 07: String Manipulation

This recipe deals with strings, for that we use String as standard library for manipulating strings and verifying their contents.
As an example the below test replace the name “Nigel” with “Rubeus” then split it into characters using Split String To Characters

Section 9: Requests and REST

In this section, recipes are a bit different, let’s say it’s also intermediate level working with RequestsLibrary that aims to provide HTTP api testing functionalities by wrapping the well known Python Requests Library.

When I run the test, a warning message is displayed, but the test is passed. I discovered that the keyword need to be updated as the RequestLibrary has changed, which shows how dynamic is the robot community!

Although it’s very simple, but I’m happy with my very first pull request into an open source project !

I changed it, and let’s now investigate into the test details

It aims to create a HTTP session on Git then sends a GET request on this Session, then check if the status code is =200 and check also if the response contains the exact values we expect.

In this section, I wanted to add more exploration as I liked the library and it’s very new to me.

  • I added a suite setup to avoid the warn we got:

Multiple test cases with name 'Get Request' executed in test suite 'Recipe091 Working With Requests Library'.

So that we create the session only one time and we use it in all the test suite via our test cases.

  • I added also verify=true as we have confidence in the request and adding certificate is strongly advised

c:\users\emna ayadi\appdata\local\programs\python\python39\lib\site-packages\urllib3\connectionpool.py:1013: InsecureRequestWarning: Unverified HTTPS request is being made to host 'api.github.com'. Adding certificate verification is strongly advised.

Another suite same section contains a recipe, made using REST library It guides you to write more stable API tests relying on constraints (e.g. “people’s email addresses must be valid”), rather than on values having the nature of change (e.g “the first created user’s email is expected to stay foo@bar.com”).


Example of keywords that we can use:

  • GET: Sends a GET request to the endpoint.
  • Delete: Sends a DELETE request to the endpoint.
  • PUT: Sends a PUT request to the endpoint.
  • POST: Sends a POST request to the endpoint.

I’m quite surprised as String has another meaning here, and it asserts the field as JSON string.

  • Output: Outputs JSON to terminal or a file.

Section 10: Dealing with Databases

This is actually interesting and a good reminder for me as I didn’t use this kind of database from my last year at university. So let’s check if I still have good memory

We used the DatabaseLibrary combined with OperatingSystem in this suite of tests

  • The first test aims to check if there is a data base and remove.
  • The second used the keyword Connect To Database Using Custom Params
  • The third contains SQL, this is a very familiar table to what I know before

It allows the creation of the database and setting it to a known state before running your tests, or clearing out your test data after running each a test.

  • The forth checks if the table exists Table Must Exist    user this simple check could be added to the third test instead.
  • The fifth ${output} =    Execute SQL String    INSERT INTO user VALUES(2, 'Charles', 'Babbage'); It’s quite similar to the earlier ones but we used keyword INSERT instead of CREATE
  • The sixth test Row Count Is Equal To X    SELECT * FROM user;    2

Section 11: Remote Machine via SSH

The tests in this suite aims to execute commands on a remote machine via SSH and get the output and return code.

This recipe could be used to implement “configuration management as code” and configure multiple remote servers.

install the external dependency

  • $ pip install --upgrade robotframework-sshlibrary
  • More about SSHLibrary documentation

Section 12: Running Tests in Parallel

This session is exciting, as I didn’t get the chance before to run this kind of parallel tests, I’m mostly used to UI testing before, so let’s go deeper.

The External Library that we used here is pabot.

https://twitter.com/emna__ayadi/status/1423303296039669763?s=20

Section 13: Selenium

This recipe demonstrates using keywords from SeleniumLibrary and SeleniumTestability plugin, how to setup webdrivers and use advanced features of SeleniumTestability

Section 14: AWS

This recipe demonstrates:

  • using a Suite Teardown to end the test suite cleanly
  • using keywords from an external library               
  • accessing OS Environment Variables directly using %{} syntax

Conclusion & recommendations to add more recipes

  • Is it clear how to use the project?

Yes, It’s clear with the documentation at the beginning of every test suite and the steps that need to be done.

Note: I didn’t run files ending with .gitkeep in section 5 as they are not .robot

why we have such files ? the only purpose is to allow pushing empty folders to git.  Git doesn’t normally permit empty folders as it’s a file based version control system but by creating this special file it forces git to show the empty folder.  This file is named .gitkeep by convention, although ANY filename would have the same effect.

  • Are the existing recipes useful?

I’d say it depends on what you want to achieve with your automated tests and what level you want to cover?

What I like the most is that they cover different recipes with various libraries that we might don’t know they exist.

So we can find new ways of solving problems in more efficient way.

  • Which recipes need more work?

Section09: I recommend dealing more with API which allows us to test API from robot framework

Here’s what I found that we can use it in this kind of recipe

Section13: I recommend adding more recipes using selenium library

  • Do you have any ideas for additional recipes or sections?

I recommend representing the most used design patterns in separate sections, to experiment the test automation project structure using Robot Framework

  • Other ideas/thoughts/suggestions?

Using BDD in a separate section and copy one of the section, then write the same test using
Given
When
Then
to show the importance of BDD and how it makes understanding the tests from non-technical involved stakeholders easier

It’s been an interesting exploration with discovery of different libraries, one of them are new to me.

Thank you Adrian Yorke for the opportunity exploring an open source project.