My SoapUI Thoughts on Effective Testing in SoapUI

Duplicating a Test Case

In this article I want to show the value of a data-driven configuration when implementing tests for new resources.

Prerequisites

  • A test case configured to test the posts resource

Goals

  • A test case configured to test the todos resource
  • An understanding of the value of accessing the service definition via template parameters.

One of the resources supported by the JsonPlaceholder API is the todo. We can assemble a set of test data for this resource in a file called todos.csv as follows.

id,userId,title,completed
1,51,Complete tax return,true
2,52,Pay parking fine,true
3,53,Attend job interview,false
4,54,Attain world peace,false

You’ll note that the field names on the first line are similar, but not identical, to those used in the test data for the post resource. With the datafile saved, now do the following:

  1. Clone the Posts test case and change its name to Todos.
  2. On the new Todos test case, change the properties so that PropertiesFile → todos.csv and resourceName → todos.
  3. Optionally, delete the Props test step. It contains properties from the Posts test case which are no longer relevant, and the step will be automatically regenerated when the script runs.
  4. Update the request body in the POST and PUT steps to refer to the todo data fields as follows:
{
    "title":	"${Props#title}",
    "userId": 	${Props#userId},
    "completed":  ${Props#completed}
}

After these actions are complete, you should now be able to run the new test case on the todo data.

A moment of reflection

It’s worth taking the time at this point to review the elements of our configuration that have allowed the duplication of the Posts test case with so little effort. The principles of data-driven design apply not just to the test data but with equal benefit to the configuration itself. We configured the requests in the service definition to specify the resource names in the endpoints via template parameters (${resourceName}). We then populated these resource names via a test case property (${#TestCase#resourceName}). This approach is itself a form of data-driven design and greatly promotes the development of tests that are extensible and maintainable.

By now, your project tree should look like this. TestSuite01 Hopefully, this process has been sufficiently straightfoward to demonstrate the ease with which a data-driven implementation can be re-purposed with new sets of test data.

Other Approaches

The use of SoapUI for data-driven testing is so widespread that many people have made their solutions available online. I invite you to review some of these contributions and compare them to the approaches I show in this article and in other articles in this site. You can make your own judgement about their scalability and ease of maintenance.

The two following implementations are of particular note in that they show what not to do. By the way, note the suspicious similarities in the code in these examples.

(The first implementation reads CSV files and the second reads spreadsheets, but neither of them use the import XmlHolder statement slavishly copied in the first line. If you look closely at the logic you’ll see that the redundant import statement is the least of the problems with these implementations.)

One quick test I apply when assessing a scripting approach is to see if the script makes reference to specific data fields. If it does, it doesn’t meet my expectations regarding maintainability.

As a way of making our scripts even more maintainable, I’d like to introduce the topic of scripting with classes.