Variables should not leak to lower level keywords

[GoogleCodeExporter]

Currently this is passes:

***Test Case***
Example
  ${x}=  Set Variable  hello
  My keyword

***Keywords***
My keyword
  Should be equal  ${x}  hello
  ${y}=  Set Variable  world
  Second keyword
Second Keyword
  Should be equal  ${x}  hello
  Should be equal  ${y}  world

This has definitely definitely been a bad design decision, and a person who
has designed it years ago I can call it a bug rather than a feature.
Instead of variables leaking to lower level keywords like this, they should
be passed as argument or, in special cases, set explicitly using Set Test
Variable keyword.

Even though this is a mis-feature, we cannot remove it without deprecating
first it because existing tests may depend on it. Unfortunately the current
variable implementation is so naïve that deprecation cannot be easily done
without larger changes that don't fit into RF 2.5 scope. We thus probably
need to deprecate this in 2.6 and remove fully in 2.7.

Unfortunately RF 2.5 has already now too much content so 2.6 is the
earliest version where we can fix this. Even more unfortunately we cannot
just remove this mis-feature because existing tests may use it. We should
at least 

Original issue reported on code.google.com by pekka.klarck on 14 Apr 2010 at 9:18

[GoogleCodeExporter]

See this discussion for an example of confusion caused by this behavior:
http://groups.google.com/group/robotframework-users/browse_thread/thread/f610fd0
a9133fcd6

Original comment by pekka.klarck on 14 Apr 2010 at 9:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Maybe, It will be useful if you can run Robot with a parameter for avoid the
"Variable leaking" for a while.
Something like: pybot -l test

Original comment by cmalu...@gmail.com on 16 Apr 2010 at 7:33

[GoogleCodeExporter]

I think a good plan how to resolve variables in RF 2.6 is this:
1) Don't put variables inside a test or keyword into the scope of the lower 
level
keyword.
2) Don't put variables in test, suite, or global level there either.
3) When resolving variables, first look the local scope.
4) If there is no variable in the local scope, look the scopes of the higher 
level
keywords and test.
5) If var is found from higher level scopes, use it but show a deprecation 
warning.
6) If var still not found, look for it from test, suite, and global scopes in 
that order.
7) If no var found, resolving failed.

In RF 2.7 we can then skip steps 4) and 5) altogether.

Original comment by pekka.klarck on 16 Apr 2010 at 9:14

[GoogleCodeExporter]

Issue 579 has been merged into this issue.

Original comment by pekka.klarck on 28 Jun 2010 at 8:13

[GoogleCodeExporter]

Original comment by janne.t....@gmail.com on 19 May 2011 at 1:20

• Added labels: Target-2.7

[GoogleCodeExporter]

Initially descoped from 2.7 due to lack of time

Original comment by robotframework@gmail.com on 2 Dec 2011 at 8:42

• Removed labels: Target-2.7

[GoogleCodeExporter]

This can lead to strange behavior if the lower keyword relies on "Using list 
variables as scalar variables" functionality.
For example:
If higher level keyword defines local ${items}, lower level keyword defines 
local @{items}, and then lower level keyword tries to use the list as a scaler 
- ${items}, it has the value set in the higher keyword and the value is not 
related to @{items}.

Original comment by kormb...@gmail.com on 19 Nov 2012 at 5:07

[GoogleCodeExporter]

Original comment by pekka.klarck on 4 Nov 2013 at 8:31

• Added labels: Target-2.9

[GoogleCodeExporter]

Robot Framework is being migrated to GitHub and issues have already been moved 
to https://github.com/robotframework/robotframework/issues/. Old IDs are 
preserved so you can find this particular issue using URL like:

    https://github.com/robotframework/robotframework/issues/<id>

Original comment by pekka.klarck on 30 Jun 2014 at 2:12

• Changed state: Moved