Inconsistent Running of Test Complete 12

[charles_1]

I am testing a desktop application which is written in VB, my tests run so far then I get either of the two following messages:

Subscript Out of Range

The Object Invoked has Disconnected From Its Client

I get this error on a function which has been used numerous times already in my tests run (up to 100 times already), if I restart the test from my test case before the error occurred then it will carry on and process more cases before getting one of the errors again.

I am finding it very frustrating that Test Complete is being so inconsistent and I have to run my test set in parts and hope it runs.

Any ideas why I would get these two messages?

[tristaanogre]

It would help to know what code is being executed at the points those errors occur. I suspect that the problem may be some sort of timing issue where you are attempting to execute something that your AUT might not be ready for. Please share your code.

[charles_1]

the line of code is the same for both errors:

if(grid.Columns.Item(i).Caption == header1) {...}

where grid is a vb constructed grid and header1 is a static string of text.

The test follows a simple loop, open test case, get figures from the grid close the case, move to next test case. I can process multiple test cases before getting the error and there are controls built in to make sure the grid is shown before doing the if statement.

[tristaanogre]

I have some experience with working with VB grids in an application we test and I've seen that error before... Usually, it's solved by making sure that the grid is fully loaded and, if anything refreshes the grid, actually call a "RefreshMappingInfo" call on the grid's parent.

However, the behavior you've described almost sounds like some sort of memory error, that the VB application is running out of available memory to include the information that TestComplete uses.

Are you keeping the application running between all the test cases or do you close and re-open on each one?

[charles_1]

I have a function beofre this one that wont carry on till the grid is loaded, so hopefully it isn't the first suggestion.

I don't close the application each time as it would take up too much test time. The application doesn't take up much memory space but TestExecute 12 does.

[tristaanogre]

Try, before your call of that If then, to do a RefreshMappingInfo of the parent object of the grid.  That might do it.

[charles_1]

I added the RefreshMappingInfo step but hasn't solved the problem.

[tristaanogre]

One of the things that I've observed in working with grids in a VB application via TestComplete is sometimes there are back-end processing things that are occurring that are not easily discernable.  A grid is displayed on screen and, based upon what I can observe of the grid, everything is where it needs to be so I proceed with my tests.  However, all the rows are not populated right away because there is an SQL query that needs to complete... or the grid hasn't populated all the columns yet because it is still resolving some code that determines which columns to display... or the grid loads... but then the MDI component that embeds an internet explorer page on top of the VB application refreshes...  Any number of things.

Just as a diagnostic test.... and I understand that this will extend your test execution time... but what would happen if, after you navigate to the form that has the grid, before you attempt any processing with the grid (variable assignment, etc), add a hard coded delay of 5 or 10 seconds... just to see what happens.  

[charles_1]

will give it a try. I have been having several timing issues since upgrading TestComplete from v7 to v12 without changing the test scripts.

[tristaanogre]

More recent versions of TestComplete have been a bit more aggressive in detecting components and in attempting to find objects.  Some of it has to do with improved efficiency of TestComplete... that it actually does run faster than it used to so what USED to work before doesn't now because of this efficiency.

Let us know what happens with the hard-coded delay.