The process I've used before is that the TestComplete project that does the unattended runs is not one that people actually work in. No one ever changes the project settings in that one and the individual tests just get updated as necessary.
That's for a tested app that TestComplete launches, not TestComplete itself. I saw that TestComplete's Runner object has a Runner.Pause() method to programmatically pause when in debug mode, but there's no way to test if we're in debug mode (Runner.Pause() looks like it will do nothing when debugging is disabled).
Maybe we should just resort to launching everything from TestExecute.
What is your objective for having the debugging run?
We are just wanting to be able to leave debugging turned on in TestComplete, and if we kick off a whole project suite test run overnight it checks if debugging is turned on and alerts you as one of the first things the test run does.
We have had several nights where we kick off a run only to find out the next morning it ran into a breakpoint and stopped the test run.
I do concede that this is a process problem, we should be ensuring debugging is disabled in TestComplete before we kick off a project run, or just using TestExecute. Just hoping there was a way to catch if someone doesn't follow the process.
