Forum Discussion

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

Champion Level 3

Long post could not go thru entirely.

But still a couple pointers to look into:

- Not sure why 3 suites are required to Generate Token.

- Difference between each environment is only ENDPOINT, right? Which can be simply replaced with Project level custom property for END POINT.

- And process to generate token is same.

- Having it in one test case (not even need not be a separate suite) will avoid unwanted maintainance.

- Similarly other tests are also duplicated per environment which is duplicate work and increases maintainance

To be frank, you dont even need to use Environments feature (sorry to say this). This can be simply achieved by using custom properties.

Please refer below thread (answer) on how to use the same tests for different environments without having to use Environments feature, with just use of different property file (per environment)

https://stackoverflow.com/questions/37655778/soapui-ability-to-switch-between-database-connections-for-test-suite/37659250#37659250

richie

Community Hero

6 years ago

Hey Rao,

sorry - I will try and be clearer - with this in mind, I will answer your specific queries inline

- Not sure why 3 suites are required to Generate Token.

RichAnswer: I have 3 different requests for my setup REST request (inasmuch that the payload on these requests contain different queryparm values - the 3 requests generate a token for the different environments. I'd separated them into separate testsuites just so people viewing my work could see what I was doing. I don't want to have 3 requests - I want 1 request (just like I have only a single instance of each actual test) - but I cant use the override function for this because....see next answer!

- Difference between each environment is only ENDPOINT, right? Which can be simply replaced with Project level custom property for END POINT.

RichAnswer: No - the endpoint is identical for the setup step tests that generate the access tokens for the 3 differnet environments - its only the content of the payload that differs. Essentially I'm trying to misuse the environments override functionality because i only want 1 setup test which generates the tokens for the 3 different environments - but currently if I only had 1 instance of the setup test (which generates the token), then I would have to manually alter the queryparm values in the request depending on which environment I wanted to test.

- And process to generate token is same.

- Having it in one test case (not even need not be a separate suite) will avoid unwanted maintainance.

RichAnswer: absolutely - which is why I only want 1 test....who wants extra work with no advantage? Which is essentially the reason for my post - I dont want 3 different requests for the different setup test. I want 1 copy - but cos the parm values on the request generates the environmetn specific token - if I have 1 setup test - I need to manually change the values.

- Similarly other tests are also duplicated per environment which is duplicate work and increases maintainance

Don't bother with the environments functionality? ok - cool, cheers for the link - I'll check it out!

rich

nmrao
Champion Level 3
6 years ago
Will be able to comment only if the screen shot of REST Request is available which consists parameters / payload and what differs for each environment.
- richie
  Community Hero
  6 years ago
  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
    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
Champion Level 3
6 years ago
If values are different for each enviornment, custom properties at test case, test suite and project level are there to deal with them.