khurlburt
10 years agoOccasional Contributor
[Res] Help with setting variable endpoint based on environm
Hi,
I need to be able to run a SoapUI Pro Test Suite based on two different variables:
1. Environment
2. Endpoint for the environment: To be clear: the same environment can use different endpoints for the same service.
In addition, I would like to be able to execute the same Test Suite both from the command line AND from within SoapUI ideally without any manual manipulation of the test itself. (I am OK with disabling a test case for the purpose of the test being available for the command line.) I have accomplished the above goal for the command line only using the following command:
testrunner.bat -r -EQA -PCPServiceEndpoint=https://mck-cs-customer-profile-qa.cloudapp.net "C:\Users\ehda1tq\Desktop\SoapUI projects\CustomerProfile.xml"
(where "QA" is the environment and "CPServiceEndpoint" is a project-level property). This works. I can execute the above command using whatever environment and endpoint I like.
The problem is trying to execute the exact same Test Suite from within SoapUI itself (versus the command line). I cannot populate the CPServiceEndpoint project property with the desired endpoint at the time that I am trying to run the test. I have tried using a a property transfer step and this doesn't work. Example:
Preconditions:
- CPServiceEndpoint is a custom project-level property
- My service endpoint is set to ${#Project#CPServiceEndpoint} also at the project level.
- Using the CPServiceEndpoint property (as the value for my service endpoint) allows me to successfully pass in the endpoint from the command line (to be used by my Test Suite) as shown above.
To allow the same exact Test Suite to be run from within SoapUI I did the following:
1. Created a new project property "X"
2. At the project level, for each (of my 4) environments - assigned "X" the hardcoded value for the endpoint
3. Switched my active environment to Default
4. In my Test Suite - created a brand new property transfer step to assign the value of "X" (based on the active environment) to CPServiceEndpoint
5. When I run the Test Suite, it doesn't work because the source value "X" is missing.
6. I determined that the issue in step 5 (value of "X" missing) is because I created the property transfer while the active environment was "Default" SO onto step 7
7. Switched my active environment to Stage & repeated step 4
8. It did work for Stage (because I created the property transfer step while Stage was the active environment) BUT the 3 other environments do NOT work since the value of "X" being transferred to CPServiceEndpoint is for Stage only
I also tried writing a Groovy script to circumvent this property transfer issue (described above). However - I am new to SoapUI and was not able to successfully do this. Nor am I sure that this is the best approach. What is the best way to set CPServiceEndpoint project property to a specific (hardcoded) value BASED ON ENVIRONMENT to be used every time the Test Suite is run manually?
As I said - I am new to this - any tips/advice would be greatly appreciated.
Thanks,
Kelli
I need to be able to run a SoapUI Pro Test Suite based on two different variables:
1. Environment
2. Endpoint for the environment: To be clear: the same environment can use different endpoints for the same service.
In addition, I would like to be able to execute the same Test Suite both from the command line AND from within SoapUI ideally without any manual manipulation of the test itself. (I am OK with disabling a test case for the purpose of the test being available for the command line.) I have accomplished the above goal for the command line only using the following command:
testrunner.bat -r -EQA -PCPServiceEndpoint=https://mck-cs-customer-profile-qa.cloudapp.net "C:\Users\ehda1tq\Desktop\SoapUI projects\CustomerProfile.xml"
(where "QA" is the environment and "CPServiceEndpoint" is a project-level property). This works. I can execute the above command using whatever environment and endpoint I like.
The problem is trying to execute the exact same Test Suite from within SoapUI itself (versus the command line). I cannot populate the CPServiceEndpoint project property with the desired endpoint at the time that I am trying to run the test. I have tried using a a property transfer step and this doesn't work. Example:
Preconditions:
- CPServiceEndpoint is a custom project-level property
- My service endpoint is set to ${#Project#CPServiceEndpoint} also at the project level.
- Using the CPServiceEndpoint property (as the value for my service endpoint) allows me to successfully pass in the endpoint from the command line (to be used by my Test Suite) as shown above.
To allow the same exact Test Suite to be run from within SoapUI I did the following:
1. Created a new project property "X"
2. At the project level, for each (of my 4) environments - assigned "X" the hardcoded value for the endpoint
3. Switched my active environment to Default
4. In my Test Suite - created a brand new property transfer step to assign the value of "X" (based on the active environment) to CPServiceEndpoint
5. When I run the Test Suite, it doesn't work because the source value "X" is missing.
6. I determined that the issue in step 5 (value of "X" missing) is because I created the property transfer while the active environment was "Default" SO onto step 7
7. Switched my active environment to Stage & repeated step 4
8. It did work for Stage (because I created the property transfer step while Stage was the active environment) BUT the 3 other environments do NOT work since the value of "X" being transferred to CPServiceEndpoint is for Stage only
I also tried writing a Groovy script to circumvent this property transfer issue (described above). However - I am new to SoapUI and was not able to successfully do this. Nor am I sure that this is the best approach. What is the best way to set CPServiceEndpoint project property to a specific (hardcoded) value BASED ON ENVIRONMENT to be used every time the Test Suite is run manually?
As I said - I am new to this - any tips/advice would be greatly appreciated.
Thanks,
Kelli