How does robotframework handle booleans?

4,873 views
Skip to first unread message

kd

unread,
Mar 5, 2009, 11:10:16 PM3/5/09
to robotframework-users
Hi,
I'm trying to compare boolean values in my test, so I have the
following:

<pre>
*Keyword* *Action* *Argument* *Argument*
Expected Value Of [Documentation] Compares a given response and
validates if the values match
[Arguments] ${elementName} ${expectedValue}

Should be Equal ${actualValue} ${expectedValue}
</pre>

where expectedValue is passed into the "Expected Value Of" keyword,
and actualValue is known to it.

The comparison didnt work so I replaced the test with "Should Be Equal
As Strings" and it worked for most part, except when I got to
booleans.

Being a Python/Jython noob, it took me a while to grok that there are
no true booleans in the language. I'm using Jython 2.2 and jybot
(2.0.4), btw.

Having figured that out, I replaced it with the following:
<pre>
${expectedValueMod}= Set Variable If str(${expectedValue}).lower() ==
'true' 1
... str(${expectedValue}).lower() == 'false' 0 ${expectedValue}
Should be Equal As Strings ${actualValue} ${expectedValueMod}
</pre>

the idea being, if everything passed in is a string, then check if the
input string is lower case true, and set it to 1, so that the stored
value (which is already evaluated and will contain 1 if its boolean
true) will then be evaluated against this modified value as a string
and everything will work.

But then things get confusing. If ${expectedValue} has been passed the
value True, then robotframework to evaluate ${expectedValue} to True,
but type(${expectedValue}) returns <type 'int'>. However, converting
it to string magically converts it to a 1, so none of the if clauses
apply, and it falls through to the else where it regains its old value
of True. So finally in the should be equals, 1!=True, the test fails.

In contrast, if I do a similar set of steps in Jython, the behavior is
consistent.
<pre>
Jython 2.2 on java1.6.0_05
Type "copyright", "credits" or "license" for more information.
>>> a=True
>>> type(a)
<type 'int'>
>>> a.lower()
Traceback (innermost last):
File "<console>", line 1, in ?
AttributeError: 'int' object has no attribute 'lower'
>>> a.__str__().lower()
'1'
>>>
</pre>

What's going on here? Obviously, my noob-ness is getting in the way,
and more efficient code and test code could be written, but the key
questions I have are:
1. What is the type of robotframework ${vars} - are they always
strings? Or are they truly typed?
2. If so, they why arent booleans consistent with the underlying
jython/python semantics.

Any/all help welcome; thanks in advance.
kd

Janne Härkönen

unread,
Mar 6, 2009, 8:10:17 AM3/6/09
to kd.v...@gmail.com, robotframework-users
On Fri, Mar 6, 2009 at 6:10 AM, kd <kd.v...@gmail.com> wrote:
>
> Hi,
> I'm trying to compare boolean values in my test, so I have the
> following:
>
> <pre>
> *Keyword*       *Action*        *Argument*      *Argument*
> Expected Value Of       [Documentation] Compares a given response and
> validates if the values match
>        [Arguments]     ${elementName}  ${expectedValue}
>
>        Should be Equal         ${actualValue}  ${expectedValue}
> </pre>
>
> where expectedValue is passed into the "Expected Value Of" keyword,
> and actualValue is known to it.

Hello,

if I understood correctly, the ${actualValue} is always a Boolean.
In that case, you can use Robot Framework variable syntax to create
Booleans in the test case:
http://robotframework.googlecode.com/svn/tags/robotframework-2.0.4/doc/userguide/RobotFrameworkUserGuide.html#boolean-and-none-null-variables

> Being a Python/Jython noob, it took me a while to grok that there are
> no true booleans in the language. I'm using Jython 2.2 and jybot
> (2.0.4), btw.

Python has actual booleans from 2.3 forward,
Jython 2.2 uses integer values 1 and 0 to designate True and False, respectively

> 1. What is the type of robotframework ${vars} - are they always
> strings? Or are they truly typed?

Variables created in the HTML test data are strings, unless specified
with the special syntax for Booleans, numbers, or None/Null.
However, variables returned by keywords in tests libraries can have
any data type.
Should be Equals compares both type and value, Should be Equal as
Strings basically calls toString() on both arguments and compares
those.

Hopefully this clarifies things, and please don't hesitate to ask for
clarification if I explained something badly,

__janne

kd

unread,
Mar 20, 2009, 5:34:52 PM3/20/09
to robotframework-users
I meant to respond earlier, sorry about that.
thanks for the prompt response, Janne.

I do think, though that it would be nice if there were a way to have
"TRUE" instead of ${true} - esp if robot is to be used for acceptance,
and it might seem incongruous to business/qa users to find symbols in
the middle of what can be otherwise some pleasantly structured
english.

but as a quick fix, that does work, so thanks again.

kd

On Mar 6, 8:10 am, Janne Härkönen <janne.t.harko...@gmail.com> wrote:
> On Fri, Mar 6, 2009 at 6:10 AM, kd <kd.vi...@gmail.com> wrote:
>
> > Hi,
> > I'm trying to compare boolean values in my test, so I have the
> > following:
>
> > <pre>
> > *Keyword*       *Action*        *Argument*      *Argument*
> > Expected Value Of       [Documentation] Compares a given response and
> > validates if the values match
> >        [Arguments]     ${elementName}  ${expectedValue}
>
> >        Should be Equal         ${actualValue}  ${expectedValue}
> > </pre>
>
> > where expectedValue is passed into the "Expected Value Of" keyword,
> > and actualValue is known to it.
>
> Hello,
>
> if I understood correctly, the ${actualValue} is always a Boolean.
> In that case, you can use Robot Framework variable syntax to create
> Booleans in the test case:http://robotframework.googlecode.com/svn/tags/robotframework-2.0.4/do...

Pekka Klärck

unread,
Mar 20, 2009, 5:56:50 PM3/20/09
to kd.v...@gmail.com, robotframework-users
2009/3/20 kd <kd.v...@gmail.com>:

>
> I do think, though that it would be nice if there were a way to have
> "TRUE" instead of ${true} - esp if robot is to be used for acceptance,
> and it might seem incongruous to business/qa users to find symbols in
> the middle of what can be otherwise some pleasantly structured
> english.

You may want to vote for issue "Automatic type conversion for Java keywords"
http://code.google.com/p/robotframework/issues/detail?id=245

> but as a quick fix, that does work, so thanks again.

Great!

Cheers,
.peke

Reply all
Reply to author
Forward
0 new messages