This tutorial will teach you how to pass on information from a soapUI Runner, such as TestCase Properties or cookies, to subsequent Runners (or other components). This tutorial will continue from where Getting Started with soapUI Integration left off.
0.1. Video Tutorial
The second half of this video cover some parts of the written content below.
0.2. The soapUI setup
We will use a simple soapUI Project, consisting of two Testcases: Login and Logout.
The Login TestCase first fetches a user from a database and then sends a Login request to a server. Finally, a Property Transfer TestStep saves the session-ID that it got back from the server to a TestCase Property called sessionId.
The Logout TestCase just consists of one TestStep: A Logout request using the TestCase Property sessionID as a parameter value. Please note that it's crucial that both of the TestCases have a TestCase Property with the same name!
The Logout TestStep also has a Not SOAP Fault assertion set, which will fail the TestStep (and thus the TestCase) if the server responds with a SOAP fault. This will happen if the server is requested to end a user session that is not active.
0.3. The loadUI setup
This is the setup that we will use in loadUI:
The exact setup does not matter; the important thing is that:
- We have one soapUI Runner connected (directly or indirectly) to another soapUI Runner.
- The second Runner's needs a value from the first Runner (in this case the sessionId TestCase Property).
That will do, now let's hit that Play button!
You will be able to see the execution count for each individual TestStep:
The second soapUI Runner's requests now completes without failing (i.e. Completed increases and Failures is 0), which mean that it works!
Just to be sure, let's intentionally break the property passing by disabling the Property Transfer TestStep. Remember, this is loadUI, so there is no need to stop the test before doing this:
As expected, the Failed counter will now start increasing on the second soapUI Runner.
0.5. Behind the curtains
You will now learn what happened behind the curtains when we disabled the Save session TestStep. To be able to see which values a Virtual User carries, we have routed them through Table Log components. To make it easier to follow, we have also simplified the structure of the scenario.
We trigger a single Virtual User in the first Runner by clicking Run Once...
- As expected, the first two TestSteps was run, but not the third one .
- In the following Table Log, we can see that the sessionId was never passed along from the Login Runner. If we would not had disabled the Save session TestStep, the sessionId field would contain some number.
- When the Virtual User arrived to the Logout Runner, it sent the logout request , but with a blank sessionId parameter.
- The server responds with a SOAP Fault, since the request is invalid. Our soapUI assertion Not SOAP Fault triggers and fails the Logout TestCase .
- The right-most output of Runners is called the Errors output. It spits out an error message each time a Failure occurs. Sure enough, we can see the Not SOAP Fault error message .