Forum Discussion

Makhlo's avatar
Makhlo
Occasional Contributor
15 years ago

Best approach for WS testing in soapUI

I have been assigned for automated testing of Web services to achieve the following in soapUI:

Basically before the soap message is send everytime it should be replaced with another test data. For example, if I have 10 test cases, then the next test case overwrites the previous one. Test Case 10 is what I finally see on the screen. The advantage is that you only need one soap request message and through a loop the soap message is refilled with the new test data(data driven) and sent.

The problem I consider now is that for each response message applies different assertions. It’s not possible to have global assertions for all response messages because every response message looks different and therefore it is necessary to have specific assertions for each response message. The problem is that I can’t hold the assertions for the specific response message because it’s then rewritten by the next response message. The response message by testcase 10 is what I finally see on the screen. You got the problem

A possible solution:

• Save each response message separately.
• Get each response message separately and enter the corresponding assertions for that specific respons.

Does anyone have an elegant solution or experience with the above and got it working well ?

Thnx for the time and effort

2 Replies

  • Finan's avatar
    Finan
    Frequent Contributor
    15 years ago
    Not (entirely) sure what you mean, but for data-driven testing you could try the following approach (unfortunately I do not have the time to prepare an example project):

    1.1. Create a testcase with properties on testcase level
    1.2. Add the soapRequest to the testcase. (To fill the properties for the request you can use references, syntax: ${#TestCase#propertyname )
    1.3. Decide on a tactic for the validation, this can be either:
    a: A teardownscript/teststep to export the response (to either the testcase property or a db)
    b: Xpath and/or contains validations to assert the response, these assertions can also use the ${#TestCase#propertyname references for validation.
    c: A groovy script for the validation and script the assertions based on the data entered on testcase lvl.

    2.1 Create a second testcase which will provide the data, (either from a datasource step/database-query/data-generator/etc)
    2.2 add the steps necessary to acquire the data
    2.3 add a script/property-transfer step or use the teardownscript to return this data to testcase-properties

    3.1 Now create the testcase that will combine the previous testcases to an actual testcase.
    3.2 add the data teststep (2.1) to this testcase (run testCase testStep) and select (all) the properties as return values.
    3.3 add the soapRequest testcase (1.1) to this testcase (run testCase teststep) and have the properties from this testStep refer to the data-testStep properties.

    Et voila, you have a data driven testcase, depending on how you want to provide data and/or validate the request, you can alter the approach.

    Tips & tricks:
    1a. If you are creating this setup, use the runmode "primary TestCase" so you can easily "debug" your testcases
    1b. If the testcase performs the way you want it to, use "parrallel" runmode so you can run it simultaneously and reuse your soapRequest testcase for other testcases.
    2 If you'd do not like the setup with the additional testcases, you can add the soapRequest and the datasource directly to your primary testcase.
    b. the disadvantage of this is that it's a bit less easy to reuse the functions of these teststeps for other testcases.

    Good luck on your project, I only use the soapUI pro version, so I do not know if all the functions described above are available for the free version....
  • Makhlo's avatar
    Makhlo
    Occasional Contributor
    15 years ago
    Hi Finan,

    Thanks a lot for the effort you make and the clear explanation. I will implement this and see if it also fits with the keyword driven testing approach.