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
