Skip to main content
In this article, I will describe the usage of external files for storing of test data and their usage in TestComplete scripts. I will describe some good and bad variants for storing data and thus explain why I chose external files. Also, I will give general examples of functions that work with *.csv files and an example of building and using of *.csv file for search options.
Contents
Why in external files?
One of the classifications of test design divides all tests into 2 types:
- Tests that are managed by the behavior, using them we have to perform many different scenarios;
- Tests that are managed by data, each such test has only one scenario and it is only input data that changes.
Tests that are managed by data can be easily automated because we need to describe only one scenario. Though, we need to choose the right storage for the test data for the convenience of usage and support.
There are many variants for this:
- Text file;
- Storing of data in the TestComplete project in the Storages module;
- Excel table;
- Comma Separated Values (*.csv file);
- Databases.
The first experiment was a text file in the (Parameter=Value) format. That seemed to be the simplest one. But it was difficult to support and use the text file. Such files become difficult for perception after their volume increase. We need to watch over the spaces, tabulation, empty strings, etc. Besides, we need to write all functions for the work with text file from the scratch. Test Complete does not provide good tools to work with data in such format.
It is rather convenient to store data in TestComplete project itself. TestComplete provides good tools for this. I know people who use it and are satisfied with everything. There is only one problem for me in it: I need to install the full version of TestComplete and open the project. But automated tests are not always started by those who write them. It is often that those who start them do not know the specific of the automated testing environment. At the same time, I would like them to have the possibility to edit data, because adding a new set with data means adding a new test, as a matter of fact. That would give additional possibilities for the testing team.
Excel tables, *.csv files, and databases provide data storing in the table form. In my opinion, it is the most convenient way of storing. TestComplete provides an excellent module to work with such files, and I will tell about it below. I think that *.csv file is the most appropriate out of these three ways of storing. Again, I proceed from the fact that we can edit the *.csv file in Notepad. Of course, it is not very convenient but this can be useful at critical moments, when we have no time or possibility to install MS Office on the test machine. Usually, the file is edited in MS Excel in the same way as the *.xls file. The advantage of the Excel file is that we do not need to solve problems of setting the delimiter on each new system, though we can do it automatically for the *.csv file.
It is rather difficult to edit databases but they can prove useful if the input data has the complicated structure and it is not enough to have one table for storing it.
So, I chose to store data in the external *.csv file proceeding from my tasks:
- that who uses the script, should have the possibility to easily edit data or even add new data without changes in the script;
- I know that my data does not have such complex structure to create a database for it and that one table will be enough.
What tools does TestComplete provide?
TestComplete provides a special DDT (Data driven testing) module to work with 3 types of storage: Excel files, *.csv files, and ADO databases. I used TestComplete 7.5 for examples, but the DDT module is present in TestComplete beginning from the 5th version. We need to install tcDDTPlugin.pls DDT plug-in to use this module. Its presence can be checked in the <TestComplete>BinExtensions folder. All the work with this module is described in the help file (Using TestComplete -> Testing With TestComplete -> Data-Driven Testing).
For the correct work of examples, see also the following part of the help file: Data-Driven Testing -> CSV files – Using as data storages. This part describes how to set the delimiter for *.csv files. Semicolon (;) is used in the examples, that’s why if another delimiter is set in your system, you should use the schema.ini file as mentioned in the help file section. Examples are written in JavaScript syntax for TestComplete7.5.
Function for getting the parameter by its name
So, we have come to the practical part. First, let’s examine the structure of *.csv file for the tests managed by data.
Column header is the name of the parameter by which we get its value for each test number. Each following row represents a set of parameters for one test. Tests are performed in a loop.
Access to data in the *.csv file is performed via the DDTDriver object.
We need the path to the file that we will open to create such object:
var DataDriverPath = "C:UsersTestUserDesktoptestsearch.csv";
var CSVDataDriver = DDT.CSVDriver (CSVDataDriverPath); //create DDTDriver objectNow, we have a CSVDriver object and we can call all its properties and methods.
But we should not forget to release the file after we’ve finished work with it. We can create not more than 64 connections to one file. We can close it by the object name:
DDT.CloseDriver(CSVDataDriver.Name);
Let’s develop the GetParameterValue function to get the value of the parameter by its name. This function takes the name of the parameter, by which we want to call it (ParameterName), test number, for which we need to get the parameter (TestNumber), and the path to the file, from which we get all of this (SCVDataDriverPath). The function returns the value of the required parameter.
function GetParameterValue(ParameterName, TestNumber, CSVDataDriverPath)
{
//Open CSVDriver
var CSVDataDriver = DDT.CSVDriver(CSVDataDriverPath);
var str = 0, col = 0;
//Go to the required row (it is equal to the current test number)
while (!CSVDataDriver.EOF() && str < TestNumber)
{
str++;
CSVDataDriver.Next();
}
//If the end of file is reached and appropriate test number is not found
if (CSVDataDriver.EOF() == true)
{
Log.Message("Test number does not exist");
//Close CSVDriver
DDT.CloseDriver(CSVDataDriver.Name);
return null;
}
//Go to the required column (it is equal to Parameter Name)
while (col!=CSVDataDriver.ColumnCount && CSVDataDriver.ColumnName(col) != ParameterName)
{
col++;
}
//If all columns are checked and appropriate column name is not found
if (col >= CSVDataDriver.ColumnCount)
{
Log.Message("Parameter name does not exist");
//Close CSVDriver
DDT.CloseDriver(CSVDataDriver.Name);
return null;
}
var returnValue = CSVDataDriver.Value(ParameterName);
Log.Message("Return " + CSVDataDriver.ColumnName(col) + ": " + (returnValue));
//Close CSVDriver
DDT.CloseDriver(CSVDataDriver.Name);
return returnValue;
}To get the value of any parameter stored in the file, we call the following function:
var DataDriverPath = "C:UsersTestUserDesktoptestsearch.csv";
var FolderName = GetParameterValue(“FolderName”, 1, DataDriverPath);Log must contain
Return FolderName: C:userstestuserdesktop
Usage by example of search options
The task is as follows: we have the form of the file search that contains many controls to set the search parameters. For example:
Edit boxes:
- directory to search the file in;
- file mask;
- text to be searched in the file.
Drop-down lists:
- Code page
- Locale
Check boxes:
- Search options (match case, whole word). I define them by one in the file or both using a comma; default – default parameters (both parameters are not selected); empty field – also, both parameters are not selected.
- File attributes (Hidden, Encrypted, etc.). If the check box is selected, then only files with the corresponding parameter are searched for; if it is not selected, then only files without this parameter are searched for; if it is in the middle state, parameter is not considered when searching. The biggest problem is to store options for attributes where the middle state is met. The solution is as follows: by default, all options are set in middle state. If some of them are set as checked, they are written as they are; if they are set as unchecked, they are written with the exclamation mark before (as a negation). Here, a database would prove useful but we managed to deal with such parameters with a single table. We can use such words as all (all are checked), no (all are unchecked), middle (all are in middle state), and default (all are in middle state) instead of the list of options.
- File types (Text, Documents, Graphics, Media, Unknown, etc.). Here, we can define them using comma. Also, we can define the words all (all are checked), no (all are unchecked), and default (all are unchecked) instead of the list of options.
An example of the file for storing parameters of such search is as follows:
You can see functions for the work with options and examples of their usage in the Appendix section of the article.
Conclusion
Summarizing all mentioned above, we can single out advantages and disadvantages for each type of storing of test data. Everything depends on a specific task: on the complexity of test data, availability of TestComplete or Office applications, necessity to edit test data, etc.
Appendix
2 scripts are attached: Main.sj and SearchParameters.sj. To make the script work you should:
- Place the corresponding csv file by the path specified in DataDriverPath variable of Main function;
- Change the <names> in the SearchParameters file to the real names of objects of the GUI of your application in all lines that are marked with REPLACE! comment.
Continue reading our Blog with the development articles:
