In brief: the Robot Framework Online Conference 2020

The agenda of the 1st “Robot Framework Online Conference” alone was promising and the participants were not disappointed on July 30. Summary of an informative and exciting afternoon.

On 30 July 2020, the Imbus AG invited the 1st online conference on “Robot Framework”, which Rene Rohner moderated with confidence. In addition to his work as a software testing consultant at Imbus, Rene is also a member of the Robot Foundation board which aims to advance the development of Robot. At the start of the conference at 2 p.m., about 140 slots in GotoMeeting were occupied, which is a very good result given 145 registered participants. The first conference block offered four presentations before the participants spread out to different virtual rooms to discuss the following topics in workshops:

• Web automation with Robot Framework (Christoph Singer, Imbus AG) – “Everything about web automation with the Selenium Library and news for connecting Playwright and Robot Framework.”
• Robot Framework Core (Andrej Nod, imbus Rheinland GmbH) – “Everything about Robot Framework itself, its operation, syntax and functions.”
• Robot Framework APIs (René Rohner, imbus AG) – “Developing Libraries, Listener API, PreRunModifier, ResultVisitors and Co. Connecting to the APIs of Robot Framework and extending them with Python.”
• Keyword-Driven Testmanagement (Frank Blechschmidt, imbus Rhein-Main GmbH) – “Keyword-Driven Testing with the test management system imbus TestBench and Robot Framework. demo and discussions.”
• Security testing with Robot Framework (Tobias Esser, imbus AG) – “How can security testing be automated with Python and Robot Framework? Which tests are recommended and help in automation?”

Pekka Klärck: News From Robot Framework / Roadmap

The conference started with Pekka Klärck, the “father” and lead developer of Robot Framework. He introduced Robot’s release roadmap and answered questions from participants.

RF 3.2.2 – the upcoming release

Version 3.2.2 will be released in early September as the last release in the 3.2 series and will mainly include small improvements. The next major release 4.0 is already scheduled for December. This is a good reason to test version 3.2 now and to submit bugs and suggestions for improvement in a timely manner.

RF 4.0 

With version RF 4.0, some new features are entering the popular framework:

Listener API:   In this release, the listener API is neatly expanded. Listeners are loaded as Python or Java classes by Robot at startup and plug into predefined so-called “hooks” – this way they receive notifications about all possible internal events before, during and after test execution.

A prominent example of this are debuggers, which can be used to put the test on hold and inspect it. Specifically, version 4 will provide new events for “Keyword start/end” as well as allow the output of the current line number in the code.

Alea iacta sunt: “SKIP”:   The main reason for increasing the major release number to 4, however, is certainly the fact that the concept of “criticality” will no longer exist from this version and will be replaced by the STATUS   SKIP.

So far, all test cases are considered criticalby default in   Robot; they therefore determine the status at the end of a suite. When calling Robot, however, this behavior can be changed by using the   switches –critical   or   –noncritical   the Tagsof the tests are specified as patterns that should be considered critical or non-critical. To avoid misunderstanding: it does not set a “critical” status, but only precisely determines which tests have permission to change the overall status if necessary.

Whether   SKIP   is a replacement   for “criticality”, was discussed on the Robot-Slack-Channel  and on GitHub. Pekka justified his decision very detailed and comprehensible in issue #3624. Pekka cites as one of the main reasons that “criticality” has always been a “special feature” of Robot and that this fact made id hard for the integration of Robot into other tools.

In brief: to have the same behavior of –noncritical in the future, use –skiponfailue. Tests having these tags are executed, but marked as “skipped” if they fail; they have no influence on the overall result. To facilitate migration, RF 4.0 includes aliases for critical   and   noncritical that refer to the new   skiponfailure. (However, I advise not to use such workarounds. At the latest from version 5 onwards, a changeover will certainly be absolutely necessary.)

Interesting at this point, the approach described in   Issue 3625   is to create further “custom status”:

--addstatus NON-CRITICAL:SKIP:non-critical:pink --skiponfailure non-critical--addstatus KNOWN_ISSUE:FAIL:bug-id-*:purple

RF 5.0 

It already looked very strange how robot handles control structures like IF/ELSE   and   TRY/EXCEPT. RF version 5.0 should finally smooth this and also allow to nest such structures (which is currently not allowed). However, time will pass before this release is released – Pekka does not expect June 2021 at the earliest. By the way, from this release onwards, support for Python 2.x will definitely be over.

Who is working on Robot Framework?

One participant asked who is mainly working on The Robot Framework. I also get this question from customers again and again. In essence, only Pekka is working on The Robot Core, but he wants to build a team with the upcoming Major Releases 4/5 that can maintain the code together. Certainly not a bad idea to lower the Bus Factor. The fact that Robot is still being developed so actively is, by the way, a great credit to the Robot Foundation. Rene Rohner explained the importance of the foundation to the framework both during the conference and very well and in detail in the Robot Forum in the thread “Robot Framework Foundation unfolded”.

2021 Robocon

The question of whether a Robocon 2021 will be held, Pekka unfortunately had to deny. The current situation or the unforeseeable development of the COVID19 pandemic does not allow this; after all, contracts for location etc. would have to be concluded for this now. Instead, an online version of the Robocon is conceivable in May/June 2021, for example.

Mikko Korpela: Playwright / Robot Framework Browser Library

After Pekka Klärck, Mikko Korpela took over and showed what is behind the   library “Robot Framework   Browser”.

Let me explain some background…. Selenium   is like a dinosaur among the web testing tools, it exists since 2005 and has evolved. And thanks to Tatu Aalto   there is also always a top maintained Robot Selenium-Library for this.

Nevertheless, there are always some “pain points” that everyone knows: there are no implicit“waits”,for example, because Selenium does not really know when the loading of a page is finished. So it is almost inevitable to pre-create a corresponding assertion, for example, to precede a click, which ensures that the button to be clicked is actually there –   even if it is often only a matter of fractions of a second that the human eye does not perceive. Also, the webdriver (the binary which Selenium uses to control the browser remotely), must fit exactly to the browser and the corresponding version must be installed e.g. for Firefox (Geckodriver), Chrome (Chromedriver) or Edge (Edgedriver).

Google cleaned up a few years ago and released Puppeteer – a solution to automate Chrome and Chromium-based browsers. Batteries included: Puppeteer also carries the browser for you. In early 2020, the two developers who led Puppeteers moved to Microsoft and worked on Playwrighton this   basis.

Playwright   allows remote control of Chromium, Webkit, and Firefox-based browsers via a common   API and promises cross-browser and cross-OS support. It is therefore possible to test on Windows with a Safari instance, for example.

Furthermore, the API has been modernized so that a click   on an element implicitly waits for the element to appear. Playwright can also handle web components, i.e. detect and address enclosed DOM trees within another DoM. Killer feature in my eyes: the Selector engine allows the mixed use of text, CSS, and XPath selectors on one line:

#find span css selector inside xpath selector: 
xpath=//html/body/div >> css=span 

Instead of starting full-fledged instances of browsers, Playwright can create so-called contexts within the browser. It is therefore possible to open several tabs in a browser window, each of which has different geolocation or language settings in their context. This is much more convenient and faster than giving this to individual browser instances as a command line argument.

Playwright can natively execute keyboard and mouse events. Why is this important? On some Web pages, simply setting values in a form may not work, so the application does not respond to them. The input “by hand” works, however, because there is real keyboard activity. 

Under the leadership of Mikko, the “Robot Framework Browser Library” was created, which is based on Playwright. Mikka was a member of the Robot Core Developer Team for four years and helped to develop the RIDE editor for Robot. The“Pabot”robotic library for parallel execution of robot tests is also his work. 

Nils Balkow-Tychsen: Test automation with Kubernetes

Nils from Humanitec GmbH then introduced to the advantages of container-based test execution. Argument No. 1 is, of course, scalability, so that tests can also be performed in isolation and in parallel. But the optimal use of resources and full control over a single API are no less interesting. At the test level, containers havw the advantage that they in fact always start with exactly the same starting conditions.

Nils explained everything from simple container launches to the start of a complete deployment in Kubernetes. He also gave practical tips, including k9s, a CLI interface for the administration of Kubernetes clusters. I only knew ctop so far…. With k9s, managing a Kubernetes is really fun:

k9s in action (Source: gitlab.com)

Nils then showed the test infrastructure he designed at Humanitec about two years ago. 

Rene Rohner: Debugging Robot Framework

Then Rene showed the possibilities to debug Robot Framework. In doing so, he proceeded “from the outside to the inside”. He first showed the use of the   DebugLibrary, simply stops the test on the keyword   . On the command line you can then debug interactively. If you know ipython or ipdb, you are immediately confident with this.

Because that wasn’t enough for Rene, he programmed his own debugger library some time ago   – and it’s worth it.

Unlike the DebugLibrary, the debugger library does not wait for a keyword for the entry point, but enters as soon as a keyword is failing. It is important to mention here that the library has to be started as a “listener”, i.e. directly when calling Robot:

robot --listener debugger path/to/test.robot

Debugging in the Editor: Although I am a self-confessed  fan of VS Studio Code, the RED editor is very nice. Rene showed, however, that the Robot Framework Language Server provides at least the same possibilities for code completion and debugging. I’ll definitely look again. At the latest with the debugging possibilities of the RFLS you can really dig in the code and descend to the Python code of Robot itself during debugging. Sometimes this is extremely helpful to see what data Robot is actually working with.

Rene demonstrated all these debugging possibilities live. Debugging is an interesting topic for everyone…

Workgroup: Christoph Singer, SeleniumLibrary/Playwright

Then we went to the workgroups; I chose Christoph Singer’s slot, in which he explained more details about the advantages of Playwright and the Browser Library, which Mikko had previously presented. Especially the explanations of browser, context and page conecept were very understandable.

Playwright: Context of Browser, Context and Page

His live demo part was very exciting: he had built up a test, which should test a dummy car configurator page. Here we could see how useful the keywords of Robot can be if you structure them correctly: Christoph had separated the actual test sequence (login, select engine, etc.) from the library-specific keywords; the latter were written into a separate resource file, which itself imported the Selenium / Playwright library. By commenting on the corresponding line with the resource include, he was able to start the tests once with Selenium and once with the Robot Browser Library. The speed advantage by Playwright compared to Selenium was very nice to see here. 

It was a bit crazy to see the Safari browser on Windows without the fancy UI known from Apple systems 🙂

Christoph’s workshop concluded with a detailed Q&A section.

Conclusion

It is definitely worth keeping an eye on such online events. Of course, there is nothing beter than Robocon in Helsinki (and Finnish beer) – but special times require special measures, and Imbus has done a very good job. The conference system (GotoMeeting) also worked smoothly with approximately 150 participants. 

It is nice that Pekka Klärck enriched the event with his lecture on the roadmap and thus made it “highly official”. The presentation by Nils was just right for me, because I also want to equip my CheckMK monitoring extension “RobotMK” with the possibility to trigger robot tests in Kubernetes.

The presentations of Mikko and   Christophabout the new Browser Library for the Playwrightframework definetely have catched me. I am convinced that Playwright will become the Web   Test Method No. 1for Robot, even if the browser versions (apparently?) cannot be preselected and you are bound to the supplied browsers, so you cannot use a browser installed in the OS. 

And now I’ll open VS Studio Code and take a closer look at the Robot Framework Language Server…