Forum Discussion
AlexKaras
12 years agoCommunity Hero
Hi Curt,
> Perhaps 10.4 is executing faster than previous versions so that it's actually finding both objects before the first gets destroyed?
Yes, most probably this is the reason.
The case is that:
a) guys at SmartBear pays a constant attention to the performance of TestComplete;
b) web applications almost always don't have objects ready in the memory (like the regular desktop applications do) but generate them after some data exchange with the server and;
c) used objects are not destroyed immediately but after some timeout when they are collected by the garbage collector.
Considering the above, my experience is that it is perfectly OK to write something like this (pseudocode) for the desktop:
parent = panel_frnCards();
Click(myCards_remove_link(parent, card.number ) );
Click(myCards_link_confirmRemoval() );
But in the case of web applications, the same pseudocode must look like this:
parent = FindAndWaitForExists(panel_frnCards());
Click(FindAndWaitForExists(myCards_remove_link(parent, card.number )) );
Click(FindAndWaitForExists(myCards_link_confirmRemoval()) );
I.e., every time before you interact with some UI object, you must search for it and ensure that the target object exists. This means that you are giving enough time to the page background script code to communicate with the server and generate and display the required UI elements.
The above approach may slow down tests execution speed, but increase their stability and your task will be to find an acceptable balance between code performance and stability of objects identification.
> Perhaps 10.4 is executing faster than previous versions so that it's actually finding both objects before the first gets destroyed?
Yes, most probably this is the reason.
The case is that:
a) guys at SmartBear pays a constant attention to the performance of TestComplete;
b) web applications almost always don't have objects ready in the memory (like the regular desktop applications do) but generate them after some data exchange with the server and;
c) used objects are not destroyed immediately but after some timeout when they are collected by the garbage collector.
Considering the above, my experience is that it is perfectly OK to write something like this (pseudocode) for the desktop:
parent = panel_frnCards();
Click(myCards_remove_link(parent, card.number ) );
Click(myCards_link_confirmRemoval() );
But in the case of web applications, the same pseudocode must look like this:
parent = FindAndWaitForExists(panel_frnCards());
Click(FindAndWaitForExists(myCards_remove_link(parent, card.number )) );
Click(FindAndWaitForExists(myCards_link_confirmRemoval()) );
I.e., every time before you interact with some UI object, you must search for it and ensure that the target object exists. This means that you are giving enough time to the page background script code to communicate with the server and generate and display the required UI elements.
The above approach may slow down tests execution speed, but increase their stability and your task will be to find an acceptable balance between code performance and stability of objects identification.