Programmatically control the recovery mechanism

Relevant for: GUI tests and components

You can use the Recovery object to control the recovery mechanism programmatically during the run session. For example, you can do any of the following:

  • Enable or disable the entire recovery mechanism
  • Enable or disable specific recovery scenarios for certain parts of a run session
  • Retrieve status information about specific recovery scenarios
  • Explicitly activate the recovery mechanism to check for Application Crash errors at a certain point in the run session.

For details on the Recovery object and its methods, see the Recovery object topic in the Utility Objects section of the Object Model Reference for GUI Testing.

Recover from Application Crash errors

By default, OpenText Functional Testing checks for recovery triggers when an error is returned during the run session.

However, this is not the case for Application Crash errors. You can use the Recovery object's Activate method to force OpenText Functional Testing to check for Application Crash events after a specific step in the run session, to trigger the recovery scenario configured for this error.

 

Example:  

Suppose you know that an object property checkpoint will fail if certain processes hung or crashed and are open when the checkpoint is performed. You want to be sure that the pass or fail of the checkpoint is not affected by these open processes, which may indicate a different problem with your application.

However, a failed checkpoint does not result in a run error. Therefore, by default, the recovery mechanism is not activated and the crashed application is not handled.

You can define a recovery scenario that looks for and closes specified open processes when an object's properties have a certain state, indicating that the problematic processes were open.

You can instruct OpenText Functional Testing to activate the recovery mechanism if the checkpoint fails so that OpenText Functional Testing can check for and close any problematic open processes and then perform the checkpoint again. This ensures that when the checkpoint is performed the second time it is not affected by the open processes.