distributedlife

Validating fault behaviour is something that is tied to the business implementation of faults. How each business implements faults, will determine the implementation of your fault validation routines. What I will talk about is how to setup your fault validation routines so that you can write fault validation easily.

The goal is to have your service test code look like this:

SetDefaultParameters () ;

FaultExpected () ;

CallService () ;

ExpectFaultWithCode ("ServiceEpicFailFault") ;

The above snippet is of course assuming that your services through fault codes with each fault.

What we are going for is a one-line validation of fault behaviour. If your faults have an additional information that you want to validate then pass it into the function. If you have different types of faults (UserFault, BusinessFault, SystemFault, ServiceFault, etc) then you will want to change the name of the function for each one.

It is better to have the following code:

ExpectServiceFaultWithCode ("ServiceEpicFailFault") ;

Rather than

ExpectFaultWithCode (“ServiceFault”, "ServiceEpicFailFault") ;

The reason being is that your fault type is now strongly typed (you could achieve the same with an enumeration) and spelling mistakes will not cause incorrect fault validation.

The basics of your fault validation code will be something like this:

void ExpectGenericFault (void)
{
    int result = 0 ;

    result = lr_xml_extract
    (
        "XML={response}",
        "FastQuery=Envelope/Body/Fault",
        "XMLFragmentParam=Fault",
        "NotFound=Continue",
        LAST
    );

    if (!result)
    {
        lr_error_message("A generic fault was expected and not found") ;
    }
}

In this snippet we are expecting a generic fault; a SOAP fault with no additional information. We report an error if no fault is found.

If you have fault codes to validate then you will want a method signature like so:

void ExpectGenericFault (const char* const FaultCode)
{
    //...
}

the response document

In our code we are dependency on the response document. We have done this all through our [pipeline] code. The reason why we do this is that if every service stores its results in a HP parameter called “response” we can take it for granted that when you want the current service response you use that parameter. This saves effort giving each response object a unique name and makes your code more readable. You have to be careful but in most cases when the response variable is not set HP Service Test will halt execution anyway.

what fault code?

Where do you get the expected fault codes from? If your developers are good then you can get documentation from them that include the faults and when they are expected. This is the kind of information they would provide another developer that is going to consume their service. If they don’t have this information then they are doing shoddy work.

If you’re waiting for information you can try the test and see. This is what I do when I’m waiting for information; test anyway.

• If you get a fault, did you expect it?
• What about the fault code; does it make sense?
• What about other fault information; is it useful to the consumer?

Ponder that information and if it makes sense then move onto the next test. If it doesn’t make sense; raise a defect questioning the validity of the fault information. If you feel a defect is too strong then ask for a ‘request for clarification’.

where fault code?

I’m not going to provide code on how to validate a fault code response because I don’t know how your fault codes are stored. It’s basic XPATH validation like this:

success = lr_xml_find
(
    "XML={source}",
    "FastQuery={xpath}",
    "Value={value}",
    "NotFound=Continue",
    LAST
);

But if you have multiple fault codes then it may be more like this:

success = lr_xml_find
(
    "XML={source}",
    "Query={xpath}",
    "Value={value}",
    "NotFound=continue",
    "SelectAll=yes",
LAST
);