TestArchitect Tutorial Part 2: Becoming a TestArchitect power user Lesson #2: Interfacing with a GUI

 Creating the test

Creating the test

Build a new test module based on the interface of the Car Rental sample application, and create a simple test that interacts with the AUT.

1. In the TestArchitect explorer tree, select any item within the current project, then click Create new test module in the toolbar.

   The New Test Module dialog box appears.

2. Enter Login Test as the name, then click Create.

   A new test module appears in the main panel, ready for editing.

3. In the editor, enter Valid login (Access granted) as title for TEST CASE TC01 in the third column.

4. In the OBJECTIVES section, enter Access is granted for a valid login as description for test objective TO 01 in the third column.

   Note that TO 01 under TEST CASE TC01 is automatically updated to reflect your changes.

5. Optional: In the leftmost cell of a row somewhere in the INITIAL section, type use interface, with the argument Car Rental, leaving at least one blank line above it to allow for a header name:
   
   

   Notes: 
   This tells TestArchitect that you’re going to test against an application’s user interface and that the details for the windows and controls can be found in a TestArchitect interface called Car Rental.
   Notes: 

   This TA interface, in contrast to a conventional application user interface, is an entity created in TestArchitect specifically to facilitate interfacing with the Car Rental application. The Car Rental interface consists of a set of worksheet files called interface entities, and is found in the Interfaces subtree of the Car Rental project:
   
   

   Refer to Creating an interface for further discussion on the topic of TestArchitect interfaces.

6. In the test case, add a new action line by typing enter, again in the leftmost cell. (Note that actions, and only actions, must be entered in the leftmost column of the editor’s worksheet.)

7. Notes: 
   enter is the standard action used for entering values into controls such as text boxes in the AUT. In this case, this action line is responsible for entering a user name. Note that the enter action accepts three arguments: window, control, and value.
   Notes: 
   You can move your cell pointer to the next cell by hitting the Enter or Tab key. Once in the field for the window argument, hit your space key. Note how this brings up a context-sensitive list of possible window names for the Car Rental AUT. (These names are defined in the Car Rental interface that you are using.) The same holds true when you enter the next argument, control.

   Enter the values login, user name, and john into the line’s argument fields as shown below:
   
   

   The values for the window and control arguments are the TA names for the Car Rental Login window and its User name text box, respectively. (In this instance, aside from being all lowercase, the two TA names are the same as their “real-world” counterparts, but that need not be the case.) The interface you have specified with the use interface action contains a set of mappings of TA names to the actual windows and controls in the AUT, including the Login dialog box, its fields, and its buttons.

8. A few rows below the enter action line, add a new action line by entering click in the leftmost cell.

   The click action in this action line will be used to click the Login button.
   
   

   When you enter the click action, five arguments appear. TestArchitect displays the names of all possible arguments for an action, though all arguments don’t require values. Required arguments are listed first.

   The available arguments for the click action are detailed below. For the purposes of this tutorial only the first two arguments are required: window and control.

   • window: The TA name of the window containing the button to be clicked (the Login window)
   • control: The TA name of the control to be clicked (the Login button on the Login window)
   Notes: 
   Refer to Built-in actions of the TestArchitect Automation Guide for details regarding which arguments are required and which are optional for other arguments.

9. A few rows below your click action line, add a new line by entering check window exists in the leftmost cell.

   The check window exists action is used here to check for the existence of the Car Rental - Welcome window. If login is successful, the application is expected to display that window.
   
   

   When you enter the check window exists action, only the window argument header appears, as that is all the information that the action requires.

You have now created your first test module which actually interacts with an AUT. In this case, your test clicks a button (Login) on a window, then tests the AUT to ensure that it has responded as expected (producing the Car Rental-Welcome window).

Next, you will run your test to ensure that it works as expected.