5.4.1.2 Adding the Event Handlers to the use case

The next step is to add the Test Cases as Event Handlers to the use case so that they are activated when an error occurs.

  1. Open a use case in the Test Case Editor . Remember that each use case should be independent, and entirely contained in one single top level Test Case 5.1.3.
  2. Add the Action Error Test Case to the use case as an Event Handler 3.18. Specify Action Error as the error type, and return as the reentry type.
  3. Add the Check Failed Test Case to the use case as an Event Handler . Specify Check Failed as the error type, and continue as the reentry type.
  4. Add the Component Not Found Test Case to the use case as an Event Handler . Specify Component Not Found as the error type, and return as the reentry type.
  5. Add the Configuration Error Test Case to the use case as an Event Handler . Specify Configuration Error as the error type, and return as the reentry type.

Now, any error in this use case (which is not handled by a local Event Handler within the use case) will result in one of these Event Handlers being activated. Check failed errors will mean that the test continues. Action errors, Component not found and Configuration errors will provoke a restart of the AUT . The test execution leaves the branch in which the Event Handler was nested (the use case) and carries on at the next Test Case (use case) or Test Suite .
\includegraphics[height=2cm]{lightbulb} The app_startup Test Case is important at the beginning of each use case in case the AUT has just been restarted 5.1.3.

Carry out these steps for each use case as you create it.

In this way, unexpected errors can be dealt with in a way that allows them to be identified later on. The test does not stop at the error, but tries to carry on at the next relevant point. This is the reason why use cases should be independent from each other - to stop further errors occurring.



Copyright BREDEX GmbH 2011. Made available under the Eclipse Public License v1.0.