2016-06-16 20:23 GMT+03:00 Kevin O. <
korm...@gmail.com>:
> As others have said, you should move the call to extract the subnet to test
> or suite setup and use Set Suite Variable or similar.
Yes, this is absolutely true. We could obviously consider enhancing
the syntax to allow calling keywords in the Variable table, but there
are two main problems with that:
1. We needed a way to separate normal value from a keyword call. At
least I don't have any good ideas for such syntax.
2. Variables in the Variable table are evaluated before importing
libraries to allow using them in the imports. Keywords aren't thus
available yet when variables evaluated, and resolving these special
variables would require some kind of a delay. Such delaying already
occurs when a variable is created based on another variable, but
adding keyword calls in the logic would nevertheless complicate
things.
The above said, being able to create variables in the Variable table
using keywords would sometimes be handy. If someone is interested to
design and implement this and the resulting syntax and code is good, I
don't have anything against reviewing and merging such PRs.
> I think it is a best practice is to put a placeholder in the variable table
> even though it is unnecessary.
>
> *** Variables ***
> ${SUBNET} X.X.X # populated in suite setup
This is a good practice. Obviously if there are certain variables that
are always automatically available and everyone knows about them,
listing them separately in each test suite isn't that useful.
Cheers,
.peke
--
Agile Tester/Developer/Consultant ::
http://eliga.fi
Lead Developer of Robot Framework ::
http://robotframework.org