My SoapUI Thoughts on Effective Testing in SoapUI

Creating A Test Case

This discussion is designed to build a test case that exercises the four common HTTP methods POST, GET, PUT and DELETE on the posts resource. These methods allow us to create a post record, read it, update it, and delete it. (These four operations are so widely applied in working with data that they have collectively become known as the CRUD operations. They form the basis of many data-driven tests.)



  • A test case that creates, reads, updates and deletes post resources

The Posts Test Case

You should create a new test case in your SoapUI project. I’ve called mine simply ‘Posts’. On the test case, create two properties as follows:

Name Value
PropertiesFile posts.csv
resourceName posts

These properties will be used by the datasource script and by the test steps, and will also be used in all subsequent examples in this article.

The REST test steps

Create a REST test step called POST and select the POST request in the New RestRequest dialog. NewRequest02 Configure the new request so that it appears as follows. POSTPosts01

  1. The value of the resourceName parameter must be set to ${#TestCase#resourceName}
  2. The id parameter must be unset.
  3. The Media type must be set to application/json.
  4. The Request Body must be set as shown in the screenshot.

The meaning of the request body will become apparent as the discussion progresses. For now it’s enough to understand that e.g. the ${Props#title} property will refer to a property in a properties test step called “Props” in the test case, created by the datasource script.

Continue creating the three remaining REST test steps for the GET, PUT and DELETE methods as follows.


PUTPosts01 (Note that the only change in the PUT request from the data in the original POST request is in the value of the userId field. A test with real-world data would probably submit data with more extensive changes.)

DELETEPosts01 At this point you can run the test case. Note that this won’t be very meaningful because we haven’t created the “Props” test step used by the parameters in the REST steps, nor do the REST steps contain any assertions. But if you want to confirm that you’re on the right track, the test case should now look like this.


Having created the data rows designed to exercise the methods, together with the four REST test steps to go with them, our next task is to have the data-driven framework iterate over each of the data rows, calling the four HTTP methods once on each row. Let’s create a script to do exactly that.