Data handling support in TestComplete – Part 3

Using Data Storages:

When I say “Data storages” here, it’s the data sources like Excel, CSV, ADO table or simple text files which lie outside Test complete. Yes. We can have our data (test data/ expected data) independent of our Test complete projects. Also Test Complete supports good interfaces to get/set these data stored else where in the system.

Mostly when we need to build a robust Test automation framework or asking for a data driven approach, the answer might be just separate the data and the code (scripts) which uses it.

Few advantages when choosing this approach are:

1. Dependability is less which eases the development and upgrades.
2. Since data is kept outside of any automation scripts/tools, even novice users who have minimum implementation knowledge can manipulate the data easily.
3. Just pile up the data as new test cases are written for same implementation.

Test Complete provides DDT object which has methods and properties to connect to a data source, read data, assign back the results and iterate through the collection or rows and columns.

I have written a post https://automate101.wordpress.com/2010/07/27/data-driven-testing-with-testcomplete-part-2/ which explains the DDT object and sample scripts to fetch data from data sources.

a) Scope

Since these data sources lie outside TestComplete we can access them in from of the scripts and even across multiple projects. For example, single excel workbook can hold data in separate worksheets for different projects.

b) Easy Accessible:

The previously discussed (Project variables/Stores) data storage options require the help of Test Complete editor to view or edit the data stores in them. But this option doesn’t require Test Complete to be opened. Provides easy viewable options if excel or ADO table are used. Supports multiple connections to the data source and have manipulation of data inside scripts can be done with few statements

c) Adapting to changes

The scripts will be robust enough until we are modifying the schema of the data storages. Any point of time we can change the data source itself ie., data from excel sheets can be migrated to Ado tables with just minor changes in the driver scripts. Because the DDT object provides similar approach (methods and properties) for all the supported data storages.

Using Storages Object

Using “Storages” object we can manipulate data from special or complex storages like INI, XML, BINARY and REGISTRY files. As you know we cannot directly access these files like text files and require good methods for the same.

Our implementation may have requirements to store data using these file types. Also more complex, system/configuration related data or hierarchical data can only be stored in these types of files. If you are committed to use these data sources, Test Complete supports you with object called “Storages”. This is an add-on support and you need to make sure whether your tool has it. Just navigate to “File -> Install extension” dialog and verify where it is checked as shown below.

 

Storages add-on as extension in TestComplete

To use this feature in Test Complete, store the data in any of the formats like INI, XML, BINARY and REGISTRY and save the file. Inside the scripts use Storages object and its methods to manipulate data. Below you can find a sample JScript to read data from an INI file and displays them in test log.

function ReadINI()
{
 var objSection = Storages.INI("D:\\Employee.ini");
 Log.Message("Total Sections : " + objSection.SectionCount);
 var section;
 for(var idx=0; idx
 {
 section = objSection.GetSubSectionByIndex(idx);

 Log.Message("Section : " + section.Name + " has :-");

 for(var idy=0; idy
 {
 Log.Message("*** " + section.GetOptionName(idy) + " = " + section.GetOptionByIndex(idy));
 }
 }
}

Similarly using corresponding drivers we can use XML, Registry and Binary files.

a) Scope

Storages object cannot be used inside Script Extensions. Inside test complete you can access this object anywhere in the script. Also you can open the file, store them in “FileSection” object and pass as parameter to different functions.

b) Easy Accessible:

One advantage of using this object is we can manipulate complex and hierarchical file structures. Also the “FileSection” and “Section” objects gets the file similar to the physical view. For example the when we open a registry file, it returns as sections which in turn has options, thus enabling us to view the exact view of the file data.

c) Adapting to changes

The files can be stored independent of project. The Storages object uses similar kind of methods for all the 4 supported types. These two features helps us to change data and its corresponding code independent to each other.

Hope there are 101 ways to Automate !!!

Thanks & Regards,

Giri Prasad