Zum Inhalt

Over the last few months it has been both a side project at work and part of my Master Thesis to write an integration of the Ranorex API into the Robot Test Automation Framework. It all started with an idea, and the first steps were to make a proof of concept, then to find out which parts of Ranorex can be transferred to Robot, and how this all can work from a technical perspective.

Fast forward to the results (as I think that everything else is not really interesting). This integration now makes it possible to write keyword-driven tests in Robot utilizing the full power of Ranroex. This means that you can finally write GUI tests using a keyword-driven approach. Yay. (At least if you own Ranorex licenses, of course.) The project itself can be found on GitHub.

So, what does this mean in practice? What is the purpose, and which problem does this integration solve?

Well, you can now do something like this (in Robot syntax):

*** Test Cases ***
Calculate 1 Plus 5
Run Application    calc.exe
Press Button 1
Press Button +
Press Button 5
Press Button =
Validate Result    6
Close Application    /winapp[@packagename='Microsoft.WindowsCalculator']

So, we just write a test using simple keywords. However, if you try to run this test in Robot, it will fail, because none of these keywords are known to Robot. Therefore, you have to import the RanorexLibrary into you Robot test. If you have placed the path to the the RanorexLibrary files in your system path, then this is as simple as this:

*** Settings ***
Library    RanorexLibrary    path\\to\\Ranorex\\Bin

Now, Robot would know the keywords „Run Application“ and „Close Application“ and the test would be able to correctly start and close the Windows calculator. The other keywords aren’t defined anywhere, yet. But that’s no problem, since we can just create keywords from other keywords:

*** Keywords ***
Press Button 1
Click    /winapp[@packagename='Microsoft.WindowsCalculator']//button[@automationid='num1Button']

Press Button +
Click    /winapp[@packagename='Microsoft.WindowsCalculator']//button[@automationid='plusButton']

Press Button 5
Click    /winapp[@packagename='Microsoft.WindowsCalculator']//button[@automationid='num5Button']

Press Button =
Click    /winapp[@packagename='Microsoft.WindowsCalculator']//button[@automationid='equalButton']

Validate Result
[Argument]    ${result} Validate Attribute Equal /winapp[@packagename='Microsoft.WindowsCalculator']//text[@automationid='normalOutput'] Text${result}

Now, we have also defined the other missing keywords, using other keywords that themselves are defined in the RanorexLibrary, here the keywords „Click“ and „Validate Attribute Equal“. The „Click“ is passed on to the Ranorex .dll files and executed by the Ranorex core, and after starting the Robot test, Ranorex will take over the mouse cursor, move it to the element that is specified by its RanoreXPath, and click it.

The RanoreXPath is still the way how you address UI elements, same as it would be in plain Ranorex. If used correctly, a tester would apply the Page Object Pattern to abstract the RanoreXPath away from the actual test case, and the test case itself would be a very simple, easy-to-understand and easy-to-write collection of keywords. The beauty of keyword-driven testing shows here: It is flexible, powerful, but also simple and user-friendly.

If you are interested in more information, you can find my whole thesis describing the integration here.

Published inComputer Science