A typical data-driven test performs the following operations:
Reads a portion of test data from the data storage.
Inputs the data into edit fields of an application’s form.
Verifies the results.
Continues with the next portion of test data.
TestComplete includes special means that simplify performing these actions in test scripts. This topic describes them:
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
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:
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:
||Returns a driver object for the specified database table. The test engine connects to this table via ADO.|
||Returns a driver object for the specified CSV file.|
||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.
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:
||These methods are used to process a list of strings. To parse comma-separated values, you should assign a comma (",") to the
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 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:
||Calls method of an object by method name.|
||Retrieves and sets a property value by its name.|
||Evaluates an expression or executes a routine by its name.|
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.