ReadyAPI - how to tell if a test property is hard coded?

[rajs2020]

Tests can have properties (i.e. variables). We can set these properties to constants/fixed values via the property window pane, or via a groovy script. But, by looking at the property window, we can't easily & quickly tell if the property is hard coded or not. We have also have to check the test to see if the property value is set via a groovy script. During code/test reviews, this becomes annoying and wastes some time. So, is there an easy & fool-proof way to find out if a test property is hard coded? (One way could be by searching in the text xml file, but I'd like to avoid that.)

[richie · Accepted solution]

Hey @rajs2020,

It's not perfect, but the way i try and handle this is by prefixing or suffixing the propertyname (when defining the property) with a specific value depending on whether the property value is static or dynamic, etc.

Thats the only way i've found to handle this (at least partially).
Perhaps other forum members have better ideas?

Rich

[rajs2020]

I think you mean naming constants something like this CONSTANT_vote = 18, or simply _vote = 18 for brevity. This is helpful, but can be a bit unwieldy because you have to type a prefix before multiple properties. It will break when someone decides to start initializing a "constant" property via a groovy script, but does not change the property name accordingly. For example, _country = UK should become just "country" when we start supporting multiple countries. Moreover, property names can get too long if you need to add other prefixes/suffixes also (ex. some people might add input or output prefixes to show which properties are inputs for a test, and which properties a test sets for other tests to use respectively).

So, it would be nice if ReadyAPI could allow us to select the type (constant or variable) of a property when we create it. The property type could be shown as a separate column, OR instead of that ReadyAPI could automatically add a desired prefix for a property type (ex. constant prefix = _ or CONST etc.). Then, it could prevent constants from having variable values like ${...some var....}. That way, we can easily catch hard coding during test reviews. As an aside, it would be nice to also have enums, but that's probably excessive.

[richie]

Hey @rajs2020,

I agree with almost all of your points which is why i said it wasnt perfect, it was just the best approach id found with the current functionality. It doesnt work in all scenarios as you say, but considering the absence of anything else i use this cos its better than nothing at all.

As ive said on previous posts, if youre not content with the current functionality the only way to get functionality added to ReadyAPI! if there is no native support is to submit a new feature request.

Nice one

Rich

[alexhim]

It's not perfect, but the way i try and handle this is by prefixing or suffixing the propertyname (when defining the property) with a specific value depending on whether the property value is static or dynamic, etc.

[rajs2020]

Thanks for your reply. I now feel I am creating too many feature requests. I hope that the SmartBear team notices this & creates one for me.

[richie]

@rajs2020,

Hey man....if your suggestions provide value theyll get up voted and its in SmartBear's best interests to pay attention. Keep them coming i reckon!

Rich