SOAP-UI
Intro
In the previous project I have experienced soapUI as a low cost but very effective test tool for Cordys BOP-4 solutions. The abilities to invoke web services and test the result from outside the Cordys environment are very convenient. The features to define test scripts make it a very powerful tool to run automatic tests (e.g. for regression tests)
SOAP UI is build around uses an hierarchy of test objects: Each level contains 0 or more of the lower level objects:
1. Project
2. Test-suite
3. Test-case
4. Test step.
Test steps
In the Test Steps the effective test actions are defined. Test actions may for instance be:
Properties
Properties contain values that can be used in the tests by a reference to the property. There are system and user defined properties. Properties are always related to one of the test-object types mentioned above and available to all object beneath it in the hierarchy.
A convenient application of properties are end-points –URLs for the web services that are tested. This way it is possible to test web services from another (DTAP) environment simply be changing this property.
Cordys Case
It was my intention to use SOAP UI to test my state-transition model, as described in my earlier BLOG-s. Testing it involves injecting numerous messages via SOAP, and check whether the correct state transition (or error) was invoked.
Initial approach
May first approach was to build test cases that consisted of multiples series of 3 steps:
This approached worked: I was able to work out a number of scenario’s that covered most of the functionality that I wanted to test.
As my state-diagram was pretty extended (consisting of 17 states) I experiences a number of disadvantages:
Building was toilsome, defining similar steps for each state transition to test
The test scenario is hard to read, as only the title of each step is visible, and the vision is blurred because of sequences of 3 steps.
The scenarios were relatively hard to maintain, every time replacing 3 steps in case of a change.
Optimization 1
This led to a need of being able to define the sequence of the test offline, in a file, were only the vital data would have to be specified.
This approach enables to maintain and store the test sequence in a text, making the scenario much more visible and way easier to modify (e.g. simply by inserting some lines)
The solution I developed used the following capabilities of SOAP UI:
The main idea is simple:
Recognize and separate the repeating steps in the test case. Extract one instance of the repeating steps and isolate them in a separate test case (“TC1”)
Replace all required hard-coded values by a property
Define an external file having sets of lines containing values that may on the defined parameters
Build a "groovy" script that reads each line, sets the according parameters and executes TC1
The file now consisted for each state-transition-to-test of a line of multiple properties in a fixed order. Each line was processed by the groovy script and assigned to the properties, before invoking the 3-step test sequence in TC1.
This approach worked fine.
The only disadvantage was that in the sequence certain properties remain the same for a long period of time (e.g. the correlation id of messages, which is the same for all steps in the same sequence).
Optimization 2
The perfectionist in me decided to make the test script more fancy and general purpose, so I added the following options:
#plist,<property-1>,<property-2>, … <property-N>
#property,<property>,<value>
#unique, <property>
//<Any comment>
An example of an input file is:
// MessageId is always unique
#unique, messageId
// For the first sequence we always use the same sequence id
#property,correlationId,cor01
// Each value line contains values for the properties messageType,Sender,Receiver
#plist,messageType,Sender,Receiver
MT01,Party1,Party2
MT02,Party2,Party1
MT01,Party1,Party3
MT02,Party3,Party1
MT03,Party3,Party4
MT04,Party4,Party3
// Now we addone property to the value lines: The correlation Id.
// The pre-set value is overruled now
#plist,correlationId,messageType,Sender,Receiver
Cor02, MT01,Party1,Party2
Cor02,MT02,Party2,Party1
Cor03,MT01,Party1,Party3
Cor03,MT02,Party3,Party1
To provide an idea what the code looked like I add a screendump of the code.
(As a Groovy novice I won't accept any liaibility ;) )
Regards,
Harald van der Weel
