Multiple testing parameters from external file
Hallo SoapUI,
I have not typical case - I think so.
I have 4 test environments. They differ a little in case of test structure. For simplification we can assume they are the same.
We build cases and the whole scenario for tests.
Generally it is ok - but the problem is - parameters are changing in each environments. So to tune to new parameters we have to spend about 2-3 hours to update config.
It is becoming a little irritating - because the final effect is - testing environment are disjoined and now we have 4 stations with own operators. So it is not possible to unify the solution. My intention is to have independent flexible station to run tests in all 4 environments.
Just in short words - we have different user ID and different Cert ID associated to tests.
So in SoapUI we have sections:
- Environment
- Settings
- Users
- Tokens Associated to User as global parameters
- 80 specific tests CASES which include these user settings.
If the user changes in one environement we have to update user data and user associations.
For now it is not so many users ... about 11 per environment. But we have also to upload user certificate from external sources...
Is there any possibility to dynamically upload usernames into .xml file which stores configuration of the project.
Any ideas how to solve this problem or how to bypass ...
Greetings
T.
- Hey tmssz,
The way i handle this is a project level properties file that gets loaded in immediately before execution.
My properties file contains static properties (like hosts:ports, users, full URLs (if necessary), environments, etc.) and dynamic property placeholders. The dynamic properties are empty of values, the static ones have values. What i mean by dynamic are the environment specific properties that can be identified by querying the environment itself...e.g. GUIDs, auth token values.
I have a disabled "setup testsuite" (disabled so it doesnt run when the project is executed), that generates all the dynamic properties you need which then transfers those values to the project level placeholders.
Each of my functional testsuites have a setup testcase within them and these contain a RunTestCase teststep that points at each of the testcases within the disabled "setup testsuite" (this handles the issue of variables timing out, so each time the project is executed, the functional testsuites call the testcases thst generate the dynamic detail so nothing has a chance to expire.
I use the above approach for every project i create now.
All my teststeps source their properties from the project level properties. This approach means that once youve setup your individual properties files (1 for each environment), and setup your property transfer in your teststeps you never hve to bother updating anything.
Cheers,
Rich
