Using Scripts for Data-Driven Testing

Retrieving Data and Iterating Through Storage

Entering Data Into an Application’s Form

Verifying Test Action Results

When creating data-driven tests with scripts, you typically use loops to iterate through test data. Script instructions that make up the loop body retrieve data from the data storage, enter them into the application form and verify the results.

To implement loops, you use the for and while statements. As for retrieving data from a storage, you use those script methods and statements that let you access the storage contents.

You can use any data storage you need, for example, comma-separated value (CSV) files, Excel sheets, or database tables (see the Data Storages section in the Data-Driven Testing - Basic Concepts topic). TestComplete includes special built-in routines and program objects that provide extended support for data-driven testing:

• Scripting objects

  To simplify access to data stored in Excel sheets, ADO databases or CSV files, TestComplete includes special driver objects that hide the actual data storage format and let you access data using a unified table-like interface. For instance, each row of a CSV file is represented as a table record, and a value in this row is presented as a column value.

  To work with the drivers, use the DDT object. Its methods let you obtain driver objects for Excel sheets, database tables and CSV files:

  Method	Description
  ADODriver	Returns a driver object for the specified database table. The test engine connects to this table via ADO.
  CSVDriver	Returns a driver object for the specified CSV file.
  ExcelDriver	Returns a driver for the specified Excel sheet.

  For information on working with these objects, see Using DDT Drivers.

  For information on converting data types, see Retrieving Input Data From Storage.

  For a step-by-step description of creating a data-driven test with the driver objects, see Data-Driven Testing With Scripts - Tutorial.

  Note that the DDT object and driver objects are available only if the Data-Driven Testing plugin is installed in TestComplete. See Using DDT Drivers.

• Routines

  TestComplete also offers a number of routines that make it easy to retrieve individual values from strings that contain data separated by some delimiter like a comma, semicolon or tab character:

  Routine	Description
  aqString.GetListLength, aqString.GetListItem	These methods are used to process a list of strings. To parse comma-separated values, you should assign a comma (",") to the aqString.ListSeparator property.

To enter data into application forms and controls, your either simulate keystrokes or mouse clicks over these controls, or store the desired values directly to properties of the desired form or control. In many cases, the easiest way to understand how to simulate an action is to record a test using one portion of test data and see how TestComplete does this. You can then modify the recorded test so that it assumes input data as parameters.

The following notes may help you with creating a test that will simulate user input:

• To simulate a key press, call the Keys method of the desired window or control.

• To set a value in a text box, use the SetText action or change the wText property value of this text box.

• To simulate mouse actions over list boxes, combo boxes, tree views, list views and other controls, use specific methods of these objects. See Working With Application Objects and Controls.

• If your tested application is compiled as an Open Application, you may call methods defined by the application code or assign values directly to properties of the application’s internal objects. To call the methods and assign properties, you can use the On-Screen Action, Call Object Method and Run Code Snippet operations.

For information on simulating user input, see also Simulating User Actions.

TestComplete includes a number of methods that let you modify the sequence of methods and properties to be called by a script without having to modify the script code:

To verify that the tested application works as expected, you compare the application’s output with the expected values. For instance, if you test an Edit Order form, you can check that the total sum of an order is calculated with the appropriate discounts.

A good practice is to store the baseline values along with the test data in the data storage and use the baseline value for each portion of test data (that is, for each row). See Organizing Data Storages.

To compare values, we recommend that you use checkpoints. TestComplete includes a set of various checkpoints that let you compare data of different types: images, files, control text, database tables, and so on. To compare individual property values, you can also use the if... then... else scripting statements.