Some interesting ideas from all!
What we did in the end is create a test called SetProjectVariables and in it we assigned each of the ProjectSuiteVariables to themself. So the file might look like this:
function Test1() {
ProjectSuite.Variables.Name = ProjectSuite.Variables.Name;
ProjectSuite.Variables.Path = ProjectSuite.Variables.pathvar;
Log.Message("ASPName is - " + ProjectSuite.Variables.Name);
Log.Message("pathvar is - " + ProjectSuite.Variables.Path);
}
We added the logging of the values so when somone came to QA and said "it's failing" the first thing we could check is what they set the system wide variables to as that is often the problem.
Turns out we can open this script file and edit it using UltraEdit. So the process for someone using TestExecute is to grab the test suite from the repository and then edit the above file using UltraEdit to match their environment, start testexecute, run this file as the first one in the test suite and it works as expected.
So if I was running TestExcute I would edit the file to look something like this:
function Test1() {
ProjectSuite.Variables.Name = "bobs_test_run";
ProjectSuite.Variables.Path = "c:\tmp\testexcute\bob";
Log.Message("ASPName is - " + ProjectSuite.Variables.Name);
Log.Message("pathvar is - " + ProjectSuite.Variables.Path);
}
The reason we assign the variable to itself is that makes it work as expected with TestComplete and gives the TestExecute users a place to edit and change the global ProjectSuiteVariables.
You can add as many ProjectSuiteVariables as you want in TestComplete and add them to this file and the TestExecute users can then change their values as needed.
