When to use recovery scenarios

Relevant for: GUI tests and components

Recovery scenarios are intended for use only with events that you cannot predict in advance, or for events that you cannot otherwise synchronize with a specific step in your test or component.

By default, recovery scenario operations are activated only after a step returns an error. This can potentially occur several steps after the step that originally caused the error. The alternative, checking for trigger events after every step, may slow performance. For this reason, it is best to handle predictable errors directly in your test or component.

If you can predict that a certain event may happen at a specific point in your test or component, it is highly recommended to handle that event directly within your test or component, rather than depending on a recovery scenario. To do this in a test, add steps such as If statements or optional steps. To do this in a component, use a user-defined function with conditional steps.

Handling an event directly within your test or component enables you to handle errors more specifically than recovery scenarios, which by nature are designed to handle a more generic set of unpredictable events. It also enables you to control the timing of the corrective operation with minimal resource usage and maximum performance.

Example:  

  • If you know that an Overwrite File message box may open when a Save button is clicked during a run session:

    You can handle this event with an If statement that clicks OK if the message box opens or by adding an optional step in the test to click OK in the message box. (For keyword components, you define this If statement in a user-defined function and make it available via the associated application area.)

  • You can define a recovery scenario to handle printer errors. Then if a printer error occurs during a run session, the recovery scenario could instruct UFT One to click the default button in the Printer Error message box.

    You would use a recovery scenario in this example because you cannot handle this type of error directly in your test or component. This is because you cannot know at what point the network will return the printer error. Even if you try to handle this event by adding an If statement in a user-defined function or in your test immediately after a step that sends a file to the printer, your test or component may progress several steps before the network returns the actual printer error.

See also: