Technical Thursday
Robot Framework
04
Jun
Posted by: Eva
Category:
Business, Test automation
No Comments
What is Robot Framework
Robot Framework is a generic test automation framework. It uses a keyword-driven syntax to create test scripts with this easy to interpret syntax, the scripts are very easy to read even by less-technical people.
On the surface due to the human readable nature of the keywords, Robot Framework looks a lot like Cucumber, however Robot Framework offers so much more to test engineers. Robot Framework moves beyond just providing fixtures to bind keywords to actual code. Robot Framework is a programming language on itself. This means that we can provide logic to test scripts.
As with any test framework, Robot Framework uses an underlying core framework to bind the test scripts to actual actions. The core framework can be written in either Java, Python or .NET or even in Robot Framework itself, making Robot Framework fully OS independent. Using Java, Python or .NET can help to fit test automation within your development technology stack. When you write the core framework in Robot Framework, since it’s completely open source, you can use thousands of libraries to help you. Robot Framework has a very active community which is evergrowing, so there’s a pretty good chance that the specific library you need, already exists. Even if the library does not exist yet, you can always use for example a Python library, bind it to Robot Framework and use the library anyway.
Why would you use Robot Framework
As mentioned before, Robot Framework uses a very easy to read syntax to create test scripts. Even less experienced or less technical people can therefor use Robot Framework to write test scripts. Tech-savvy engineers can build and maintain the framework while your junior profiles, analysts or even the project manager can write the tests.
Robot Framework offers a great deal of flexibility and can either use the pure keyword driven syntax, or it can be used as a behaviour driven framework. Other behaviour driven tooling such as Cucumber are more collaboration tools rather than a framework. While Cucumber is the easiest to learn and the less technical of the two, Robot Framework offers the user the use of logic and variables which causes a higher learning curve, but makes this up by being much less rigid than Cucumber.
When executing a robot file, the tests written in the file are ran and both a report and a log are generated. The report gives a quick impression which test cases failed and why, while the log gives you a detailed overview of what’s going on. The logs will give you information on every line of code which is executed and it’s pretty detailed on this. Other than the log and report, Robot Framework will also output an XML file which can be parsed to create your own custom report.
Benefits and drawbacks (from several user standpoints)
As with any tool, Robot Framework offers several benefits, but also has some drawbacks. Let’s dive into this from several user standpoints. For the purpose of this blog, we’ll be looking at the out of the box character of Robot Framework. Many drawbacks in any tool can be solved or mitigated with the use of custom components, but this would defeat the purpose of this blog.
👨🏻‍💼, businesspeople such as project managers & product owners
Let’s start with businesspeople such as project managers, product owners… For them Robot Framework can be a much bigger hurdle than for example Cucumber. But as mentioned before, Robot Framework can offer the use of traditional behaviour driven keywords out of the box, making it on par with Cucumber. Robot Framework also offers two IDEs called RIDE and RED which are created for non-technical users, making them easy to handle. Debugging the test cases, could prove tricky for the average user. Since there is so much information logged, Robot Framework can bury relevant information beneath all other information. This makes debugging harder for the untrained eye.
Robot Framework offers several benefits, but also has some drawbacks. Let’s dive into this from several user standpoints.
👨🏻‍💻, Developers
Next up are developers. Robot Framework is basically a programming language. This causes Robot Framework to be much closer to their day-to-day tasks than for example Cucumber. However, while Robot Framework has the ability to provide some logic, many developers will struggle because of certain restraints of Robot Framework. For example, Robot Framework does not support nested loops. There are ways to overcome these constraints but overcoming things which are often seen as basic functionality, tends to cause some frustration. In any case, the developers can always revert to Python, Java or .NET to develop the framework and let the less-technical people work with Robot Framework bound to their code.
🕵🏻‍♂️, Test engineer
Lastly let’s discuss Robot Framework from the point of view of a test engineer. Test engineers are given easy to read test cases making the learning curve of the project less steep. Not only are the test cases easier to read, but the underlying framework, if it’s written in Robot Framework is also easy to read and debug. This makes fixing issues within the test automation framework rather easy.
Pitfalls and bad practices
Any tool has pitfalls and Robot Framework certainly is no exception to this. In this section you’ll find some pitfalls that I’ve come across during the years I’ve spent with Robot Framework.
You’ll find some pitfalls that I’ve come across during the years I’ve spent with Robot Framework.
The forgotten abstraction-rule
First of all, Robot Framework is a programming language thus follows the same generic rules as any programming language. One of the rules which is often forgotten is abstraction. Encapsulating behaviour and decoupling elements is one of the key rules in software design. Like any piece of software, a test automation framework written in Robot Framework needs some refactoring from time to time. A framework with enough abstraction layers makes it much easier to refactor or extend certain functionalities. Abstraction layers also makes a code much more readable to everyone as the script will communicate behaviour rather than implementation.
The infamous keyword pollution
Another common issue which I’ve come across is the infamous keyword pollution. Keyword pollution occurs when there are many different keywords which all perform the same task. Someone designs a test case with a new keyword, without knowing which keywords are already available. A test automation engineer picks this up and sees that the keyword does not yet exist and proceeds to bind actions to this keyword, without first checking whether a similar keyword already exists. It is therefore imperative that there’s sufficient maintenance on the framework to remove similar keywords and to perform a thorough analysis before just binding a new keyword to actions.
The use of “Sleep”
Other than pitfalls I also want to address some bad practices which are often used. One of them is the use of “Sleep”. The Sleep keyword is commonly used to synchronize tests with the test object. Usually executing code is much faster than a test object can react, so test engineers tend to use “Sleep” to synchronize both of them. A much better way is to build in a “wait”. While Sleep pauses the test from continuing a set amount of time, a wait will only pause the test as long as needed. We’re often only talking seconds here, but this is one of the biggest increases in test automation framework performance.
The lack of visible validation in test scripts
Another bad practice is the lack of visible validation in test scripts. I see this often in frameworks when reading a test script, the validations which are being done are not visible in the test script. A prime example of this is when you’re testing web services. In this case a keyword performing a REST request is written and it will already validate the request on a “200 OK” status code. A better way of approaching this, would be for the keyword to just perform the REST request and return the status code along with the message. You can then put the validation of your status code in your test script, instead of within the keyword. This way, it’s immediately clear for a test engineer which validations are being checked during this test script.
Conclusion
Robot Framework is a very powerful and versatile test tool for test automation. It has some very nice out of the box features which can get you very far. If you’re still lacking functionality or libraries, you can easily import custom libraries or create your own libraries using Java, Python or .NET. Getting started in Robot Framework and setting up a full e2e framework can be tricky at first, but the rewards will be plentiful. Brightest is offering a training course on Robot Framework which can get you on the right path towards mastering Robot Framework. Want more help? Our team of professionals is always happy to take a look at your current QA process and assess possibilities to enhance the process and take it to the next level.
Written by: Sepp Van Cauwenbergh
