Test Automation Using SoapUI – How-To Guide

Hello! My name is Alexander Krylov, I am a Siebel CRM developer at Moscow Credit Bank.

After developing the next task, which is entirely based on integrations, we were faced with the question of functional testing before transferring it to full testing. The task was quite large, consisting of a dozen services, each of which was closely related to the previous business logic.

Just in case, I’d like to emphasize that test automation plays a key role in modern IT projects (in case anyone hasn’t guessed). This allows teams to speed up the testing process and improve product quality by increasing the number of test cases passed.

And just one of the powerful tools for testing web services is SoapUI, which offers ample opportunities for working with SOAP and REST. services. In this article, we'll look at how to effectively automate testing using SoapUI and integrate it into your CI/CD process.

So let's get started!

For example, let's build a simple service that checks a number – if the number consists of 3 characters, then the service will return Status – OK, otherwise NOT OK, and ERROR if internal errors are received.

Putting together an autotest

First, you need to add a new TestSuite to your project (right-click on your project in the project tree):

Next, you need to create a TestCase on the created TestSuite. Added from the list when you right-click on TestSuite.

This is where the main logic of interaction between the steps of the case will take place. You can create more than one TestCase and describe different cases. The name speaks for itself.

After creating the case, you should get the following result:

Steps need to be added to the case itself. Let's add an XML request, fill it in Groovy scripts, condition on the parameter from the response, and execute the request in the database after 1 second when the OK status is received.

Additionally, we will add response validation and autotest parameterization, but first things first.

Adding steps

In the case window we can add steps that will be performed in order:

We will need Properties, Groovy Script, SOAP request, Conditional GoTo, Delay and JDBC request:

After successfully creating the steps, each one needs to be configured. Access to the setting opens after double-clicking on the required step.

Properties

The Properties step does nothing; it is needed to store some data while the case is running. For example, UZ data or service address. Let's add them to our case:

SoapUI has an interesting feature: if you name the parameter “Password”, its value is masked.

We can also store the parameters themselves not only at the case level, but also higher in the hierarchy. For example, at the project level or create global ones for the application.

For our purposes, we will limit ourselves to case-level parameters.

Groovy Script

Groovy is a java-like language that greatly enhances the capabilities of SoapUI. In our example, we implement the generation of Number.

In order for the service to return different statuses, we will generate values ​​from 900 to 1100 and substitute them into the new parameter of the Properties step:

If the parameters used in the scripts are not created or deleted, the script will create them.

SOAP Request

Let's move on to the most interesting part – filling out the XML and setting up the entire request window.

Previously, we created parameters, now we have to use them. You can specify them anywhere and SoapUI will understand you.

Let's fill in what has already been created and make a test call to the service.

The service responded successfully, now let’s fill in the MessageId, also using generation, but in a different way.

In addition to specifying parameters in the request, we can write executable code. Here are some useful features:

We use the first one for MessageId:

To see what was inserted into the request, use the Raw tab:

For the current step, it remains to configure the validation so that when the ERROR status is received, the autotest stops.

Let's select XPath Match:

Now the autotest will stop if the service responded with ERROR status, in other cases it will continue to work.

Conditional GoTo

Next, according to the condition, we need to repeat the generation and send a second request after receiving the NOT OK status; the Conditional GoTo step will help us cope with this:

We have added a condition: If the status from the response is NOT OK, then go to the Groovy Script step, that is, go back 2 steps.

We will not add a condition to the OK status; the autotest will go to the next step without it, since it will not find a single suitable condition.

Delay

Above I wrote that we need to execute a query in the database in 1 second if we have passed the condition.

The Delay step is a regular timer that stops the execution of the case for the time specified in the settings. Specified in milliseconds:

We will consider executing the request below.

JDBC Request

To execute a query in the database, we need to place the JDBC driver from the required database in the folder for the SoapUI application.

Next, open the settings window and specify the driver, connection string and the request itself.

Like the service address above, the connection string and the driver, I put them in the parameters:

Since this is also a request, you can extract parameters from the response and process them in the case, but in the example we will not do this.

Validation is also present here. Apart from setting up a connection to the database, all settings are similar to the settings for a SOAP request.

Additionally

Also, in the example above, we did not consider transportation.

SoapUI allows you to do this using the Property Transfer step:

The image shows the setup for writing the MessageId parameter from the response to a SOAP request to the MessageId parameter of the Properties step.

This step can be useful, for example, to carry identifiers from a response to the next request.

Launch and results

In order to launch the entire case, you need to launch it in the case window:

FINISHED – means successful completion of all steps. The case logs describe which steps were performed and in what order. In case of errors, the status FAILED will be displayed.

After full setup, we got a full-fledged automated case, which:

• Generates information for a SOAP request;

• Performs a SOAP request;

• When receiving the ERROR status, it stops;

• When receiving the status NOT OK – starts from the beginning;

• When receiving the status OK – waits 1 second and executes a query in the database;

Tips from the “thank you, I’ll think about it” or “best practice automation testing in SoapUI” sections:

1. Data Validity Checking: Use various checks to ensure that the data returned by the service is correct.

2. Decomposition of tests into projects: if there are many services, but they are not related, then it is worth dividing them into several projects.

Test automation with SoapUI is an effective way to improve development quality and speed up the release of new software versions. Using Groovy's power for complex scenarios, you can create a powerful automated testing process that works without your constant input.

If you have experience automating testing in SoapUI, share it in the comments. What tools and practices do you find most effective?

PS Test automation is not just a trend, but a real necessity in the context of the accelerating pace of development. Using SoapUI, you can significantly optimize your processes and improve product quality.