Archiv der Kategorie: Robot Framework

Install Robot Framework with IronPython on Windows

… or how to get YOUR Robot Framework test-report in less than 10 minutes!


Installation architecture


Install Robot Framework from Source Code

1.) Download & install IronPython
2.) Install elementtree (because it’s broken in current IronPython:

cd C:\Program Files (x86)\IronPython 2.7
ipy install

3.) Install Robot Framework:

cd "C:\Program Files (x86)\robotframework-2.9"
"C:\Program Files (x86)\IronPython 2.7\ipy.exe" install

4.) Add

C:\Program Files (x86)\IronPython 2.7;

to the PATH-variable.
5.) Restart cmd & check for success:
cd "C:\Program Files (x86)\robotframework-2.9\src\bin"
ipybot --version


Run an example testcase

1.) Save

*** Test Cases ***
My Test
Should Be Equal 1 1

as Example.txt in C:\Program Files (x86)\robotframework-2.9\src\bin
2.) Execute in cmd:
ipybot Example.txt

Create a test-report

1.) Execute in cmd:
ipyrebot output.xml
2.) Open report.html and enjoy the result:
For more information on Robot Framework read:

SKIP Mechanics in Robot Framework

I haven’t found a sophisticated solution to SKIP in Robot Framework (compare this issue).
So you have to implement such a mechanism on your own.
There are two parts:
1.) the independent testcase (or testsuite)
2.) the dependent testcase (or testsuite)
1.) The independent testcase
Execute in [Teardown] only one keyword, because Robot Framework restricts more then one (the same applies to [Setup]).
Because IMHO the SKIP mechanism belongs to the testcases, I wouldn’t put the keyword definition in a ressource file, but at the end of the test case file.
Because you typically will take a screenshot in the testcase teardown, the file would look like this:

*** Variables ***
${SkipDependenciesOfTestcase1}    False    # this declaration avoids "Non-existing variable '${SkipDependenciesOfTestcase1}'"-Error which happens non-deterministically (=sometimes).
*** Test Cases ***
Testcase 1
     Testing Keyword 1
     Testing Keyword 2
     [Teardown]    Teardown Testcase 1
*** Keywords ***
Teardown Testcase 1
     Capture Page Screenshot    Teardown Testcase 1.png
     Run Keyword If Test Failed    Set Global Variable    ${SkipDependenciesOfTestcase1}    True

2.) The (appropriate) dependent testcase
You have to put the second part of the SKIP mechanism into the [Setup] of the dependent testcase:

*** Test Cases ***
Testcase 2
     [Setup]    Setup Testcase 2
     Testing Keyword 3
     Testing Keyword 4
*** Keywords ***
Setup Testcase 2
     Run Keyword If    '${SkipDependenciesOfTestcase1}'=='True'    Fail    SKIPPED due to failure of testcase 1.

Some testautomaters prefer to PASS a SKIPed testcase: Pass Execution Keyword
Tip: You can test your implementation of skip mechanism with an empty page, because then the independent testcase fails certainly and quick.
For more information on Robot Framework read:

Robot Framework is a programming language

Working on a large project (~200 web developers) with Robot Framework (RF) for ~3 month, I consider the notion of “framework” in Robot Framework a bit misleading. Robot Framework is more than a framework, it’s also a programming language. In this article I don’t want to bash Robot Framework as a testautomation language, even if I don’t feel comfortable with its strange syntax. I want to show that Robot Framework is a programming language and draw some conclusions.
RF has its own syntax
RF has variables (with different scopes)
You create them like this:

${hi} = 	Set Variable 	Hello, world!
${hi} = 	Set Test Variable 	Hello, world!
${hi} = 	Set Suite Variable 	Hello, world!
${hi} = 	Set Global Variable 	Hello, world!

BuiltIn-Library Documentation
RF has functions
In RF they are called keywords.
You create them like this:

Return One Value 	[Arguments] 	${arg}
	Do Something 	${arg}
	${value} = 	Get Some Value
	[Return] 	${value}

User Guide
RF has conditional statements
It looks like this:

${result} = 	Run Keyword If 	${rc} == 0 	Zero return value
... 	ELSE IF 	0 < ${rc} < 42 	Normal return value
... 	ELSE IF 	${rc} < 0 	Negative return value 	${rc} 	arg2
... 	ELSE 	Abnormal return value 	${rc}

BuiltIn-Library Documentation
RF has loops
And they look like that:

Run my hobbies
    :FOR 	${index} 	IN RANGE 	1 	11
    \    Watch TV
    \    Plague your neighbor
    \    Play with your dog

User Guide
RF has its own IDE
It’s called RIDE and it has some bugs.
RF has its own libraries
Look e.g. in the Selenium2Library
You’ll see, that the naming has nothing in common with what you’re used to from the WebDriver API.
… and RF has its own gotchas and bugs
Because the testcase-timeout produces a flaky bug in the reporting engine, I had to implement a timeout on my own … loop … sleep … boilerplate …

  • Test automation is programming. Robot Framework is a programming language. And you have to spend time on learning it.
  • I haven’t found any advantages over Java/TestNG yet (after 3 month working full-time with it).
  • Think of the Java web-devs in your project/scrum team. Do they want to read/maintain test scripts in a foreign programming language?
  • The skill-combination of Robot-Framework and browser-automation is seldom (In XING (leeding business network platform in Germany) you find the skill-combination “Selenium AND Robot Framework” with 12 people. But the skill-combination “Selenium AND Java” you find at 1000 people.
    • So think of stuffing your project: it is easier to find a pro with Java skills than with Robot Framework skills.
    • So think of the size of the community for support, advancing the tools, articles, …

If you are an adventurer, try it with Robot Framework.
If you like to install Robot Framework on .NET, find an instruction here
For more information on Robot Framework read: