|
6 |
if(endPoint = "ScreeningPage") then Exit Select |
|
7 |
if(endPoint = "Orders" or "CreditCardInformation" |
|
8 |
for online orders, then click Continue button > |
|
9 |
currentPoint = "Orders" |
|
10 |
else |
|
11 |
for online orders, then click Continue button to |
|
12 |
currentPoint = "Information" |
|
|
… |
|
N |
End Function |
Figure 3: Handling points in the path
In the interest of brevity, only the ScreeningPage portion of the function is shown in the updated figure. Notice that the first check, in line six, is to see whether the desired destination has been reached. This statement indicates that if the endPoint identified in the function call is equal to the current screen, then the Select statement can stop. The loop will also subsequently end at this point, because the currentPoint will be equal to the endPoint.
Next, every possible endPoint that may occur after the ScreeningPage is addressed. Line seven begins handling the path that begins with the Orders screen, while line ten begins handling the path that begins with the Information screen. The if condition at line seven addresses the application activity that will need to take place in order to get to any of the endPoints that may occur in the Orders path. The if condition at line ten addresses the application activity that will need to take place in order to get to any of the endPoints that may occur in the Information path.
Finally, lines nine and twelve identify what the new currentPoint will be once the appropriate application activity occurs. This will ensure that when the loop moves to its next iteration, it will go to the appropriate Case statement and perform the appropriate activity in order to move forward in the application.
These basic statements need to occur in each Case statement in the function.
Benefits of Dynamic-path Handling
There are many benefits to this approach to Dynamic-path Handling, including:
- When developing many automated tests that address many diverging paths, this type of function works as a buffer to shield your tests from numerous navigation paths, which could slow down test development and could also leave the test vulnerable to application path changes. With this type of function, navigation within a test may be handled with a statement as simple as:
NavigateTo("CheckInformation")
Note: for applications with a large number of paths, it may be best to limit the NavigateTo function to only those paths most traveled. Otherwise, the function may become too difficult to maintain.
- When combined with error handling, dynamic-path handling increases the power of automated tests, because the tests' "offensive strikes" will work off of the tests' "defensive maneuvers." This greatly increases the robustness and effectiveness of the tests.
- By introducing more advanced coding, this type of function could be set up to chose navigation paths at random, which will increase the automated tests ability to find new defects in the application
With the conclusion of this session, you are now Taekwondo-mation masters! However, I must caution you to not use this power in the wrong way. Some of the techniques may seem cool to play with, but it is important not to complicate automated tests that don't warrant such levels of complexity. I suggest that you perform an assessment of your application and test environment to determine whether or not the return obtained from implementation of these techniques exceeds the time investment involved in that






