then allows the automated test to dynamically determine what path to take in order to get there. One such path that may be taken is:
Screening Page à Orders à Credit Card Information
A different path may be:
Screening Page à Orders à Check Information
While it is plausible that an automated test may want to begin navigation from some point other than the Screening Page, for simplicity we will assume that the starting point is always the Screening Page. In order to appropriately implement dynamic-path handling, the following steps need to be taken:
- Build a construct that addresses each point in the possible paths. (Note: Not all paths need to be addressed. Only the paths that are deemed most important. This is your automation, so you set the rules.)
- Identify branches in the paths to be addressed.
- Assure that each point addresses the possible ending points in the path.
Step 1: Build a Construct
One simple way to build such a construct is to set up a loop that continues to check the current point against the final point and continues until the final point is reached. This may appear in a function similar to the one in figure 2.
|
1 |
Function NavigateTo(endPoint) |
|
2 |
currentPoint = "ScreeningPage" |
|
3 |
Do While (currentPoint <> endpoint) |
|
4 |
Select Case(currentPoint) |
|
5 |
Case "ScreeningPage" |
|
6 |
|
|
7 |
Case "Orders" |
|
8 |
|
|
9 |
Case "CreditCardInformation" |
|
10 |
|
|
11 |
Case "CheckInformation" |
|
12 |
|
|
13 |
Case "Information" |
|
14 |
|
|
15 |
Case "OfficeContact" |
|
16 |
|
|
17 |
Case "OfficeContact" |
|
18 |
|
|
19 |
Case "InfoRequestDescription" |
|
20 |
|
|
21 |
End Select |
|
22 |
Loop |
|
23 |
End Function |
Figure 2: The construct (Note: The code used in this and other examples is Pseudocode, as opposed to actual code from a particular language, although it is worth noting that the pseudocode resembles VBScript).
This function addresses each point in the possible paths through the use of a branching construct known as a Select-Case statement. The loop ensures that the function continues to check for the current path, implements code to handle the current path, and then sets a new current path to be handled. This loop will continue until the current path becomes the ending path. The code that performs the activities just described can't be fully understood until the branches in the paths have been identified.
Step 2: Identify Branches in the Paths
The circles in figure 1 reveal the branches in the possible paths. The Screening Page may go to Orders or Information, while the Orders page may go to Credit Card Information or Check Information. These divergences in the path are where the most work will take place in the navigation function. Once these areas are identified, you may create the necessary code.
Step 3: Address Possible Ending Points
Each point--that is, each case in the Select-Case statement--must have code that performs the following activities:
- Determine whether or not the currentPoint is equal to the endPoint. If it is, then stop the loop.
- If you haven't identified the endPoint, identify it and what steps need to be taken at the currentPoint to facilitate reaching the desired endPoint.
- Identify the next point in the process and set it in the currentPoint variable, to be addressed in the next loop iteration.
Continuing with our sample, the construct from figure 2 may be updated as follows:
|
1 |
Function NavigateTo(endPoint) |
|
2 |
currentPoint = "ScreeningPage" |
|
3 |
Do While (currentPoint <> endpoint) |
|
4 |
Select Case(currentPoint) |
|
5 |
Case "ScreeningPage" |






