Dion Johnson use the martial arts metaphor four common issues with automated tests and how test automation specialiasts can "train" their scripts to identify, capture, and handle these problems. In this week's column, Dion talks about how to make develop test automation scripts that handles dynamic paths within an application—which he call "strikes."
In the first three parts of this series, instructor Dion Johnson taught how to write flexible and balanced automation scripts that can defend themselves against the application under test's attacks. Now that our automated test scripts are strong, they're ready for the next and final step of training. Enter Dion's dojan once more, and prepare yourself to learn offensive strikes in regards to dynamic-path handling.
We are reaching the conclusion to this technical series known as "Taekwondo-mation," and your power has definitely grown. 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
Your automation has become flexible in the way it inputs data, and it has become balanced in the data that it inputs. Then, in part three, your automation prowess expanded to the defense of your scripts against the offensive maneuvers of the application under test (AUT). With these first three Taekwondo-mation principles mastered, you are now ready to complete your training. I must warn you, however, that this final session is no walk in the park. It is the most technical of all of the Taekwondo-mation principles, and will therefore be the most challenging. Many have stumbled on this principle as they have sought to become Taekwondo-mation masters, but I will be rooting for your success in this endeavor.
Ever heard the phrase "The best defense is a good offense"? That is what this final principle of dynamic-path handling asserts. By creating automated tests that attack the application in whatever state it exists, the tests will be more robust and, in many respects, more effective. Dynamic-path handling is a concept that is akin to model-based test automation. Model-based test automation is an automation approach in which the tests are derived by creating and implementing a model of the functional parts of the AUT. Dynamic-path handling, while similar, is smaller in scope. Where model-based test automation normally begs for a relatively complex framework, dynamic-path handling concepts may be implemented within any framework.
Dynamic-path handling, as discussed in this column, may be implemented in two ways:
- Point-A-to-point-B transitions
- Random path changes
"Point A-to-point-B-transitions" is a concept that refers to transitions from one point in the application to another in which, at the very least, the final point is known and planned by the automator. The unknowns in this situation are the intermediate points. "Random path changes" refers to point changes that are largely random. Therefore, not even the ending state is known by the automator, but is instead chosen at random during automated test execution. For the purposes of this column, I'll only expound upon the first bullet.
To understand dynamic-path handling, let's examine a simple example of the paths that an application may follow.
|Figure 1: Order application pathing|
The above figure illustrates the paths that our sample application may follow. The Screening page collects information from a user that will determine whether he gets routed to a screen that allows orders to be placed online or to a screen that provides information for contacting an organization to place an order. From the Orders screen, a user may place an order by credit card or by check online. From the Information screen, the path may go to another screen that provides detailed office contact information, then finally to a screen that provides the ability to submit a request for information via an online form.
In this sample application, dynamic-path handling may be introduced in the form of a navigation function that allows an automator to define where he currently is in the application and where he'd like to go, and