Automation Testing

UFT API Negative Testing HTTP 500 Errors

By Test Guild
  • Share:
Join the Guild for FREE
UFT API Cover

I recently was asked by a co-worker (Sreevani) how to use Service Test 11.20 to test for HTTP Error 500 returned from a REST service.

My first suggestion for testing HTTP 500 errors

My first suggestion was to say, “Sure. All you need to do is use the HTTP request's checkpoints status code. Set the status code to equal the expected Value 500. Turn off the service, run the test and it should pass.” That advice however, would have been wrong. As you can see below, the test actually fails when this approach is used:



</h2

When you think about it, Service Test is behaving as you would expect when an HTTP error code 500 is received. Service Test fails the test because it expects a valid response back from the service (like 200). The HTTP 500– Internal Server Error is a general “catch all” error that means something has gone wrong.

That's how positive testing should work–checking that the service does what it was designed to do without any errors. In this case, however, we need to do some negative testing.

Negative Testing UFT API

Negative testing is used to verify that the service did not perform a task it was not designed to perform. In this case, we need to verify the status code 500, and if it finds the expected error code 500, pass the test. (When testing SOAP web services in ST 11.20 there is an actual setting–“Fault is expected”–that allows you to do this.)


Unfortunately, this option is not available when testing a REST service.

Fault is expected when testing a REST service

My second instinct was to tell the engineer that this could be handled using custom code. To my embarrassment, however, I didn't know what the exact syntax should be. After trying everything I could think of, I was stumped. Luckily, a developer on the project pointed us to the args.ExecutionResult object, which allowed us to tell Service Test to pass if it received a failure:

if ( args.ExecutionResult.Status == STExecutionStatus.ApplicationUnderTestFailure)


args.ExecutionResult.Status = STExecutionStatus.Success;


Place this code in the HTTP request's AfterExecuteStepEvent Event.

Lesson Learned

The above is yet more proof that “developers are your friends!”

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  1. Hi Joe,

    I am new to QTP and ST and I am glad that your site exists.
    I tried half a day to find a solution but couldn’t find any.
    So thank you so much for this!

    Philipp

      1. Hi Joe,

        I still have one question.
        What happens if a HTTP 500 is returned but has nothing to do with my test case?
        Would the test not also be set to “passed”?

        salute
        Philipp

  2. Tried, it does not worked.

    Even I tried to fail test with
    args.ExecutionResult.Status ==STExecutionStatus.ApplicationUnderTestFailure;

    But not test still passed.

    I want to test response status agains expected status programmatically and fail/pass test accordingly.

    Any suggestion?

  3. To programmatically handly negative test:
    Check oputput parameter StatusCode on HTTPRequest Activity. If it match expected status code and Activity status is fail due to HTTP500, flip status to success
    args.ExecutionResult.Status = STExecutionStatus.Success;
    Else throw exception to fail the activity or set status to failure.

    This way no need to use check point at design time.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Selenium SMS Email Testing Tool (e2e with Mailosaur)

Posted on 09/25/2023

Do you have manual tests that are not currently automated, not because they ...

How to Scale Your Enterprise Testing (Introducing SBOX)

Posted on 09/21/2023

Based on my conversations with hundreds of testers each year, automation testing has ...

The 4 Destroyers of Any Automation Test Script

Posted on 09/05/2023

After interviewing over 500 test engineers on my podcast, I've identified the four ...