embedded keywords in a custom test library?

[Kai Hackemesser]

Hi,

I haven't found that in the documentation:

Can I have custom test libraries (4.1.6   Dynamic library API) with embedded keywords (2.6.4   Embedding arguments into keyword name)? And how would the getKeywords/getArguments have to look for that?

Cheers,
Kai

[Pekka Klärck]

2010/2/25 Kai Hackemesser <kai.hac...@gmail.com>:

Embedding arguments into the keyword name works only with user
keywords. The main reason this support wasn't implemented for library
keywords is that we couldn't figure out any suitable syntax. If
someone has an idea how it should work, the functionality could be
added possibly already in RF 2.5.

Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Kai Hackemesser]

Ok, for ideas I'm good :)

How about this:

if the getKeywordNames() method returned any value that contains a placeholder like "high_${number}", the robot framework would be aware of this keyword and adds it to the begin of list of arguments that will be returned with the getKeywordArguments() in the order of their appearance. when the method then is called the number of arguments is correctly processed by the runKeyword() method (library is responsible to handle the parameters then.)

to take the example further there are then two cases:
- If the keyword is emtpy on the call like in ${output}=\thigh
the method call would be
return runKeyword("high_${number}", {null})
- If the keyword is given on the call like in ${output}=\thigh five
the method call would be
return runKeyword("high_${number}", {"five"})

Is that realistic?

Cheers,
Kai

2010/2/26 Pekka Klärck <pekka....@gmail.com>

[Pekka Klärck]

2010/2/26 Kai Hackemesser <kai.hac...@gmail.com>:

> Ok, for ideas I'm good :)
>
> How about this:
>
> if the getKeywordNames() method returned any value that contains a
> placeholder like "high_${number}", the robot framework would be aware of
> this keyword and adds it to the begin of list of arguments that will be
> returned with the getKeywordArguments() in the order of their appearance.
> when the method then is called the number of arguments is correctly
> processed by the runKeyword() method (library is responsible to handle the
> parameters then.)

It didn't need to be even this complicated. With user keywords it's
enough that a) the keyword has variables embedded like
"high_${number}", and b) the keyword doesn't take any arguments. With
the dynamic library API where the library returns the keyword names we
could actually use exactly same rules.

A bigger problem would be how to support this with the static library
API. It's not possible to have a method with name like
"high_${number}" in the code so we needed to figure out some other
syntax. Any ideas?

Personally I'm not sure that library keywords even need this
capability. I've found that the possibility to embed arguments to the
keyword names works best on higher level test cases where you really
want to make the test read like plain text requirement or example.
Even in such cases I've been happy to use the normal argument passing
mechanism with the lower level keywords needed by these tests. Notice
that I'm not saying this functionality would be totally useless or it
will never be added. Getting it into RF 2.5 will require external
help, though.

Cheers,
.peke

[Kai Hackemesser]

2010/3/2 Pekka Klärck <pekka....@gmail.com>

A bigger problem would be how to support this with the static library
API. It's not possible to have a method with name like
"high_${number}" in the code so we needed to figure out some other
syntax. Any ideas?

 
I would say how about ruling that dynamic keywords are only possible with dynamic user libraries (and locally defined keywords of course)?

 

Personally I'm not sure that library keywords even need this
capability. I've found that the possibility to embed arguments to the
keyword names works best on higher level test cases where you really
want to make the test read like plain text requirement or example.
Even in such cases I've been happy to use the normal argument passing
mechanism with the lower level keywords needed by these tests. Notice
that I'm not saying this functionality would be totally useless or it
will never be added. Getting it into RF 2.5 will require external
help, though.

Let's say it's a nice to have ;)

Cheers,
Kai