Event Handlers for API test steps

Relevant for: API testing only

An event handler is a specific occurrence of a defined code process triggered at a specific point in the overall test flow. Use event handlers in your API tests to change or extend your testing.

Each API test step has predetermined event handlers that are run at specific points in the test execution.

Within these event handlers, add additional code (above and beyond the test step's regular execution flow) to enable you to define properties, parameters, or variables and additional processes that help to facilitate your test flow.

Note: Any add-ins you choose in the Add-in Manager when opening UFT One do not affect API tests or event/custom coding. All API test event handlers are written with C# code.

We recommend having experience and/or knowledge in writing code before attempting to write event handlers for your tests. All API test events use the C# language and syntax, even if your application uses a different language. For details on C#, see the Microsoft C# Reference.

Event handler usage

When you run a test of your application's API, or when you run the application itself, each business process is executed as defined in your application's code.

These processes are each represented by your test's steps. To extend your application and test functionality, add events to your application code, and event handlers to your test.

Example:

You might add an event handler after compiling a Web service call response to do one of the following:

Set security for the Web service response data
Add attachments to the Web service call response

Available resources in event handlers

Event handlers are designed to be run at a specific point in the application/test flow. The objects, methods, and properties available in a given event handler are limited to the context of where the event occurs in the application or test workflow.

This means that while working in an event handler, you cannot access the process's or step's output properties, as these properties are part of an application or test that hasn't yet run.

If you use an event handler out of the context in which it was designed, the properties and methods the test will try to use are not accessible.

Example:

To set the request properties of one step based on the response properties of a previous step, create code in an event handler called BeforeExecuteStep. There, enter the property values you would like your test to use.

Available properties and methods are limited to the objects contained in the context of the step's flow, and the event handler located immediately after the step.

These include the output or response properties available in the previous step, and the input or request properties of the current step.

Standard event handlers

For most test steps, there are three standard event handlers which run:

Before the test step
After the test step
As a checkpoint for the test step

For Web service and SOAP request steps, additional event handlers mimic the process of a Web service call. For more details, see API test events structure.

Additionally, you can use Custom Code steps, for which the entire test step flow is event handlers. For details, see Custom code steps.

Event handler recommendations

Use event handlers to extend the behavior of existing test steps, instead of providing all the property/parameter values for those steps.

When you do define property/parameter values for test steps, use the grid in the Input/Properties tab (Properties pane) instead of using custom code.

Note: This functionality is in contrast to the manner GUI testing uses coding. GUI tests and components enable you to write the entire test or action flow using code. However, an API event handler or custom code activity is only a portion of the larger test flow.

Sample event handler use cases

Example: Connect to a local database

Before entering customer information into a flight booking service, your application must connect to a database located locally on your computer (which mimics the application connecting to a local database).

However, using the existing UI framework of the UFT One API test, you cannot connect to the database.

Use an event handler designed to run before the test step to include code that accesses your database and imports the information to your test.

Example: Extract information from a response file

After receiving a response from your Web service (in XML format), you need to extract certain information from the response file to use as the input for another test step.