TestPlan Intercepting HTTP Errors
Document

Intercepting HTTP Errors

by Group Public on Friday March 12 2010 @ 15:15:09 (1/1 Points)

Tutorial ↪User Guide ✑ Reply ✓ Stick It ✗ Ditch It ⚐ Tag It

During the normal flow of a script and HTTP error will cause a failure and immediately end the current unit. There are some times however where you would like to look at the failed response. For example, in a live monitor you don't normally care about the content of 404 error page, but sometimes there may be information in there useful for your deployment team. Using HTTP interception you are able to provide a global handler for all errors.

If you are just interested in manually looking at the response for debugging then use Debug.Web instead. The interception described here is for when the test itself must inspect the responses.

System.HTTPIntercept

The context entry System.HTTPIntercept is where an intercept handler can be defined. Each handler is defined with the name Single.### where ### is the specific error code to be handled. The value of this entry should be the name of a unit to be executed.

Rather than exact numbers a class can be specified, such as Single.4xx. A global intercept can also be defined as Single.xxx, though this may introduce some performance issues.

Single indicates only one such callback will be executed. The most specific one will be chosen. There is currently not other option other than Single.

The below is an example of registering several handlers.

System.HTTPIntercept:Single.504=global.Handle504

System.HTTPIntercept:Single.404=global.Handle404
System.HTTPIntercept:Single.4xx=global.Handle4xx

Note again that if an error code of 404 is returned only one handler will be called: global.Handle404. The generic 400 class fallback will be used for all other 400 level errors.

Supported Modes

The HTTP interception mechanism works in HTMLUnit and ULRMode backends. It does not work in Selenium (it is not possible).

Writing a Handler

When called the actual response is setup as the current response. It matches the response format as RawGetURL.

Be aware that the handler is called outside of the normal execution path. As such checkpoints will be performed, and output, but will not have an influence on the overall test. Where values are emitted, and at what time the callback is executed, is also undefined, thus it should not attempt to communicate with the main test in any fashion. It should simply write notices or files for use outside the system.

© 2008-2010 edA-qa mort-ora-y
Using Persephone and TestPlan
Tag: