Testing Cordys BOP-4 using SOAPUI

 

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:

• 
  
  invoking a SOAP Service
• 
  
  validating the result (e.g. by checking database content)
• 
  
  Set properties
• 
  
  Pausing for an amount of time.
• 
  
  Executing an script

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:

• 
  
  A SOAP call to send a message
• 
  
  A wait step to allow Cordys to process the request
• 
  
  A validation step.

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:

• 
  
  Run “Groovy” scripts (See http://groovy.codehaus.org/)
• 
  
  Invoke test cases from groovy
• 
  
  Read files from Groovy
• 
  
  Set property variables in Groovy

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:

• 
  
   The option to specify the properties that are mapped upon the value lists.

            #plist,<property-1>,<property-2>, … <property-N>

• 
  
  The option to specify a property that is assigned with a unique value each time it is set

            #property,<property>,<value>

• 
  
  The option to specific a specific property until it is set again.

            #unique, <property>

• 
  
  The option to add line-comments

         //<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

Haraldvanderweel@gmail.com