Meet new TestComplete - v.10.20

Yes I can understand that perspective Alexei for new users to have all features enabled by default. It's just my preference to have things continue working rather than magically break when I run an update. Ideally, in situations like this, you notify the user of new "features" (plugins) during an update and provide instructions to enable/ prompt to enable them. Enabling things by default can cause just as many problems as it can solve, as Colin, and myself have experienced first hand.

I can see where you're coming from but I prefer disabled by default as well.



Reasons being:



1) If something doesn't work. I'll look for a solution to make it work. If it's stated during install that only basic plugins are enabled, this should be the first place you look.



2) The performance hit with them all on is huge. Really, really huge.



Prior to v10.10 I would not have been so bothered. But the difference I'm seeing since v10.10 is so massive I can only vote for "disable all by default".

Hi Tanya



Thanks for the update.



If they are going to remain all on by default, I think it needs to be made much more obvious that this is somewhere you should be aware of in terms of run performance. I know it's mentioned in the performance tips area but I just think it needs to be a little more prominent given the potential effect it can have. Not quite sure how or where you'd go about doing that though.



At the moment, I have the enabled plugins pared down to the very bare minimum. (For this particular test suite)



I only have Chrome Support, Open Applications and Web Testing enabled.



I will, at some point, try and start enabling extensions and running my test but this won't be a quick process. There are about 85 extensions in there! Over 80 of which I'm not currently using. Even doing it 5 at a time, that's 16 runs. And each run will need to be left for 5 or 10 minutes to get an accurate idea of how it's performing. That's several hours work. At least. I have a bunch of holidays coming up and a lot of project work currently on the go so I have no idea when I'm likely to get the time to do this. Not soon would be initial reaction. Sorry!



If your R&D people want to investigate it, try simply using a busy site so the DOM is quite heavily loaded and then running a simple test that searches out and updates or clicks a couple of elements on the screen. I found element searches (our site is heavily dynamic below the most top level elements so I can't map them) got much, much, slower. With only my 3 extensions enabled, it takes a few seconds to find some elements on the busiest pages. With all extensions on it was going way over a minute in many cases.



This is a page with multiple tabs, each tab with a webtable of varying size on it, each webtable containing an assortment of different controls. Textboxes, checkboxes, dropdown, colour pickers, icon pickers, etc etc. It's a big, horrible, complicated site and most of it (everthing within the tables pretty much) is dynamic and has to be searched out and identified at run time. I have a couple of fairly big data driven script functions that handle all this. They have to be fairly complex to deal with all the possible controls that may or may not be there and also to either validate whats in them or update them. It's all data driven by the user.

Whey guys, just updated firefox to version 29, TC stopped recognizing it as a browser.



Any hints?