My pupils, you have all done well thus far as we've trained in the automation martial arts known as "Taekwondo-mation." You have grown stronger and more centered, but you are still not yet ready to be called "master."
As you are now aware, Taekwondo-mation places a focus on four key principles:
- Flexibility--Dynamic inputting data
- Balance--Inputting dynamic data
- Self-defense--Exception handling
- Strikes--Dynamic-path handling
Through the first two installments of this series, you have become versed in the first two principles. Put your combat robes back on, young Grasshopper (a Kung Fu reference my mother told me about), you are now ready to embark on the third principle--self-defense.
Make no bones about it, software applications and systems that are being automated don't go down without a fight, particularly those involving Graphical User Interfaces (GUIs). The minute an automated script gets near them, they start fighting. And without a good defense, automated scripts will lose the fight. Implementation of automated tests with effective exception handling involves:
- An understanding of the typical types of attacks that applications wage on automated tests
- Helping automated tests recognize when an attack is occurring
- Training automated tests to counter application attacks
Effective handling of error conditions that occur during automated test execution relies heavily on an automator's ability to predict the types of errors that the automated tests may encounter. This becomes exceedingly easier once it becomes clear that most errors fall into the following categories:
- Abrupt Application Termination
- Popup Dialogs
- Object/Data Failures
- Test Verification Failures
Abrupt Application Termination--Also known as a "crash," this type of error is a condition where the AUT unexpectedly suspends functionality and stops responding to both external and internal system stimulus.
Popup Dialogs--Popup dialogs are windows that are smaller than standard windows and come without a lot of the features that may be common to other windows in the AUT. The unexpected appearance of popup dialogs is troublesome for automated tests mainly because the dialogs tend to suspend all application activity until the appropriate dialog button has been clicked.
Object/Data Failures--Failure to find a desired object or object data is probably the most common of all failures experienced by automated test runs.
Test Verification Failures--Test verification points are typically a good way to address issues before they become problematic for the entire test run. These failures may be anticipated, and the automated test may therefore be set up to handle errors at this point.
Once potential errors have been identified, the next step in the exception-handling development process is to define a means of capturing the error. Error capture involves identifying an error occurrence, determining the type of error, and passing it off to the exception-handling routine. This is often done via the concept of an exception. When encountering error conditions, automated scripts may trigger what is called an exception in the form of an error code. Exceptions provide automated tests with the ability to pass control of the script to a handler routine that will effectively handle the error conditions that caused the exception to occur. Some exceptions are generated automatically by the automated test tool when an error occurs, but automators may also write code that triggers an exception in specific circumstances. The automator then creates and/or customizes an exception-handling routine that handles the error in such a way that automated tests may continue or end in a smooth manner.
Exception handling may be localized or may be established in a separate utility that runs once an error is triggered. Localized exception handling may be implemented as detailed in figure 1.
1 | Input "John" into Username textbox |
2 | Input "JPass" into Password textbox |
3 | Click Login button |
4 | If "Login Error" dialog exists then |
5 | Click Ok button |
6 | Log Error |
7 | Abort the test |
8 | End If |
| Figure 1: Localized example of exception handling. |
This example has some exception handling in steps four through eight. This example specifically looks for the anticipated "Login Error" dialog, handles it by clicking the OK button, and then aborts the test. The advantages to handling this error are: time is not wasted by continuing to execute a failed test; the report will be clean because only the main error will be logged; and the following tests will not be adversely affected.
Another approach to handling this error is to use exceptions and a separate error handler, as seen in figure 2.
1 | Input "John" |
2 | Input "JPass" |
3 | Click Login |
4 | scrVar = Verify |
5 | If scrVar Not |
6 | Pass |
7 | End If |
| Figure 2: Passing to error handler. |
This example reveals how an exception handler may be introduced. An error code is received from a verification point (line four), then the error code is sent to an error handler in the event that the code is not a "Pass." The exception handler will be responsible for executing exception code similar to what is shown in figure 1, in addition to handling other types of errors that may occur.
Stay tuned for Part IV of the Taekwondo-mation series, in which I will explore the principle of Strikes (Dynamic-path handling).
Read Training Test Automation Scripts for Dynamic Combat: Flexibility - Part I
Read Training Test Automation Scripts for Dynamic Combat: Balance - Part II
Read Training Test Automation Scripts for Dynamic Combat: Strikes - Part IV
