Ask a Question

ReadyAPI - How to use code in the custom properties of a test step ?

SOLVED
rajs2020
Frequent Contributor

ReadyAPI - How to use code in the custom properties of a test step ?

Say we have a test step which actually calls/runs some test case. One of the properties, say ID has a variable value which is set by something else (script, another test step etc.). E.g. like this:

ID : ${TestCase-GetId#ID}.

Can I use code inside the value box/field to alter the value of ID? This will be useful for ad hoc testing or could be used normally in the test. E.g. ID : ${TestCase-GetId#ID}.subString(0, 5). I don't want to create another groovy script for minor changes to property values.

I know that we can prepend or append constants to the value easily like this - ID : MyId_${TestCase-GetId#ID}. But, I don't know if we can use code there instead. If we can use code, then are there any limitations (e.g. the code should be 100 characters or less) ?

Keywords -

script in custom properties editor, code in custom properties editor, alter the value of a custom property, code in the value of a custom property, script in the value of a custom property, code in the custom properties of a test step.

2 REPLIES 2
richie
Community Hero

Hey @rajs2020,

Yep you can do this. SmartBear call it dynamic property expansion or inline scripting.

For example i used ${=Java.util.randomUUID()} to autogenerate unique GUIDs/UUIDs.

If you search the property transfer/property expansion SmartBear help, youll find the inline scripting detail.

Nice one

Rich.
if this helped answer the post, could you please mark it as 'solved'? Also if you consider whether the title of your post is relevant? Perhaps if the post is solved, it might make sense to update the Subject header field of the post to something more descriptive? This will help people when searching for problems. Ta
rajs2020
Frequent Contributor

Thanks @richie. That helps.

Btw, I wish we could avoid writing the fully qualified names of classes there. It makes the code harder to read & takes up too much space. Maybe we could have imports for the custom properties window to avoid full names. Then, we could still use full names in case we have use a class name which is present in two or more packages.

 

cancel
Showing results for 
Search instead for 
Did you mean: