Forum Discussion

richie's avatar
richie
Community Hero
6 years ago

Using the Environments Override When The HOST doesn't determine the environment

Hey!   This is a little confusing - so I'm going to try and be as clear as I can - I'll add visual aids :)   Within my ReadyAPI! project I have maybe 18 REST Services with various resources, ...
  • nmrao's avatar
    nmrao
    6 years ago

    richie 

    Provide payload as below

     

    resource=${#Project#RESOURCE}
&client_id=${#Project#CLIENT_ID}
&client_secret=${#Project#CLIENT_SECRET}
&grant_type=client_crendentials

    You can define property file as show below, and create a file for each enrionment.

    dev.properties

    RESOURCE=<dev-resource>
CLIENT_ID=<dev-client-id>
CLIENT_SECRET=<dev-client-secret>

    And import the above file at project level, refer below documentation

    https://www.soapui.org/scripting-properties/working-with-properties.html

     

    So, you can similarly, use properties for END POINTS / other varying values per environment into property file and use them in the project as mentioned in the payload content.

     

    Now all you need is single project, common test cases. No separate test suites / test cases per environment any more, just use appropriate property file, import them into project before running the tests.

    If you are running the tests command line, even properties can be directly loaded runtime without even modifying the existing values in the project.

richie's avatar
richie
Community Hero

Hey nmrao 

 

here ya go fella - screenshots of the 3 requests of the 'setup tests' - just to reiterate - these GENERATE the access tokens I need provide the authorization for my tests.  I execute one of these and write the generated access token to a single Project level property.  All my 'real' tests reference the access token via this Project level property.

 

Dev environment:

 

 

 

Test environment:

 

 

Integration environment:

 

As you can from above - the host and URI string are identical for each request - it's only the attributes in the payload that allow the app server to generate the appropriate token for the specific environment. 

 

I'm using 'x-www-form-urlencoded' type but without the 'post querystring' checkbox enabled.  I can alter the requests and add in the payload's name/value pairs as query parms using the 'post querystring' checkbox if it helps - but essentially it still does the equivalent - posting the queryparms as a payload.

 

Hope I've been clear,

 

rich

 

 

as

nmrao's avatar
nmrao
Champion Level 3
6 years ago

richie 

Provide payload as below

 

resource=${#Project#RESOURCE}
&client_id=${#Project#CLIENT_ID}
&client_secret=${#Project#CLIENT_SECRET}
&grant_type=client_crendentials

You can define property file as show below, and create a file for each enrionment.

dev.properties

RESOURCE=<dev-resource>
CLIENT_ID=<dev-client-id>
CLIENT_SECRET=<dev-client-secret>

And import the above file at project level, refer below documentation

https://www.soapui.org/scripting-properties/working-with-properties.html

 

So, you can similarly, use properties for END POINTS / other varying values per environment into property file and use them in the project as mentioned in the payload content.

 

Now all you need is single project, common test cases. No separate test suites / test cases per environment any more, just use appropriate property file, import them into project before running the tests.

If you are running the tests command line, even properties can be directly loaded runtime without even modifying the existing values in the project.

  • nmrao's avatar
    nmrao
    Champion Level 3
    6 years ago
    richie, have you got chance to try the above?
    • richie's avatar
      richie
      Community Hero
      6 years ago

      Hey

       

      Cheers to nmrao for sorting me out :)

       

      Kudos awarded and solution accepted

       

      nice one,

       

      rich