distributedlife

The next step in improving your HP Service Tests is to reduce the scope of what you are testing to the test focal point. This should be standard testing practice but not everybody does it. So I’ll briefly explain what I mean before showing you some code.

When you are designing a test case you should only be testing one thing. I called it ‘singular of purpose’ in my article on ATS Test Cases. This keeps your test discrete and quicker to test¹. When a bug is found a fine grained test is easier to analyse because you have less changes between the last working test and the failing test. Let’s talk about this difference between tests.

In mathematics the difference operator is known as the delta Δ. If you have lots of discrete tests then the difference between each test is also the delta. Reducing the delta between tests will make them more specific whilst increasing the delta will make the tests more general. When it comes to service testing I try to get the delta down to one; one change between the last test and the current. If the test fails; I know exactly why and so does the developer.

So how does this relate to HP Service Test?

Let’s start with some standard looking service test code, but we’ll include the improvements from step 1.

web_service_call
(
    "StepName=Service}::{Method}",
    "SOAPMethod={Service}|{Binding}|{Method}",
    "ResponseParam=response",
    "Service={Service}",
    "ExpectedResponse=SoapResult",
    BEGIN_ARGUMENTS,
    "xml:composite="
        "<composite>"
            "<BoolValue>true</BoolValue>"
            "<StringValue>The quick brown fox jumps over the lazy dog</StringValue>"
        "</composite>",
    END_ARGUMENTS,
    BEGIN_RESULT,
    END_RESULT,
    LAST
);

If we want to test another aspect of this service test then we are going to copy and paste this code and change one of the attributes. This keeps in line with our small delta policy but is a process that can only be described as tedious and error prone.

How is someone who has to maintain the test going to know what you’re testing and why you made that change? What if you need to change one of your default values due to a code change?

A better solution is to change your vuser_init function to define our defaults.

void SetDefaultParameters (void)
{
    lr_set ("true", "BoolValue") ;
    lr_set ("The quick brown fox jumps over the lazy dog", "StringValue") ;
}

vuser_init()
{
    return 0;
}

When I mean defaults I mean the bare minimum of input information required to achieve a successful operation call. If it is optional, do not supply it. The goal is to get your request down to the smallest set so that your first test doesn’t require any input changes and will pass.

SetDefaultParameters () ;

web_service_call
(
    "StepName=Service}::{Method}",
    "SOAPMethod={Service}|{Binding}|{Method}",
    "ResponseParam=response",
    "Service={Service}",
    "ExpectedResponse=SoapResult",
    BEGIN_ARGUMENTS,
    "xml:composite="
        "<composite>"
            "<BoolValue>{BoolValue}</BoolValue>"
            "<StringValue>{StringValue}</StringValue>"
        "</composite>",
    END_ARGUMENTS,
    BEGIN_RESULT,
    END_RESULT,
    LAST
);

From here each test you can toggle each attribute as required. Taking out a required parameter should result in a fault. Adding an optional parameter will give you varied outcomes based on your requirements.

The important aspect of all of this is that each test now has a finite list of changes required to make it distinct from a previous test. The changes are clearly labelled before the service call.

SetDefaultParameters () ;
lr_set ("false", "BoolValue") ;

web_service_call
(
    "StepName=Service}::{Method}",
    "SOAPMethod={Service}|{Binding}|{Method}",
    "ResponseParam=response",
    "Service={Service}",
    "ExpectedResponse=SoapResult",
    BEGIN_ARGUMENTS,
    "xml:composite="
        "<composite>"
            "<BoolValue>{BoolValue}</BoolValue>"
            "<StringValue>{StringValue}</StringValue>"
        "</composite>",
    END_ARGUMENTS,
    BEGIN_RESULT,
    END_RESULT,
    LAST
);

These tests are easier to maintain and to some extent, self documenting. If you need to change a default parameter you change it in one place. If you need to change an optional parameter you know where that change is because your action name will list parameter being tested.

Next time, I’ll talk about how you find this minimum set; it’s a workflow.

1. anecdotally at the moment but I’ll prove this one day [↩]