TestComplete (Code Editor) is slow

My commentary. :-)

1. The Code Editor is slow. I can type faster that the editor can show.

Couple of things may be contributing to this.  First of all, syntax highlighting has update everything on screen to match what you're typing so, as you're typing strings within the quotes, it has to update lots of junk.  I haven't seen much performance hit on this but I've seen it have some, especially on very large code units.  Secondly, under Tools | Options | Panels | Code Editor | Editing, if you have "Code Completion" set to auto-popup, it's going to try, as you type, to parse out what you're typing to determine if it should pop-up suggestions for automatic code completion.  Personally, I find that annoying and it can be invoked by a simple keystroke.  Try turning that off to see if this corrects things.

2. I cannot Edit while debugging.  Explanation: Stepping through the code I find bugs. So I want to fix them, add a comment, or something like that. I know I cannot expect the script reflecting the changes during the current run, but I want to edit the files for next test run.

Unlike the Delphi IDE (or any application IDE for that matter), when you're running the test, you're not running on compiled code, you're running scripts and so what you see on the screen in the editor is, actually, what's running.  So, editing the script file while the script file is in the process of execution is, sorry to say, non-sensical in this kind of environment.  Now, I like the idea of tossing in comments or something as you go but that feature doesn't currently exist in TC so it would have to be prioritized and added by the actual SmartBear folks.

3. Stopping a test: I have to wait several seconds (5-10) until I can type again. I have disabled that the testresults are shown after the test run. This saves a lot of time. Before it was very very anoying (spot a bug, stop the execution, click on the line to fix it, *bam* TC takes away my editor and switches to the test results).

Depending upon what you're doing during your test, there are probably a lot of "clean up" things that need to be done and written to disk at the end of your test.  Even though you're not viewing the test log automatically at the end, there are some steps to flush the final log to disk, properly associate it with the project, and save the related project files to disk that may or may not have been altered.  These are just guesses, to be honest, but as far as I can tell, it's that bit of overhead that is necessary for flushing certain files to disk.  Again, it's the difference, I believe, between compiling an application and running it and running a set of script files that are accessed directly during run time.

I encountered several UI bugs which are not as problematic, but are annoying too:    * Test Item-Tree: Drag&Drop doesn't always behave correctly (a flat list gets completely nested when dropping on another item)   * Deleting a Item from the Watch List via <DEL>, Confirm Dialog, Item is deleted, next item is focused, <DEL>, Confirm-Dialog, nothing happens

I'm sure someone from SmartBear will come along and deal with these.  However, they do have a direct support portal for documenting bugs like this and getting actual trouble tickets.  Try it here

Compared to my main development environment (Delphi) TestComplete feels awkward slow. I'm really disappointed. The "Run Test"-"Fix Bug"-"Run-Again"-Cycle takes so much time which makes me so frustrated after some minutes working.

Again, it may be the difference between an IDE that creates code for later compile and an environment in which the script files themselves are the actual "application" to be executed.  



On thing of note, you say you have over 400 script files in your project.  In my previous life, I worked with a pretty highly complex application and automated a large portion of it and I never had 400+ script files.  Are these script files code units of libraried utility code or is each unit a test or collection of tests?  To have that many files to be parsed and syntax checked as you're writing may be part of the slow-down as well.  There are design techniques and such for automated testing that can reduce the number of script code units and increase your speed.  Data driven or table driven testing for one.  Also, if you have a lot of universally useful code, you can create Script extensions or even your own plug-ins for TestComplete so that you may not need quite so many code units in your actual test project.

Actually, I've found TC 8.70 to be considerably slower than TC 8.50.  Sometimes it takes upwards of 5-6 seconds to load up syntax highlighting.  It really shouldn't take so long.



But all in all, they are minor annoyances to me.

Hi Vince,



To look into this issue, we need to get more information. Please contact us directly via the Contact Support form and provide us with following information:



1. A short video demonstrating the 5-6 seconds delays while loading syntax highlighting. For example, you can use Jing to record it.



2. Your zipped project suite along with exact steps to recreate the problem.



3. Information from about your system: run the msinfo32 utility (Start | Run...) and save the information it collects to an *.NFO file (File | Save...).

Hi Lynn,



This is odd. Perhaps, you just rebooted the machine. :)