Hi Andrey,
My approach is an extension of Phil's one. :) It probably is more complex, but once implemented also works well for me.
Generally speaking, project variables in TestComplete are great feature. Especially considering that their values become local for the given machine if the test project is opened in the networked mode, so you may use them without the risk that your changes will influence someone else running the same project on another machine.
The bad thing is that project variables can be edited from within TestComplete only, so you cannot adjust their values if you have only TestExecute installed on the given test box.
Also, if you store long data in the project variable (e.g. login URL) and have more than one value for the given test box (e.g.
http://testServer1/App_v6/ and
http://testServer2/App_v7/) and would like to switch between these values periodically, you have to either memorize those data or store them somewhere (e.g. in the Description field for the given project variable).
Considering the above, I am using not .ini, but .csv file. (Why .csv? Because it can be edited with any text editor that exists on the given box, does not require special software (e.g. Excel for .xls files) and is easier to understand when compared with .xml, for example.)
This .csv file has these fields:
Active,ID,Machine,Name,Value,Comment
Active - a True/False flag that indicates if the current record should be used or ignored;
ID - just an id with whatever value;
Machine - the name of the test machine;
Name - the name of the parameter;
Value - the value of the parameter;
Comment - any comment
Using the above structure, I can have a file like this:
Active,ID,Machine,Name,Value,Comment
False,0003,,Browser,btIExplorer
True,0003,,Browser,btChrome
True,0003,TestBox1,Browser,btSafari
True,0003,TestBox2,Browser,btFirefox
And a function that gets value for the requested parameter:
strBrowser = SysTestConfigRecordsetGetValue("Browser")
When this function is executed on the TestBox1 machine, the returned value will be btSafari which means that the tests on TestBox1 will be executed using Safari browser.
Likewise, if the test is executed on the TestBox2 machine, the function will return btFirefox.
Records without machine name are the ones that are used as a default values. This means, that if SysTestConfigRecordsetGetValue() function is called from TestBox3 machine, the returned value will be btChrome (not btIExplorer because the record for btIExplorer is marked as inactive).
Note, that, for example, if you like to change the default browser from btChrome to btIExplorer, you should not edit the value for the browser name, but instead may just switch the Active flag:
True,0003,,Browser,btIExplorer
False,0003,,Browser,btChrome.
Likewise, if you like temporarily use Opera browser on TestBox2, you can just add a new record for TestBox2 and keep the previous record by making it inactive:
False,0003,TestBox1,Browser,btSafari
True,0003,TestBox1,Browser,btOpera
So, what the above approach gives to you:
-- You have configuration file that can easily be edited on the target test machine;
-- You can keep configuration records for different test machines within one configuration file;
-- You can have more than one configuration record for the same parameter for the given test machine and switch between these records easily;
-- Default values are provided for the machines that are not explicitly specified in the configuration file.
Hope that the above will help you and you will extend the suggested idea/approach.
