To my understanding loading end points from a config file is good way if you're working with SOAP UI Community edition ( Which do not have environment feature)
The very purpose of environment module is so that you can hard code environment specific values like end point.
For example - let's say your a service where end point changes in 3 different environment DEV, QA, UAT
you should just hard code those end point values for each ENV
dev : http://dev.mysevice.com
uat : http://uat.myservice.com
Even if some of the url changes, you have only one place to update. Just like your good old properties file.
But once you have set up everything in enviornment module you have option to just flip the environment selected using a drop down menu ( or a command line argument if you're using testrunner.bat/ testrunner.sh ) without the trouble of updating the property list everytime.
Another way is to add each environment specific end point to Global Properties and pass those values to each environment. That way you can handle changes better, especially if same end points are used in multiple projects.
There are many ways you could do this. But the approach mentioned above has served me well for years.
Cheers!
Gilu Gopi
Thank you for the detailed reply. Config File approach was in place due to SoapUI OS. As you explained, I did evaluate Environment module. This question was out of curiosity.
Again, you have mentioned that "Another way is to add each environment specific end point to Global Properties and pass those values to each environment." - I am familiar with Global properties and calling them in my scripts or test steps. But I didn't understand how it is different from passing a project property to environment.
thanks!
Basically anything which is to be shared across projects is better to be stored as a Global Property. Then you don't have to keep all project level property files and have overlapping information in all of these
Let's say we have a customer service which is used under multiple projects, and need to be executed in multiple environments. I would store these end points in Global Properties . Ex
customer_dev : dev.customer.myservice.com
customer_qa : qa.customer.myservice.com
Then in each of the project I use customer service, I'll have project level property for customer end point to be used under environments.
Each environment end point would be like
DEV Env > customer : ${customer_dev}
QA_Env > customer : ${customer_qa}
Later down the line if your project changes server hosted or you have to hit a loadbalancer URL you only have to modify only one global property and all projects would be up to date
For example customer_dev : devloadbal.customer.myservice.com:8440
But all of these are optional if
1. you are not using same end points in multiple projects
2. your project end points are not likely to change.
Cheers-
Gilu Gopi
