cancel
Showing results for 
Search instead for 
Did you mean: 

Best way to keep custom settings in TestComplete

Occasional Contributor

Best way to keep custom settings in TestComplete

Hi,



I presume we're not the only ones who use some custom settings to prevent hard-coded paths, usernames, timeouts etc.

At the moment we keep a set of public constants in a central script.

This approach works, but user access to the settings is limited and I'd like to have a user-editable text file, in xml or ini format - this also has a benefit of adding at least one dimension to the settings to make them more robust (at the moment we use prefixes, e.g. FN_ for file names)



Bottom line I want to be able to access the data from VBScript using something like MyPath = CustomSettings.MyPathValue



Is there a recommended way to handle this?



Thanks,

Jean
4 REPLIES 4
Contributor

RE: Best way to keep custom settings in TestComplete

What's wrong with project variables?
And how would an xml or ini file be easier to edit than a script file?

Occasional Contributor

RE: Best way to keep custom settings in TestComplete

People who run TestExecute don't have as much flexibility as those who use the TestComplete IDE.

And text files are better because you can keep multiple copies with different settings and script files come from version control.

Contributor

RE: Best way to keep custom settings in TestComplete

Ah, I see. It wasn't clear that you were thinking of users who couldn't use TC for editing. That is a common problem.



You could use a script file that simply isn't included in your version control system. That gives you the best of both worlds; editable both in and out of TC.



Personally, I have used both xml files and spreadsheets for this sort of thing in the past, but I am currently moving towards a database system. More work to set up, but so far it has been totally worth the effort.


Occasional Contributor

RE: Best way to keep custom settings in TestComplete

Thanks Tony for your thoughts, but for now DB would be a total overkill in our case.

And editing values in DB is even more complex (for those who run the tests) than your previous suggestions - guess I'll stay with text files for the next couple of years.

Now making a nice infrastructure for accessing the settings might be useful as it lets me replace the data storage method at a later stage w/o affecting the rest of the code.
New Here?
Join us and watch the welcome video:
Watch the New Interview
APITestingMistake#2
Top Kudoed Authors