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

[richie]

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, methods and requests.

I have 3 different environments - dev, test and integration (see screenshot entitled Capture4.png), so rather than duplicate the tests (1 copy of the tests for each environment) I'm using the Environments override which allows you to specify which host is peculiar to which environment.

My MS Dynamics CRM has 3 instances - 1 for dev, 1 for test, 1 for integration  - see below:

https://whatevs-dev-exp.crm4.dynamics.com/  = dev
https://whatevs-test-exp.crm4.dynamics.com/  = test
https://whatevs-integration-exp.crm4.dynamics.com/  = integration

This is fine and works great for 17 of the 18 REST Services - but doesn't work for 1 of them.  The 1 relevant REST Service is not used to test - but it's a setup testcase to generate the access token my actual tests need to get through the authorization/authentication.

The 1 REST service that is my setup service (to generate the access token to hit the CRM's via the webAPI (to hit the CRMs listed above)) is described below and the request (both host and the URI string) is identical for each environment - e.g.

https://login.microsoftonline.com/someGUIDvalue/oauth2/token

So - rather than the 'host' (or even the URI string) determining what environment is being used - its the content of the payload (e.g. resource, client_id and client_secret) that provides the details allowing the actual tests to hit the CRM successfully.

The https://login.microsoftonline.com/someGUIDvalue/oauth2/token request's payload for the 'test' environment is as follows:

resource=https://whatevs-test-exp.crm4.dynamics.com
&client_id=d86d999-f520-4708-946a-e013d5f12ff0
&client_secret=Cep6ZhZoYV%2F385ia%2FGCJWWW9X7ryu8u3p7GWDr%2BwCww%3D
&grant_type=client_credentials

At the moment - I have 3 different testsuites with a single test cases (1 for dev, 1 for test, 1 for integration) containing a single REST request with the above payload (see screenshot entitled Capture.png). 

Currently, depending on which environment I'm testing, I disable 2 of the 3 Generate Access Token test cases because I pass the Access Token generated from these environment specific requests to a single Project level property and all the tests in my project point to this single Project property for the Authorization header value in my requests (see screenshots entitled Capture2.png & Capture3.png)

I was wondering if anyone knew how to configure the request in my project so I can use this via the Environments override, but rather than the host determining which environment is being hit, instead its the content of the request determining the environment?

I understand that part of the problem is that I've setup the saving of the Access_Token to a single Project level 'Authorization' property, so when my setup test executes to generate the token - it overwrites the previous token value and all my tests point to that single project level property meaning that I always have the latest token (as long as I execute the correct environment specific setup testcase to generate the token).

I did consider having the 3 environment specific Access Token generation tests writing to 3 individual project level properties (e.g. CRM_Token_Test, CRM_Token_Dev and CRM_Token_Integration) - 1 for each environment - but I can't see an efficient way of pointing my tests to the correct access token property. (remember - each of my tests has a POST which needs the correct access token value)

Have  any of you come across something like this before where it was the payload that provided the project specific detail and so no easy way to use the Environments override?  If I enable all 3 access token test cases - the last one in the sequence will overwrite the others - so that won't work.

I need to get this ReadyAPI! project into a CI/CD pipeline sooner or later - so I need everything to be automated as possible - I can't be manually changing things (like enabling and disabling testcase/testsuites) each execution run to pick the correct testsuite to run depending on which environment I need to execute the tests in.

I'd welcome any thoughts anyone has on this, cos I just cant see a way forward.  Strictly speaking I can see why this doesn't work for this access token request - the request runs in all environments - the request isn't environment specific - its just the payload of the request that determines the environment specific token and my problem is that I only have 1 project level property - I just can't see a more efficient way of doing this.

I hope I've been clear..... 🙂

cheers,

rich

[nmrao]

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

[richie]

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]

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.

[nmrao]

If values are different for each enviornment, custom properties at test case, test suite and project level are there to deal with them.

[richie]

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 · Accepted solution]

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

@richie, have you got chance to try the above?

[richie]

Hey

Cheers to @nmrao for sorting me out 🙂

Kudos awarded and solution accepted

nice one,

rich