Robot Framework Tutorial
Part I: Robot Framework Tutorial – Overview
Part II: Robot Framework – A complete example
Part III: Robot Framework IDE
Part IV: How to Structure a Scalable And Maintainable Acceptance Test Suite
Part V: Robot Framework Tutorial – Writing Keyword Libraries in Java
Part VI: Robot Framework Tutorial – Loops, Conditional Execution and more
Part VII: Robot Framework – Testing Windows Applications
Appendix A: Robot Framework – Compact Sheet
The new Robot Framework Tutorial 2016 series
The Robot Framework is a generic test automation framework. This is the first article – in what is planned to be a series of articles – to provide a comprehensive overview on the Robot Framework. You can find already now a whole bunch of articles related to the Robot Framework in this blog , but those are more like a loose-leaf collection. This series should give a more structured view on the whole topic and will at the same time include some of the already existing articles to draw the bigger picture.
Please note that this first article does hardly contain any “real implementation stuff”, but is more a high-level overview of the used concepts to have a solid foundation for the forthcoming articles.
What is a test-automation framework?
If you have already some experience in test-automation (e.g. from using some other test automation tools) you can probably safely skip this section.
Otherwise I would like to start with a short side track about the questions: What is an automated test? And how does it differ from a manually executed test? The following article by Michael Bolton gives a very good answer to these questions that can be condensed to the the following quote :
Checks Are Machine-Decidable; Tests Require Sapience
Please note that we will nevertheless use both terms – tests and checks – when talking about automated tests in the following.
Let’s take a look at some concrete example like a rating engine for some insurance company. This is calculating some values based on certain input parameters (numbers). This is obviously a good example where a lot of (automated and probably meaningful) checks can be implemented when the algorithm for the calculation is known. Whether or not this algorithm as such is correct requires obviously some sapience.
Let’s assume we have an interface based on some database tables and a batch program: Put values to one table, execute the calculation and check results from a different table.
Now we need some basic testscript that we can start (depending on ones preferences this could be implemented in Shell, Perl, Java or whatever). In addition we need some basic test-functionality to start with. Accessing the database tables, executing another script, returning the results preferrably as some kind of report. Once this is done we can start implementing our checks as such. Basically we have now already named those parts that should be typically provided by a test-automation framework.
Minimal Test Framework Design
The figure above depicts a very basic test-automation framework. You have a core system that can execute the tests, can do some reporting and has an interface that allows you to plug-in your specific test functionality. This plugging can then hopefully be done as easily as possible.
Of course this leads to a basic question: In which programming languages can I implement my test-functionality when using a specific test framework? We will answer this question later in more detail, but for the moment we can say that the architecture of the Robot Framework enables the user to use a lot of different programming languages here.
Before we can proceed to the concrete architecture of the Robot Framework we have to discuss a central term related to the Robot Framework, namely keyword-driven testing.
What means keyword-driven testing?
Whenever I try to explain what a keyword is, I refer to it as a function or method that can be used to test (or help test) one (smaller or bigger) aspect of the SuT (“System under Test”, that is how we call the tested system to be a bit more cool ;-)).
The really cool – and really powerful – thing about this now is that one keyword can be defined from other keywords and so on. That is why we are often talking of:
- Higher-level keywords: Those are really testing a concrete aspect of the business logic of the system under test.
- Lower-level keywords: To keep the implementation of the higher-level keywords at a decent size one is often breaking down the required functionality to several lower-level keywords.
- Technical keywords: Those provide the technical implementation to access and thus test the system.
The following figure depicts this based on an example keyword.
Nested Keyword Definition
Typically technical keywords are written in any programming language (ok, not really any). The other keywords are then written as a combination of already existing keywords. Even though in this article we are more on the abstract part of the world, let’s have a look at a concrete definition of some keyword:
Keyword GoogleSearch
This shows the definition of a keyword for a Google Search using keywords from the Selenium Library. This leads us to the fact that there are already a lot of predefined keywords defined in so called Test Libraries. And this basically leads to …
… the promised overview
Finally here comes the promised overview on the Robot Framework. When you install the Robot Framework you get the core framework and a set of Standard Test Libraries that are bundled with the core installation.
In addition to the Standard Test Libraries there are a lot of additional external Test Libraries available. Those are often contributed by the Robot Framework community and serve different purposes. The very good thing on all this libraries is that you can mix all the keywords from all the different libraries together in defining your own keywords or when writing a specific testcase. Thus you can for example easily write tests for a web application using keywords from the Selenium Library to remote control the web frontend and use at the same time the Database Library to check results of certain operations from the database. In an ideal case all this can be done without a need to do any “real coding”, but by combining existing keywords from existing libraries to high-level keywords.
Robot Framework Overview
In addition to the core functionality and the Test Libraries the Robot Framework provides a graphical user interface called RIDE (Robot Integrated Development Environment) that can help a lot in writing and managing testcases and keywords written in Resource Files. Please note that this has nothing to do with writing technical keywords in your own Test Library. This is entirely done in the development environment of your choice, e.g. Eclipse when using Java as a programming language.
Now there is one item in the above figure that we have not yet covered: Resource Files. Our testcases are bundled in so called Testsuites, which makes perfect sense. Now it would be possible to add new (higher-level) keywords into those Testsuites as well. But it is much better to have them defined in some external file and that file is then called a Resource File.
Finally this means that we have three artefacts that must/can be developed when writing tests using the Robot Framework.
- Testsuites: This is where testcases (checks) are implemented. Typically every project will at least have one Testsuite. In bigger projects it makes for sure sense to divide the test functionality further into different Testsuites.
- Resource Files: As it makes much sense from a test-design point of view one will almost always define own higher-level keywords. In turn this means that one will typically have own Resource Files. Especially in product development or in some long-running projects it makes sense to implement certain keywords centrally that fit to the product/project very well and can then be used by all teams.
- Test Library: Typically you are not required to write new technical keywords – for which you would need to implement a new Test Library – unless you are using a very specific technology. Nevertheless this is possible and does not always neccessarily mean a lot of effort.
It must be emphasised that when using a keyword it does not make any difference whether this has been written natively in a Test Library or has been defined as a combination of existing keywords in some Resource File.
In which languages can I implement my test functionality?
The Robot Framework itself and its Core Libraries are written in Python . Therefore this is definitly a good choice for writing own keywords if you are familiar with Python (or you would like to start getting familiar with it ;)). I guess Python is a cool programming language, but if the Robot Framework would be limited to it I personally doubt it would be that successful. This is where Jython comes into the picture. With Jython it is possible to run Python code in a Java Virtual Machine. This enables us to use Java for writing own Test Libraries or basically any programming language that is compiling to Java Byte Code.
Using IronPython you get a similar integration into the .NET world that you get into the Java world when using Jython. Due to my complete lack of knowledge and thus practical experience regarding this .NET integration it will not be looked into any further in the following. Just be aware that this exists :).
This leads to the following possible installation stacks:
Robot Framework - Installation Stacks
The Robot Framework is historically coming from the installation stack shown on the left-hand side (without RIDE) of the above figure. In the early days the Jython-installation and -support was a little bit notchy. Nevertheless this works very well nowadays and – if the Java-support is needed – there is no problem in using this stack. They both have the slight disadvantage that (a lot of) installation work is required on each PC.
This leads to the JAR installation of the Robot Framework. In this one the Robot Framework as such, required Python Test Libraries (the Java ones can be added via the classpath) and Jython is bundled into one big JAR-file. This has the big advantage that you can either check this JAR into source control or you can make it availabe via some lokal Maven repository. This way it can be ensured that all team members are always working with the same version of the Robot Framework and also installations and updates are very easy this way. But as usual there is of course also here some “but”: This way RIDE cannot find and show help for those keywords only available from within the JAR-file. Of course RIDE still needs to be installed seperately.
Ok, but now back to the topic which was: In which programming language can I implement my test functionlity. We have already covered this topic to a good extend, but there is one more possibility that must be addressed here. And as it would fit to different topics it gets a topic of its own.
Remote Libraries
So far we have looked at a local – or server – installation of the Robot Framework where all parts have been installated to the same machine. Then we have seen different possibilities in starting the Robot Framework using Python, Jython or pure Java.
Remote Libraries enable us to write Test Libraries in basically any programming language supporting the XML-RPC protocol and running them on different machines (than the one running the Robot Framework as such) if required.
Remote Library Usage
The usage of Remote Libraries does no differ from using “normal” Test Libraries beside the way they are imported in Test Cases and/or Resource Files. Another big advantage here is that RIDE also fully supports this feature and is able to retrieve the documentation from Remote Libraries as well. If you would like to try out (or have a look at the source) of a Remote Library implementation you can check out the Database Library . Probably this must not be noted, but just to be sure: Of course the Remote Library functionality is an add-on that certain Test Libraries offer.
Remote Libraries are started as a remote server and the Robot Framework is then acting as the client. Of course you can use those libraries as well completely locally.
This is definitly a very powerful feature that should not be underestimated.
What about …
Typically when evaluating a new tool there are plenty of questions related to ones own use cases. Please feel free to ask or comment in the comments section below. I will give my best to answer them. One question that should be asked is
… Continuous Integration?
Integrating the Robot Framework to a Continuous Integration server is very straightforward due to the script nature of the core Robot Framework system. The Java version can of course also be integrated using Maven. When it comes to Jenkins there is also a Robot Framework PlugIn available .
To be continued
As stated in the beginning the plan is to continue this series with more detailed articles. The next one is planned to cover a complete sample project. Stay tuned :). Other parts available are listed below.
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.