Modularization, Action and Keyword Testing in soapUI
Test and Monitor | Posted March 13, 2012


Consider this scenario for Functional and Load Testing (this is an actual user issue from the loadUI forum):

  • Login (get session id)
  • Ping server every 10 sec
  • Run transaction A every 30 sec
  • Run transaction B every 15 min
  • Repeat for 1 hour
  • Logout

The first requirement is for us to use the session id we got back from the login in other actions.The actions ping, transaction A and transaction B cannot be executed in sequential order which is how tests in soapUI are built normally. Actually they are independent from each other and they need to be executed in parallel (at the same time).
So how do we do this? How do we create a solution where the test is executed in parallel in soapUI?


Creating a Solution

Since all steps required for solving this are independent from one another, except for the fact that they all need a correct login id, they can be treated as independent actions. Once we realize this; that it's not a chain of events, that they are all separate and dependent on the response from login, we can reformulate the problem as such:

  • Login Action
  • Ping Server Action
  • Run Transaction A Action
  • Run Transaction B Action
  • Logout

Login Action

For each of them I'll create a separate TestCase and put them in the a same TestSuite. For the Login Action our requirement is to store the loginID obtained from the login request in a loginID property at the project level in order for us to have it easily accessible to any TestCase in our project.

Ping, Transaction A, Transaction B

The new TestCases Ping, Run Transaction A and Run Transaction B are configured to not stop if any TestStep in them fails and also to propagate success of their operations. Actually success is not that important but certainly some validation is required. Also, at the TestSuite level we need to add a property which serves to indicate whether the TestCases should continue running. We can name the property to run and set the initial state of the property to true. The property will be monitored by all three TestCases. Just to make things more modular, let's add a TestCase property in each of them for holding pause length between two executions of the same TestCase (for Ping 10s, etc.).


This test case will just execute a logout request using loginID.

Putting it all together

So we have the VirtualUser TestSuite as seen below:

Ping, Transaction A and Transaction B almost look the same. What you need is a DataSource TestStep to generate values based on the value property run in the TestSuite's properties. In our case the best option is to use a Groovy Data Source. We'll also add a delay TestStep to handle pauses:

Now, let’s put all this together in a new TestCase, named Scenario:

The example above shows a Groovy TestStep to start pinging, and transactions since we need them to run in parallel. This can be handled in Groovy. If we run them in soapUI the usual way, for example as the Login TestCase mentioned above, they will be run in sequential order. Also, in Groovy script we can manage the fact that we need the test duration to be for one hour.
So, what we've done here is broke down the scenario into small, atomic type operations (actions). These actions are usually parameterized, and have a result that can be used by the following actions. The parameters are kept at a TestCase or higher level in order for them to be visible to all other actions. With a setup like this we have the option of reuse; these actions can be used to create other scenarios, or to modify scenarios, just by changing the parameters.


Modularization, Action and Keyword Testing

What happens over time as you become a more and more sophisticated tester, is that many soapUI projects tend to get quite long and complex. This is good; it’s a sign of you becoming more skilled and more intricate in your use of soapUI. You might start trying to create scenarios like the one we’ve taken a look at above, or they can become even more complex. What they all have in common is they all try to create a complex scenario, (which of course is just a test describing a complex business case) in one single test case. Even if you are using a modular approach like we’ve done here and take advantage of the strengths of the Run TestCase TestStep it can still be quite complex when you try to combine all modules into one single scenario.

A good practice is to plan your test to be in atomic operations and actions, and to keep them all in separate TestSuites from the scenario TestCases. Please note that each action has a set of input and output parameters and that these are uniquely identified by a TestSuite and TestCase name. Knowing and using this I gain the ability to create more complex actions that can be used elsewhere. This is modularization; creating tests by building logical blocks small enough to be used as building blocks in big, complex scenarios.

If we go back and look at the scenario above we notice that it has two characteristics: duration and a set of actions. A good way to look at a set of actions is the following view:

TSName1, TCname1, para1Name, para1Value, para2Name, para2Value…

TSName1, TCname2, para1Name, para1Value, ...

TSName2, TCname1, para1Name, para1Value, ...

TSName2, TCname3, para1Name, para1Value, ...

This looks like a good candidate for an Excel sheet or a CSV file. Since the soapUI API is accessible from Groovy scripts the scenario we've looked at can be executed like this:

  • A DataSource TestStep to read scenario
  • A Groovy script to execute actions
  • Loop the DataSource

Please note that if you have a setup where the execution TestCase is in the same TestSuite as the TestSteps with actions, or if you have only one TestSuite containing just actions, the first column is not needed. If each action has the same number of parameters columns and the same parameter name, this column can be skipped. This is an example of how keyword or action driven testing can be achieved in soapUI. The main point being to make testing more transparent and fun.

With an approach like the one we've just examined we have the following benefits:

  • Test scenarios are moved outside of soapUI
  • Maintenance is easier
  • Anyone can create tests
  • Test scenarios become more understandable




By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox