Forum Discussion

rajs2020's avatar
rajs2020
Frequent Contributor
4 years ago
Solved

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.

  • 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.

2 Replies

  • richie's avatar
    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.
    • rajs2020's avatar
      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.