Last july I
wrote about setting environment depended properties in SoapUI. I'm looking for the best way to make SoapUI testcases environment independend and to make it easy to switch between target environments.
In that
article I suggested to create a set of properties with the actual working values on project level to be refered in the endpoint urls (hostname:port
+ URI), username/passwords and so on. And per environment a distinct set of the same properties holding the values of that target environment. Then I created a test case per target environment that copies those target-environment values to the working properties.
This works fine for me. However, in my quest to the most comfortable way of registering and toggling between those values, I found a few enhancements quite convenient.
First of all, after the property-transfer step, I created a manual step, listing the values of the working properties, with a remark that it should contain the values of the particular target environment:
My Localhost version of this testcase will run into:
Don't forget to click 'Ok' after this step. Unfortunately I did not find a way to increase the 'Expected Result" Textarea.
The second enhancement was that I moved my Target Environment property values to the "set
Environment" test case. I found that with an increasing number of properties it is quite hard to have a clear overview of the properties. And I need to think about a proper naming convention. But when I moved those to the "setEnvironment" test case I have a distinctive set of properties per environment and on project level a distinctive set of working properties.
Since the testcase is environment-specific, I don't need a target-environment reference in the property-names. And also, they are scoped and thus not referable within other testsuites/testcases, preventing errors.
Moving those properties in SoapUI is pretty labor-intensive. But moving those in the source is quick (and dirty). If you open the SoapUI project xml file, you'll find the project-properties at the bottom of the file:
For instance:
<con:properties>
<con:property><con:name>CSServiceURI</con:name><con:value>ContentServer/PS_StoreDocumentToCSStage_v1</con:value>
</con:property><con:property><con:name>CSServiceHost</con:name><con:value>localhost:7001</con:value></con:property>
<con:property><con:name>CSUser</con:name><con:value>svc_GSA</con:value></con:property>
<con:property><con:name>CSPassword</con:name><con:value>welcome1</con:value></con:property>
<con:property><con:name>CSHost</con:name><con:value>localhost:8088</con:value></con:property>
<con:property><con:name>CSAuthenticationURI</con:name><con:value>ContentServer/Authentication</con:value></con:property>
<con:property><con:name>CSSearchServiceURI</con:name><con:value>ContentServer/SearchService</con:value></con:property>
<con:property><con:name>CSDocumentManagementURI</con:name><con:value>ContentServer/DocumentManagement</con:value></con:property>
<con:property><con:name>CSAuthenticationToken</con:name><con:value>TsiKqmREU78MhR4Po%2FJFlsv3OzGUAnDsDsPDcymSnxI%3D</con:value></con:property>
</con:properties>
Copy and paste the properties to move (since I did so allready you'll don't find my target-env properties here anymore) to a seperate file to get them together.
Then find the target-testcase in the file (in this example "SetLocalEnvironment"):
You'll find at the end of the testcase an empty properties element (<con:properties/>). Open it up (<con:properties> </con:properties> ) and copy and paste the properties within the element.
SoapUI doesn't do formatting of the xml, so you might want to add line-feeds like I did in this example.
Finally you need to change the property-transfer-lines. In the example above, you'll see that I found the transfer-step and added line-feeds for each "<con:transfers ..."
<con:transfers setNullOnMissingSource="true"... some other properties... ><con:name>CSServiceHost</con:name><con:sourceType>CSServiceHost-Dev</con:sourceType><con:sourceStep>#Project#</con:sourceStep><con:targetType>CSServiceHost</con:targetType><con:targetStep>#Project#</con:targetStep><con:upgraded>true</con:upgraded></con:transfers>
You'll find in this line the source step: "<con:sourceStep>#Project#</con:sourceStep>" and target step: "<con:targetStep>#Project#</con:targetStep>".
Change the value of the source step to: "<con:sourceStep>#TestCase#</con:sourceStep>". Now the property is refered from the testcase instead of the project. The property on project level can be deleted.
Renaming the properties can better be done from the UI, since SoapUI will then change the property-name also in every reference. Even in soap-requests. So after changing the file in your ascii-editor reload the project in SoapUI. And make the final changes and do the tests.
Now, although this is a nice example of source-hacking from outside the UI, you can't expect any support on this of course. So enable a proper version-control and test the SoapUI properly.
