Skip to main content

Everyone in the field of test automation is familiar with Robot Framework and Selenium. They are the two leading automation frameworks that developers and testers use to build test harnesses that automate the testing of another application.

So what are the future applications of these frameworks, and how will they shape the evolution of technology and web applications? In this article, I’ll explore the similarities and differences between Robot Framework and Selenium, keyword automation, and other expert insights.

The similarities between Robot Framework and Selenium

Both frameworks are proven technologies, with Selenium existing for over two decades and Robot Framework approaching 20 years. 

Both are open source and with user bases in the hundreds of thousands (if not millions). However, neither is a tool in the strictest meaning of the word; they are frameworks you use to build the tool for your specific testing purpose. 

Robot Framework and Selenium are widely used for testing web applications. In fact, Selenium was built explicitly for this purpose, while Robot Framework was designed for automating almost anything. Robot Framework is known to be used even for testing time-sensitive signaling systems.

Both frameworks are accessible from various programming languages—Selenium has a historical association with Java and C++, while Robot Framework primarily associates with Python.

Discover what’s new in the QA world.

Discover what’s new in the QA world.

  • No spam, just quality content. Your inbox is safe with us. For more details, review our Privacy Policy. We're protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
  • This field is for validation purposes and should be left unchanged.

The differences between Robot Framework and Selenium

A test automation framework operates between the tester and the application under test. It provides a scripting interface (“upper test interface”) for describing the tests to the framework and a driver interface (“lower test interface”) to command the application under test, simulating the user’s actions. The main task of the framework is thus to translate the commands of the test script in the upper interface to the points, clicks, and keystrokes in the lower interface.

Selenium initially established the standard for the lower interface in web applications testing: a consistent model for addressing web page elements using a locator format known as XPath. The upper interface of Selenium is just a thin programming library to work with the XPaths, which requires strong programming skills. In addition, all Selenium users know that XPaths tend to change, and tests require continuous, time-consuming, and expensive maintenance.

Robot Framework was born out of frustration with cumbersome automation tools, Selenium among them. The design goal was to build a generic automation framework that can extend with custom libraries that implement different test interfaces. The concept was inspired by keyword-based automation, pioneered by Hans Buwalda and Behavior-Drive Development (BDD). 

What is keyword-based automation in Robot Framework?

Keyword-based automation is the process of programming high-level commands such as Login, EnterLead, CreateContact, etc., that carry out the typical actions a tester or real user would. The keywords hide the dirty details of XPaths and other technicalities. The test designers would then use the keywords to define the actual tests. If something changes in the implementation of the underlying application, one only needs to modify the definition of the keywords, and all tests using the keyword would work again.

Considerations of keyword-based automation

Keyword-based automation does come with a caveat. A lot of consideration must be put on defining the keyword vocabulary to avoid the proliferation of keywords. If you apply BDD, the proliferation of keywords is almost guaranteed. If the keyword vocabulary is application-specific, using Robot Framework to design tests for one application does not imply proficiency in designing tests for another. 

And, just like with Selenium, the developers maintaining those keyword implementations tend to become bottlenecks of the process. The volatile XPaths that need maintenance may be far fewer than with Selenium, but they still exist.

Benefits of keyword-based automation and wide libraries

The extensibility of Robot Framework has enabled the community to create plenty of useful keyword libraries. For example, there are at least three unique web automation libraries: SeleniumLibrary, QWeb, and BrowserLibrary.  The Robot Framework SeleniumLibrary was built on Selenium but on a higher level of abstraction than Selenium itself. The community hosts a myriad of libraries for various other purposes, such as API testing or test data generation. 

If you are a professional programmer, you can accomplish any web automation task with Selenium, but you need to complete the task all by yourself. Robot Framework provides the same level of flexibility, but with a vast number of useful libraries that can make your job more productive.

The well-thought model for extensibility is one of the considerable strengths of Robot Framework. For example, you can create new keyword libraries by programming them in Python or another language of your choice, or you can simply sequence existing keywords, even with basic control structures, to create new ones.

A no-code note

If you are not a professional programmer, you’ll be helpless with Selenium and, to be honest, almost helpless with Robot Framework. You cannot comprehend much about a Selenium script, but if you see a Robot Framework test script, you can probably, but not always, follow its logic and understand what it is supposed to do. If you have good examples to copy and improve, you will even be able to create Robot Framework scripts yourself.

Many test leads estimate that working with Robot Framework is more productive than working with Selenium, thanks to its higher level of abstraction and ready-made libraries that reduce both the cost of automation and particularly the cost of test maintenance. It’s common to see four-to-eight-fold productivity gains over Selenium are common. 

On the other hand, if you know what you are doing, you can undoubtedly get it done with Selenium: the pain of having to do almost everything yourself carries the liberty of being able to do anything by yourself.

By Esko Hannula

Esko Hannula is VP Product Line Management at Copado, a DevOps and testing solution for low code SaaS platforms that run the world’s largest digital transformations. Backed by Insight Partners, Salesforce Ventures and SoftBank Vision Fund, Copado accelerates multi-cloud, enterprise deployments by automating the end-to-end software delivery process to maximize customers’ return on their cloud investment.