using TC properties dynamically
my test requires to use TC properties dynamically, e.g. TestedApp.Params.ActiveParams.CommandLineParameters. After using the generated value, the Default value is reset. This leaves me with a st...
Forum Discussion
Well, if I knew how to do a save, this would solve my issue.
What I aim at is to run TE silently, controlled by a Scheduler. Therefore I don't want any GUI Actions like message boxes.
Concerning the TestedApps object, I will apply a Workaround using something like vbScript shellexecute instead of applicaiton.run, so I don't have to Change the testedapps object.
If you're running in a schedular as commandline, either with TestComplete or TestExecute, there is a "silent mode". This will bypass all UI dialogs by pressing the "default" button.
https://support.smartbear.com/viewarticle/81120/
Shared mode for a project is fine for editing code, tests, namemapping, etc... however, I have always found shared mode to be problematic for execution. Usually, for execution, I have my source control download a new copy of the latest projects into a different directory and execute from there. That has the bonus advantage of being able to have a set of tests executing while I'm still developing without having to worry about one "stepping" on the other.
TC is definitely not able to handle dynamically changed Project properties correctly in shared Project mode / multi-user mode.
I tried it with TC and TE running parallel, both dynamically changing the ODT tree: dynamical properties are changed by a first running TC/TE instance. When a second instance starts, it gets the properties in changed Status and changes them again. In case a third instance would start, it would get properties changed over and over. The property values You get depend on the call starting sequence of the instances and on their running time.
At least, the second instance fortunately doesn't make the first instance's property readings inconsistent.
Similar things can be watched with the TestedApplications Object.
It seems as if TC/TE get a local snapshot of the central Project properties when starting a test run. When the test is finished, or in case of ODT even during the test run, changes are written back to the central Project store.
The correct way to handle this would be to
- get a local snapshot of the Project properties
- store any changes EXCLUSIVELY in this local snapshot
- enable the script programmer/user to save or disregard when the test run is over.
So, I have to backup and restore some files on my own. Is there any way to determine during a test run, whether other TC/TE instances are already executing the current Project?
I ended up in doing it all myself.
In my shared mode configuration, I added a global ExecutionConfig Folder for the Project and one in each Host's config path.
In the global one, the Hosts running the Project at a time are logged.
The first host does a backup of the config data in question (e.g. odt.XML), and the last host finishing does the restore (in .cmd file after terminating TE).
