Set Test Variable and scalar vs lists
Taisto Tammi
When I set scalar, with Set Test Variable keyword to test level
variable, there is some strange behavior. The test level variable
behavior seems to depend, do I assign a new value to my test level
variable.
First example:
*** Test Cases ***
use bar test variable
create bar
verify bar
*** Keywords ***
create bar
${BAR}= Set Variable foo bar
Set Test Variable ${BAR}
verify bar
Log Variables
Should Be Equal ${BAR} foo bar
All works fine. ${BAR} is found by the "verify bar" keyword and ${BAR}
contains 'foo bar'
Second Example:
*** Test Cases ***
use foo test variable
create foo
use foo
verify foo
*** Keywords ***
create foo
${FOO}= Set Variable
Set Test Variable ${FOO}
use foo
Log Variables
${FOO}= Set Variable foo bar
Log Variables
verify foo
Log Variables
Should Be Equal ${FOO} foo bar
I would expect that in the "use foo" keyword, the ${FOO} is still test
level variable and based on the Log Variable keyword it seems to be
so. But in the "verify foo" keyword, the ${FOO} is empty, which I did
not expect. I did expect to contain 'foo bar'
Third example, with list:
*** Test Cases ***
use list
create mylist
use mylist
verify my list
*** Keywords ***
create mylist
@{MYLIST}= Create List
Set Test Variable @{MYLIST}
use mylist
${temp}= Catenate foo bar
Append To List ${MYLIST} ${temp}
verify my list
Log Variables
Should Be Equal @{MYLIST} foo bar
Now against the second example, but somewhat aligned with first
example, the @{MYLIST} is test level variable (assumed) and list
contains: 'foo bar'. So verification succeeds and test pass.
So the question, is this a bug (which of the examples actually
contains the bug?), expected behavior or something else (if yes, what
then)? If some correction is made, I would like that that example 2 is
fixed, to the direction what the example 3 tries to do.
Jussi Malinen
This is actually similar to how the namespaces work in python.
If you set a scalar variable using "set variable" it creates a new
variable which is visible only inside that keyword. If you modify a
list then you are modifying the original list, not creating a new one.
If you want to modify the value of a scalar test variable in side a
keyword, then you need to use "set test variable" keyword.
- Jussi
--
Jussi Malinen / Robot Framework
Reaktor, www.reaktor.fi
> --
> You received this message because you are subscribed to the Google Groups "robotframework-users" group.
> To post to this group, send email to robotframe...@googlegroups.com.
> To unsubscribe from this group, send email to robotframework-u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/robotframework-users?hl=en.
>
>
--
Jussi Malinen / Robot Framework
Reaktor, www.reaktor.fi
Taisto Tammi
So, this could as design feature? If this is true, then for us
non-python users, the documentation [1] [2] could be enhanced to mention
this? At least I have a habit to declare all the global/suite/test level
variables in the beginning of the test. And if a assign a value to a
global scalar, I do not expect it do disappear.
[1]
http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html?r=2.6.3#using-built-in-set-test-suite-global-variable-keywords
[2]
http://robotframework.googlecode.com/hg/doc/libraries/BuiltIn.html#Set%20Test%20Variable
Pekka Klärck
>
> So, this could as design feature?
Yes, the behavior is by design.
> If this is true, then for us non-python
> users, the documentation could be enhanced to mention this?
Variable priorities and scopes are actually already explained:
http://robotframework.googlecode.com/hg/doc/userguide/RobotFrameworkUserGuide.html?r=2.6.3#variable-priorities-and-scopes
If you have ideas on how to enhance the documentation please let us know.
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
Taisto Tammi
Perhaps documentation should make a differentiation between the scalar and list in the Variable scope. If one assigns a new value to a list after the list has been declared as Global/Test suite/test case scope, the list will keep the scope. In the other hand, if one assigns a value to the scalar, after the scope is declared, the scalar will lost the scope and one must declare the scope again (if needed).
Now the priorities [1] section says in the Variables set during test execution that variables set during test execution will always override the variable scope, which is only valid for scalar and not for a list. Now the build-in library documentation [2] says that: Variables set with this keyword are available everywhere within the scope of the currently executed test suite. Which is did lead me to assume that if I assign new value to the scalar, scalar will keep it's scope. Which is a bad assumption, I have to admit.
But anyway, I did not see explained the differentiation between the scalar and the list anywhere in the documentation. I can try write something up, if one needs?
-Tatu
Pekka Klärck
>
> Perhaps documentation should make a differentiation between the scalar and
> list in the Variable scope.
There is no such difference.
> If one assigns a new value to a list after the
> list has been declared as Global/Test suite/test case scope, the list will
> keep the scope. In the other hand, if one assigns a value to the scalar,
> after the scope is declared, the scalar will lost the scope and one must
> declare the scope again (if needed).
The difference you encountered was that when you modified an existing
list variable the changes were seen also outside the scope where you
did the change. If you had, instead, created a new list variable with
the same name, this change would not have been seen outside that
scope. You can try this by changing the line
Append To List ${MYLIST} ${temp}
in your example to
@{MYLIST}= Create List @{MYLIST} ${temp}
Set Test Variable @{MYLIST}
Notice that you would get a same behavior if your scalar variable
contained an object that you could modify (in programming such objects
are typically called mutable). If you would, for example, create a
scalar variable ${MYLIST} instead of list variable @{MYLIST},
modifying it would have exactly same semantics. Notice also that the
most command scalar variable values strings and numbers cannot be
mutated in Python.
It could be that this difference between immutable and mutable
variable values isn't explained in the User Guide. Writing a short
section about it might be in order.
Taisto Tammi
After doing some reading, from python and from user guide, all this
seems quite logical. I have to admid that my expectations were wrong
and whit better rtfm this could have been corrected. The point that
Pekka did made, is missing from user quide and should be corrected.
Should I raise a bug about it?
-Tatu
Pekka Klärck
>
> The point that Pekka did made, is missing from user quide and should be corrected.
>
> Should I raise a bug about it?
Please go ahead and submit an issue about it. If you have an idea
where the section should be added please mention that too.