You can just switch them all off. Switch on the obvious ones you know you'll need. Then run the test. If it's missing an extension it needs, you'll figure that out pretty quick when it fails, re-enable the needed one and try again.
You can't actually break the test by disabling extensions. Stop it working, yes, but it's not actually broken. If all else fails switch them all on again and you're no worse off than when you started.
Can make a world of difference performance wise. Some of my bigger suites run several hours so a 30% performance hit can make a BIG difference ...
My joy only lasted until (it seems) the first time I ran a test. For several hours after turning off the unused extensions, I didn't have a single incident of TestComplete not responding where it had been happening almost every time I would switch between tabs in the workplace.
After I ran a test, the freezing returned. I checked and all of the modifications I had made to the extensions were still good so I don't know what's going on. I tried shutting down and restarting TestComplete and my machine with no luck. The odd thing is, if I watch Task Manager when TestComplete has "frozen", the CPU usage seldom goes above 0% on the TestComplete process, and indeed the overall processor usage is around 1% (at this time).
All I can tell you is that it makes using the IDE next to impossible. Waiting 30 to 40 seconds every time you switch tabs in the interface is not acceptable under any circumstances.
William
So it was OK (after switching off extensions).
Then you run a test and it's not OK.
And after a complete re-start of everything it's still not OK?
Weird.
That it was OK prior to running the test would suggest that running the test causes something, somewhere, to make everything start locking up. No idea what though. The strangest part is that even after a total restart, it didn't return to it's OK state.
Was whatever was being tested also started up after your reset?
Do you have any other tests you can run, on completely different applications, of a completely different type?
So at least you can try and pin down the trigger, even if we don't know whats actually happening yet ...
The only time I tend to notice obvious slowdown and hangs with testcomplete is when it's trying to show an especially heavy object model. In your object browser, if you set it to only show tested apps, does it make any difference?
Sorry I didn't reply to this earlier, but I had a project that had to be finished last week and development was going extremely slowly due to the freezes.
I was trying to keep an eye on when these happen but its pretty erratic. I got some relief from tagging 'Show only tested apps' in the object browser but it was not consistent. At other times, while showing only tested apps, if I hide the Object Browser, that can also give some relief, but again, not consistent. Still at other times, there is no problem at all. I did notice that when things were going well, if I displayed the Object Browser to check something, the freezing was more likely to return than not. In these instances, hiding the Object Browser again would not clear things up.
With respect to my environment, restarting my machine does not start any of my TestedApps; they are always explicitly launched at the beginning of testing - no acceptions.
Does TestComplete 'audit' the TestedApps on a timed basis for any reason? If so, perhaps if I were to remove all TestedApps and create them at run-time, that might make a difference.
I did do a full shutdown of my system again this morning and since restarting, TestComplete hasn't had any issues. Other than the restart, nothing has changed since Friday when it was being quite uncooperative.
hi bduncan,
I recently begun to manage all my testedApps in runtime, and now I just can't imagine doing differently.
It does sound like the problems may be due to it trying to manage one or more very large object models?
I do get the odd bit of lag in name mapping, object browser etc when I have a lot loaded up. But it's never more than a few seconds and only when it's a very busy object model ...
hi Colin,
Maybe, I test two huges Delphi exe.
One NameMapping.tcNM file is more than 2Mb large...
It is looking like TestedApps is the culprit. If I remove the TestedApps object from my project, there is no freezing at all (2 hours and counting), even if I leave the Object Browser open and showing all processes.
If I load a new, blank TestedApps object, no problem at all. When I remove the empty TestedApps object and replace it with my original, freezing starts immediately and continues.
At this point, I'm going to create a new, empty TestedApps object and create them in code to see how that works out.
Might explain why I've never hit these problems then as the TestedApps object isn't one I use.
Control all my application/browser/site launching and management via scripts as my tests are all user data driven so have to be super-flexible ...
Thanks for all of you input, Colin_McCrae; it helped to finally whittle down the problem. When I took over this system 6 years ago, TestedApps where set up and didn't cause this issue through version 7.5; as soon as we upgraded to 10, it started happening and has grown worse until 11.20 where it made the product almost unusable.
I'm glad to be past that now so I can catch up on stuff that I need to do.
