Keep Your Code Clean and Robust

Your code should be fairly robust, meaning that it should account for the unexpected and always allow for orderly termination when errors do occur. Notice the Select Case statement in our example in the previous section. These three lines of simple code alert the tester that an unknown window code was read either because a new case statement has not yet been added to accommodate it or because a bad code found its way into the test data.

When using called procedures and functions, always construct it so that a return code is made available to the caller. This alerts the caller that either the function/procedure was successful, or failed, and allows for proper action to be taken.

Now that the window is selected, it follows that the tab or subwindow as specified in TabCd (tab code) is selected. Use the same type of Select Case construct as was used for the Window_Select code.

'$Include: "DataDriven.sbh"
Declare Function Tab_Select(TabCd)

Sub Main
    Dim Result As Integer
    Gen_Return_Code = Tab_Select(TabCd)
End Sub

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Function Tab_Select(TabCd)
tab_Select=1                                 'initially set the return code to "Success"

    Select Case tabCd

        Case "t1"
            msgbox "t1 selected"

        Case "t2"
            msgbox "t2 selected"

        Case "t3"
            msgbox "t3 selected"

        Case Else
            Msgbox "Tab Select not found for TabCd: "&Cstr(TabCd)&" Terminating"
            Tab_Select=0                        'return value FAIL
            SQALogMessage sqaFail, "Tab Select not found fortab code: "&Cstr(tabCd)&"", ""
        End Select
End Function

Notice that this procedure is constructed in exactly the same way as the window select procedure. The only difference is that in this procedure we are working with the Tab_Select code instead of the Windows_Select code. Sticking with our example, let's say that on the Customer Information window there are two tabs, one for Billing Information and one for Account Information. Therefore, we need Tab_Select codes for both. Let's use Acct_Info and Billing_Info. Our newly modified tab selection procedure may now look something like this.

'$Include: "DataDriven.sbh"
Declare Function Tab_Select(TabCd)

Sub Main
    Dim Result As Integer
    Gen_Return_Code = Tab_Select(TabCd)
End Sub

'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Function Tab_Select(TabCd)
tab_Select=1                       'initially set the return code to "Success"

    Select Case tabCd

        Case "Acct_Info"
            Record selection of the account information tab here
            Validate the tab was selected and is now in focus

        Case "Billing_Info"
            Record selection of the billing information tab here
            Validate the tab was selected and is now in focus

        Case ......-
            Add additional cases for as needed

        Case Else
            Msgbox "Tab Select not found for TabCd: "&Cstr(TabCd)&" Terminating"
            Tab_Select=0  ''return value FAIL
            SQALogMessage sqaFail, "Tab Select not found fortab code: "&Cstr(tabCd)&"", ""
        End Select
End Function

Now that the tab or subwindow is selected, it is time to perform the action as specified in ActCd (action code), and subsequently to perform error processing based on the content of the ErrCd (error code) value. As with the window and tab selection codes, the Perform_Action code and Process_Action code should also be kept in a separate script or procedure file. This helps keep the code in the Main procedure small. We can use identical Select Case constructs for the action selection and error processing as we did with window and tab selection. The code for these routines is in Chapter 8.

Since the actions being performed in each window or tab are not the same from window to window, unique action codes relative to each window and/or tab must be used. For example, if there is an OK button on multiple screens, use a code that is a combination of the window name and the OK button such as “User_Pref_OK” and “Options_OK”—this will help to eliminate confusion among all of the various command buttons, which are on different screens.

We can usually record (using the insert-at-cursor record/playback feature that accompanies Robot) the window and tab selections directly into the Window_Select Tab_Select functions because the amount of code required to perform these actions is fairly small, and it is easy to set the cursor and insert these recorded excerpts into the function code. The same holds true for the Process_Errors function. In the Perform_Action procedure, this does not hold true, as you will usually be required to enter/record a significant amount of code. If that becomes the case, then simply construct a separate script/procedure to hold that code. The scripts can then be called from within the primary Perform_Action procedure. Use a good naming convention to assist in keeping the filenames straight—for example, PA_Options and PA_User_Pref.

Here is the code for the DDPerform_Action procedure template, followed by the same code demonstrating calling subprocedures such as our example, PA_User_Pref.

'$Include: "DataDriven.sbh"
Declare Function Perform_Action(ActCd)

Sub Main
    Dim Result As Integer
    Gen_Return_Code = Perform_Action(ActCd)
End Sub

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Function Perform_Action(ActCd)
    Perform_Action=1

    Select Case ActCd

        Case "a1"
            msgbox "a1 selected"

        Case "a2"
            msgbox "a2 selected"

        Case "a3"
            msgbox "a3 selected"

        Case Else
            Msgbox "Action Selection not found for ActCd: "&Cstr(ActCd)&" Terminating"
            Perform_Action=0  ''return value FAIL
            SQALogMessage sqaFail, "Action Selection not found for: "&Cstr(ActCd)&"", ""
    End Select
End Function
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Here is the same code with an inserted procedure call.

'$Include: "DataDriven.sbh"
Declare Function Perform_Action(ActCd)

Sub Main
    Dim Result As Integer
    Gen_Return_Code = Perform_Action(ActCd)
End Sub

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
Function Perform_Action(ActCd)
    Perform_Action=1

    Select Case ActCd

        Case "User_Pref_OK"            'processing for selecting the OK button on the User
 Preference window.
           CallScript "DDTab_Select"   'instead or recording in-line here, we will call a
 different script where
                                       'the recording/code entries were made

        Case "a2"
            msgbox "a2 selected"

        Case "a3"
            msgbox "a3 selected"

        Case Else
            Msgbox "Action Selection not found for ActCd: "&Cstr(ActCd)&" Terminating"
            Perform_Action=0  ''return value FAIL
            SQALogMessage sqaFail, "Action Selection not found for: "&Cstr(ActCd)&"", ""
    End Select
End Function
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

Think about how you would verify that a new data value or record was entered into your AUT. Here are some possible scenarios:

• Access the database directly, outside of the AUT, to verify that the record was entered.

• Look for an expected message box or status indicator that states that the record/data was entered and saved.

• Look for an expected new window.

• Close the window/tab and, in the next data record, perform a selection or display type of action using the same data that was used for the insert or add action to verify that it was entered.

The ability to delete the newly inserted record without error on a subsequent input record is another possible method. Or simply assume that the lack of an error message indicates that the insert was successful, but this is the least desirable method. Why? The verification code should be included directly after the action performance code (e.g., inputting data or selecting a record). A verification failure here constitutes a test failure and should terminate the test.

Data input is performed and recorded in the portion of the code where the action selection procedure takes place. This occurs in conjunction with an Insert, Add or New, Delete, Update, Select, Display, etc., type of action where data input to the AUT is necessary to satisfy these conditions.

Assume for a moment that we wish to input data into a window/tab that has already been selected, enabled, and is in focus. Also assume that this window/tab has only three input fields into which data can be input. We would record (using the insert-at-cursor method) the selection of each of these fields, preferably using the Tab order.

If not using the Tab order, we should record the selection utilizing the normal order that a user would employ. As each field is selected, assuming for the moment that it is an input data field, we will type in a value. Start by typing a 1; then tab or double-click to/on the next input field; then type a 2, and so on. This will help us to easily identify the selected fields in the code.

Note that double-clicking on a data input field is preferable to tabbing and is usually necessary. Double-clicking on an input data field generally selects all of the data in that field so that it can be replaced. A single-click operation may merely position the cursor in the input control where it would normally put you into insert mode. Not good! The data is not replaced with the new value.

Our small piece of recorded code may look like this:

Window SetContext, "Caption=Window Name", ""
EditBox DblClick, "Label=Label name:", "Coords=x,y"
InputKeys  "1"
EditBox DblClick, "Label=Label name:", "Coords=x,y"
InputKeys  "2"
EditBox DblClick, "Label=Label name:", "Coords=x,y"
InputKeys  "3"
PushButton Click, "Text=OK"

We will substitute the data values in the InputKeys command with the names of the variables that contain the data read from our external source. Suppose we choose to read our data into a string array named DFld( )—we might then substitute the recorded, typed-in value with the variable name DFld(x), where x represents the index into the array, as follows:

DFld(1) is the first data value read

DFld (2) is the second data value read

DFld(3) is the third data value read

and so on; it is continued as necessary to enter all of the required values.

Our small piece of recorded code may now look like:

Window SetContext, "Caption=Window Name", ""
EditBox DblClick, "Label=Label name:", "Coords=x,y"
InputKeys DFld(1)
EditBox DblClick, "Label=Label name:", "Coords=x,y"
InputKeys DFld(2)
EditBox DblClick, "Label=Label name:", "Coords=x,y"
InputKeys DFld(3)
PushButton Click, "Text=OK"

Notice the text in italics. Instead of x it is now DFld(x).

At this point our script is entering values from our data file versus using data that was originally input. Our goal at this point is to substitute data and/or selections that were made manually during a recording session with values or data from our input file

Now that the data has been entered, we typically have to perform a subsequent action such as

Add

Save

Delete

Update the database

and so on. This is usually accomplished by selecting a control button or menu selection such as File→Save. This type of common action should be recorded into a subroutine, which can be called throughout the code. Then, if changes are made, there is only one place to fix.

Now that the action is finished, we are ready to check the ErrCd (error code) value to determine if we should look for an error condition—an error message or other identifiable error condition. We can build a Select Case construct using the same procedure we used for the window/tab selection. Again, separate this code into procedure or the library file to help keep Main small and manageable.

Typical coding in the error processing section might look like this:

Select Case ErrCd
    Case "Err1"
        Verify the existence of the appropriate error msg, etc. before proceeding!
    Case "Err2"
        Verify the existence of the appropriate error msg, etc. before proceeding!
    Case Else
        Msgbox "The Error code in ErrCD code does not exist. Terminating"
        SQALogMessage sqaFail, "Error Code not found for "&Cstr(ErrCd)&"", ""
End Select

If the expected error condition is found, the processing of this record is complete and is successful. Main continues processing by reading the next data record, provided we are not at the end of the input file and more records are available to be read. If the expected error condition is not found, a test failure occurs (usually a test case). The test can be terminated and the result entered into the test log, or Main can log the result and continue processing as long as the test data records represent independent tests.

The test log should indicate what the last recorded read contained and the record number. This allows for fast debugging and problem isolation. This can be accomplished in Main with very little code.

Archer Group Summary

CSDDT consists of a group of routines, libraries, or procedures that will allow the use of data from an input file to perform selections; CSDDT also allows data input versus what we typed in as input or clicked on as selections. If we change the data in our input file, the selections and actions as well as the data that are to be input into the AUT can be modified or altered without changing the script.

This is the real benefit of a Data Driven testing framework. Once the mechanics of making the selections are in place, the test code is set up to operate on the input data, and we can modify each test scenario using different data, not different test scripts, to create functional variants. This is because the test data file contains codes that specify where to go in the AUT, what action to perform, what to expect, how many data fields to use, a comment (documentation), and what data to use (input into the AUT).