Calling a keyword under *** Variables ***

1,077 views
Skip to first unread message

Vidya S

unread,
Jun 16, 2016, 4:50:10 AM6/16/16
to robotframework-users
Hi,
       I am using a variable which value will be used in entire suite.As a reason I need to put the var under *** Variable *** tag,

 1.Under *** Variables *** , when we add scalar variable , this scalar variable stores the return value of the keyword .
 2. The keyword needs a single parameter .
 
here is the e.g  :
*** Variables ***
${subnet} Get ${ip} 
${subnet} holds return value of keyword , Get is the keyword and ${ip} is the parameter to that keyword.


please let me know how can we achieve this. I tired but keyword throws error as the parameter is not recognized .

J Wipf

unread,
Jun 16, 2016, 6:31:55 AM6/16/16
to robotframe...@googlegroups.com
I would look into [1]. Try to use a keyword that has the least scope possible. Depending on when you want this available you could call the keyword in suite setup.

[1] http://robotframework.org/robotframework/latest/libraries/BuiltIn.html#Set%20Global%20Variable

Bryan Oakley

unread,
Jun 16, 2016, 6:56:39 AM6/16/16
to robotframework-users
You can't do what you want. the variables table is for static values only. From the user guide:

The most common source for variables are Variable tables in test case files and resource files. Variable tables are convenient, because they allow creating variables in the same place as the rest of the test data, and the needed syntax is very simple. Their main disadvantages are that values are always strings and they cannot be created dynamically.

For an example of how to use a keyword, see http://stackoverflow.com/a/29774308/7432

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

Kevin O.

unread,
Jun 16, 2016, 1:23:45 PM6/16/16
to robotframework-users
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.
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

On Thursday, June 16, 2016 at 3:50:10 AM UTC-5, Vidya S wrote:

Pekka Klärck

unread,
Jun 17, 2016, 7:51:55 AM6/17/16
to ombre42, robotframework-users
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
Reply all
Reply to author
Forward
0 new messages