Data driven testing using SOAP-UI
Background
Some of the key challenges during testing a web-service or an API are listed below:
- Back-end availability - This generally happens when your service code is ready but the back-end isn’t. In such cases, you will generally mock your back-end.
- Different data across environments - This is a common pain point that I hear most of the time. This post will try to address this issue using SOAPUI
- Different URLs across environments - Although test cases aren’t directly related to a target environment(generally), but test data and API urls are directly related to environment. In this post, I’ll be talking more about these two pain points. Keep reading & taking notes.!
In this post, I'll talk to you on how to use SOAPUI to perform dynamic data driven web service or API testing. In this example, I'll test a very simple web-service that returns details of a customer, given a valid customer Id.
First of all, you'll need SOAPUI. It can be downloaded directly from this location. Make sure to select the appropriate version of the OS while downloading. After finishing the installation, you can import the project – it's available in my GitHub repository.
Some Basics
This post is not a starter's guide to SOAPUI – it assumes you have basic understanding of SOAPUI. Before getting started, let's understand the problem that we aim to solve. Firstly, a web-service is usually deployed across a number of environment; thus having a different URL. In addition, each environment has a different set of data.
Hence, every-time you want to test a service in a given environment, you must change the endpoint and data to perform the test.
In the example here, the customer service has different set of customers in local, development & test environment and is accessible via different URL's.
WHY SOAPUI
I find it easier to setup & use. It has a free version & a commercial one too. In this example, we are using the free version.
GET STARTED
The customer service SOAPUI project looks like this
As you see above, there are 3 steps in the test case. The first step is to define the properties, second being the load of data from the property file & third is sending the actual SOAP/REST request to the web service.
Under the custom properties section on your SOAPUI, select the last button to load properties from an external file. Point it to the file that contains the properties & select the check boxes before pressing okay. There is one property for each environment. Each property refers to its own data file that is specific to an environment. Refer to the image below for more information.
So far it looks good, now the question arises that how the request payload does reads this data. The answer is simple – SOAPUI provides you an easy way to refer to dynamic properties using scripting. Look at the screenshot below