Robot Framework is Python-based and a versatile open-source generic automation framework used for automated software testing, robotic process automation, acceptance testing, and acceptance test-driven development.
As a keyword-driven framework, it can integrate into behavior-driven development allowing you to use user stories in full sentences. These user stories or keywords are then used as an abstraction which connects to test automation scripts. Apart from many other integrations, it enables test engineers to also use Selenium. Selenium is an industry standard tool for scripting user-based web browser interactions and to automate user behavior for any website.
The framework can be used for user interface and application program interface testing. For example, our product at Humanitec has integrated with a number of third party APIs. Therefore, we needed to be able to handle those APIs in a reliable way. The majority of our testing is based on API requests, and it can be tested in combination with the Robot Framework and other libraries.
A test case in this framework is agnostic of any programming language. The keywords can resemble English sentences instead of a traditional programming language, and it can be facilitated in Behavior Driven Development (BDD) via the Gherkin Syntax (Given-When-Then-Syntax). This means that the writer of a test doesn’t have to be a programmer making it possible for testers or other non-developers to write and then later maintain tests.
In this blog post, we highlight six reasons to use the Robot Framework.
The right test framework for you
Reason #1 — Good support
Building test automation can be tough, so having access to supportive communities is important. There are several examples of good support for the Robot Framework:
Stackoverflow — This site is active and has 4,446 questions as of the time of this writing (February 2020). This is a great place for test engineers to get their questions answered.
GitHub — GitHub contains 260 public repositories on the topic.
Another option is to join one of the 26 meetup groups spread out over 12 countries with overall 2,825 members.
Finally, a good example of support is the annual convention RoboCon that occurs every year in Helsinki. In 2019, there were over 300 visitors. RoboCon 2020 was on January 14th through the 17th and featured workshops, RoboCon conference as well as open-source development sprints. All previous talks are available on their website: https://robocon.io/#previous-talks
Reason #2 — Well-maintained and open-source
The Robot Framework is completely open-source, and all additional libraries are provided by the community. For example, on GitHub.com there have been, as of the time of this writing, more than 12,000 commits from 101 contributors.
Reason #3 — Many integrations
Due to the active community as well as the ease to extend the Robot Framework, there are many libraries for different testing purposes. Some examples of these integrations include:
- Database Library for any database related testing. This library will allow developers to query a database as an action and then verify the results.
- Appium Library for automated UI testing on mobile devices to communicate with Apple and Android applications.
- Requests Library for API testing. This is a test library that makes use of the Requests HTTP client.
In case additional libraries are needed, here is a list of libraries on the Python Package Index.
Reason #4 — Good documentation
Having comprehensive documentation makes it easier to work with any tool. The Robot Framework is no exception, and has great documentation on their website. This site includes Getting Started instructions, Demos, Videos, and Online Courses, and there is also a Robot Framework User Guide for new users.
In addition, it provides great tooling for auto-generating well-structured documentation for any extension library anyone could build. This provides a nice consistency to the quality of documentation for all community-driven libraries.
Reason #5 — Python extendable
Some testers might wonder, since there are already so many libraries, why would they need to extend the Robot Framework? Here are two reasons why you would want to extend the Robot Framework using Python:
- The need for specific custom keywords. This is used when a certain type of functionality is missing. For example, test engineers might have an internal API or CLI tools they need to script for testing. Wrapping the functionality as Robot Framework custom keywords will make it available in their test suite.
- Wrapping functionality into custom keywords that shouldn’t be individually asserted in their testing (i.e. seed data, clean up tasks, external APIs, etc.)
For example, if test engineers need specific test data in their database, they can build a keyword to write that data to their database before the actual test is starting.
It’s also worth mentioning that any programming language can be used for implementing keywords. Python has bindings to interact with C and C++ APIs via ctypes and pybind11 and there is also pythonnet on Windows to interact with C# code. Considering the availability of many other Python remote libraries, the sky’s the limit for languages that can be used for integrations.
Reason #6 — All-in-one test reporting
After each test run, the Robot Framework provides a clear, concise, and human-readable HTML-test report. These reports are based on XML outputs from the tests. As an all-in-one reporting, it also helps when presenting to other stakeholders within an organization.
When keywords are written in Gherkin syntax, the test report will clearly show;
- the purpose of the test,
- what it is verifying, and
- all other available details.
The generated test reports can be easily understood by developers, testers, product owners, and product managers. For example, this is a test report of a login test:
Example of a Robot Framework login test report
In this test, the login of a user to a desktop web application was automatically performed. The final validation is that after the successful login the dashboard page of the application is shown.
Next, we’ll explore how user stories can use this type of informal, natural language and also be used in your software development.
Re-using user stories as test definitions throughout the software development life cycle
User stories make end users the focus of the conversation, and they use non-technical language and typically contain only a few sentences that do not go into detail. User stories can also include acceptance criteria within the document.
This, in turn, is given to developers and the developers know exactly what needs to be implemented. A QA Engineer can turn those user stories and acceptance criteria into test scripts by copying them into their Robot Framework test suite and then attaching test code to it. This allows product owners, etc. to define tests while the developer is building the code. Once the developer finishes, there’s already a test developed that they can validate the implementation against. This speeds up the process.
Keyword documentation can be generated from the Robot Framework test suite. It allows organizations to have a catalog of all of the user stories already covered by test automation. If a product manager writes a new story, then he or she can copy and paste some of the phrases which are already covered in other stories. As a result, the test engineer might not need to create more test automation because those phrases have already been covered.
Building test automation is a lot of work, and its performance is best when supported by a sophisticated test framework like the Robot Framework. The key elements of this framework are having reliable support, comprehensive documentation, well-maintained open-source code, plenty of integrations, and the ability to extend the framework easily. Ultimately, this framework unlocks the possibility to build test automation setups which will enrich any quality-focused software development.
Originally published at https://humanitec.com.