The feature-rich Robot Framework can assist us in the design and development of mature end-to-end automation solutions, with ease. As the scripts are keyword based, they are readable, which makes it easy for different stakeholders to collaborate in quality engineering of the product.
The characteristics and components of a good automation framework are:
- An appropriate language like Python, Java, etc, to write the tests and create scripts.
Reusable pages or entity objects.
- Supporting libraries that offer the capability to test Web, API, database or mobile applications.
- An abstraction layer that provides users the ability to write test cases in a natural language so that it can also be understood by business analysts.
- A test runner that has selective capabilities like tagging test cases and running them by tags.
- Test suites or test setups and teardown mechanisms that enable us to clean up and also not repeat setup and teardown scripts.
- A key component is well structured reports that have a results summary with aggregation, timestamps, the ability to drill down into the test case to see what was executed, as well as the ability to search results and automatically embedded screenshots if there is a failure.
- The capability to schedule tests daily, weekly or monthly.
- The capability to integrate with a continuous integration system so that the tests can be run automatically after the build and deployment on a server.
- The support for parallel execution so that tests can be run on different computers simultaneously to save time.
- Finally, the need to have some sense of convention to bring about consistency within the team.
Why the Robot Framework?
The simple answer to this question is that the Robot Framework does all of these things, right out of the box, so that we do not require to build test automation frameworks from scratch. What’s even better is that it’s open source and free. It can also be installed, be up and running, and ready to use in no time and with minimal effort. It’s definitely the fastest and easiest test automation framework to learn.
An overview of the Robot Framework libraries
Robot Framework scripts are mostly keyword driven, i.e., we can type in some simple, plain English words to invoke pre-written logic in some pre-existing libraries that have been made available to us. This gives us the ability to create our scripts in a natural language, essentially Business Domain vernacular, and the end result is simpler, more readable test scripts. Figure 2 makes it easier to visualise this. Inside our chosen IDE, we create a script file, which is simply a text file with a dot robot (.robot) extension. These script files reference workflow files, which are lower level keywords, as well as text .robot files. Those workflows themselves make calls to the various libraries. So, we can see the libraries we have access to include built-in libraries that come with the Robot Framework itself, and also external libraries that can be installed by using pip3 install and then the name of the library.
Installation steps on a Mac
- Install Python and PIP (add to your Path)
- Use PIP to install the Robot Framework
- Use PIP to install the Selenium library
- Select and install the desired browser versions
- Install Selenium WebDriver for each browser
- Install the PyCharm IDE and Intellibot plugin
- Create the base directory for the script
1. Install Python and PIP (add to your path) with the following command:
$ brew install python
Homebrew installs PIP pointing to the Homebrew’d Python 3.
2. Use PIP to install the Robot Framework as follows:
$ pip3 install robotframework
3. Use PIP to install the Selenium library:
$ pip3 install robotframework-seleniumlibrary
4. Install Selenium WebDriver for each browser, e.g., install Chrome WebDriver for Chrome:
$ brew cask install chromedriver
5. Install the PyCharm IDE and Intellibot plugin, as follows:
Open Pycharm and Pycharm > Preferences
Select Plugin, and then search and install IntelliBot @SeleniumLibrary Patched.
Organising project files
We can organise our project files by using a layered script approach. As represented in Figure 5, the script file contains test cases – the keywords files contain lower level keywords that are created to help the script do its work, and the page object files are a way to encapsulate locators and functionality to represent different pages in the system under test. So the script falls under a test directory, while the keywords and page objects together fall under resources. If we happen to get into creating our own libraries using Python, we could also consider creating a libraries directory to hold them. If instead, we had multiple products and tests, we could consider an approach by which inside our test directory we have a Product 1 directory, which might hold Feature 1, Feature 2, and so on. This would mean shorter scripts for specific areas of our product. Of course, this assumes a Product 2 directory, a Product 3 directory, and so on. Then, inside the resources directory would be a Product 1 directory and a Product 2 directory, which would hold our corresponding keyword files for Feature 1, Feature 2, and so on — that means a single page objects directory for each product.
The reason for this approach is that we could use one common keywords file for all of the different products.
So, for things like suite setup and suite tear-down, which includes things like opening up the browser, closing browsers and such, if we don’t want to have to repeat those keywords for multiple products, we could have this one common keywords file that serves each of our multiple products. In Results we would have a Product 1
directory and a Product 2 directory, which would hold the results for those products, respectively.
To conclude, here’s a quick view of the Robot Framework’s features:
- Simple tabular syntax
- Built-in keywords from the Selenium library (open browser, close browser, maximise browser, etc) and also user defined keywords
- Supports a lot of external libraries like Selenium library, database library, FTP library and HTTP library
- Possible to write test cases that work across platforms
- Data-driven test cases
- Separate test data editor
- Clear reports
- Detailed logs
- Generic test libraries
- Support for parallel execution of test scripts
- Text editor support: Eclipse, Emacs, Vim, Visual Studio code
This framework can be containerised and integrated with a CI tool like Jenkins.