Forum Discussion

rajs2020's avatar
rajs2020
Frequent Contributor
4 years ago
Solved

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

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's avatar
    richie
    4 years ago
    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

6 Replies

Sort By
  • richie's avatar
    richie
    Community Hero
    4 years ago
    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's avatar
      rajs2020
      Frequent Contributor
      4 years ago

      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's avatar
        richie
        Community Hero
        4 years ago
        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's avatar
    alexhim
    New Member
    4 years ago

    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.