Robot Framework Tutorial 2016 – Keywords

No Comments

Robot Framework Tutorial 2016

Part 1: Installation

Part 2: Keywords
Part 3: Implementing Keywords in Java
Part 4: Selenium2Library as a drop-in replacement for SeleniumLibrary
Part 5: Integration with TeamCity CI-Server
Part 6: Integration with Jenkins
Part 7: File Processing
Part 8: Working with Collections
Part 9: Wrap-Up and Conclusion

The “old” Robot Framework Tutorial.

The Robot Framework really comes with a very comprehensive User Guide. Sometimes this makes me think that additional tutorials are almost not needed. But then again I think that a blog post can be more specific in digging into one aspect of a tool than the documentation can. So here we go digging into the central testing concept of the Robot Framework and that is: Keywords.

This blog post will entirely deal with available Keywords and how to write new Keywords out of existing ones directly using Robot Framework features. For a lot of use cases this approach is already sufficient due to the huge amount of existing Test Libraries and thus Keywords. The next blog post in this series will then deal with writing new Keywords in Java (just in case you are waiting for that one). One could also use other programming languages, but for me as a Java developer this is a quite natural choice. Writing new Keywords this way is needed if you have to test specific technologies that are not yet covered by the existing Test Libraries.

A first Example

Let’s jump into the cold water right away with the smallest possible example I can think of for a Test written with the Robot Framework. (Yes, actually it is not even testing anything, but that is nitpicking.)

*** Settings ***

*** Test Cases ***
Test Robot Framework Logging
  Log   "Test Logging"

The Settings section is empty because we are not importing any external Test Libraries. I could have omitted that section of course, but somehow for me it belongs to a Test Case File even if it is empty.

We defined one testcase below the Test Cases section. That one is executing one Keyword “Log” and we are passing one parameter to this Keyword, namely the String “Test Logging”. Easy as that, but still there are a few stumbling blocks. There must be at least two spaces to separate arguments from Keywords and arguments from each other. Furthermore there must be always an indention of two spaces in the beginning of each line below a testcase. Both should be visible from the example, but it is still easy to miss these things.

The test can be executed with pybot or Java – depending on the type of your installation – directly from the directory where the Test Case File is stored.

pybot --outputdir ./report sample-0-trivial.txt
java -jar /usr/local/opt/robotframework/robotframework-2.9.2.jar --outputdir ./report sample-0-trivial.txt

There are lots of command line options possible. Here we are using “–outputdir” to define the place where the resulting Log- and Report-Files are stored. Just take a look at the Report-File by opening it in a Browser. We will still have a closer look on the Report- and Log-File at the end of this blog post.

All examples shown in this blog post can be found from GitHub here. This way they are hopefully easier to access than through this blog post and there are more examples than shown in this blog post. Furthermore I am planning to enhance that site with more examples in the future.

The Robot Framework is supporting different formats for writing Test Case Files. The format used throughout this blog post (and blog series) is the Plain Text Format. I simply like it the most as it is very easy to read and understand once you have been getting used to the thing with the “additional whitespaces” mentioned above. You could also use HTML, which allows you to have a nice kind of “presentation view” on your test cases. But it is simply more code to write and it is more likely to run into merge conflicts when putting the files under version control (which should always be the case). There is also the possibility to use BDD-style test case descriptions. Well, that could probably be a blog post of its own, but for the time being I would like to omit that. It only makes things more complicated while we want to learn the basic concepts here.

Thomas Jaspers

Long-term experience in agile software projects using
Java enterprise technologies. Interested in test automation tools and concepts.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon


Your email address will not be published. Required fields are marked *