Forum Discussion

jeans's avatar
jeans
Occasional Contributor
15 years ago

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

Sort By
  • tppegu's avatar
    tppegu
    Contributor
    15 years ago
    What's wrong with project variables?
    And how would an xml or ini file be easier to edit than a script file?

  • jeans's avatar
    jeans
    Occasional Contributor
    15 years ago
    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.

  • tppegu's avatar
    tppegu
    Contributor
    15 years ago
    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.


  • jeans's avatar
    jeans
    Occasional Contributor
    15 years ago
    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.