When TestComplete doesnít find an object name while recording scripts, it assigns a number (like, Item(69), Item(34), etc) names. And I heard itís not safe to use those names as they changes often on different run making script unreliable.
So my question is; is it a myth? If no then does it applies to both Web based & Windows based applications? The application that Iím testing hasnít changed it name (Item(69)) for past 2 weeks that Iím testing. So should I continue with it or look for an alternative.
Also, Iím using FindChild method to get those objects to be on safer side but apparently take a lot of time in finding them (locating it using 2 different properties using array example that sometimes takes about 2-3 minutes(depth=20)).
Iím testing windows based application & a very complex one with many of them having same properties. And if I get an assurance that itís safe to use TestComplete generated ĎNameĒ then it would really help me or if you show me an alternate way of finding an object other than FindChild method then I would appreciate that too.
The item number changing is more likely to happen with a web application that a windows app (depending on the type of windows app). If you a dealing with a static page, the number will not change until someone decides to add a new html element before your element then the number will change. It would be better if you can get the developers to assign ids to the html elements that you want to use in your tests.
As far as I understand, the key problem with using generated names is script reliability and maintainability (though readability also suffers).
Since the names are assigned consecutively, a trivial change to anything that comes before the item you're using can easily change your item's number and cause subsequent script failures. When something like this happens, it may be very difficult/time-consuming to debug and fix the problem (though the final script change, itself, will probably be trivial; you know: "$1 for pushing the button; $2000 for knowing which button to push"). As a result, your "automated" testing stops being so "automatic."
If the performance is more important than the script resiliency offered by FindChild() (or other alternatives), you could at least make future occurrences of the above-mentioned problem much easier to recognize and fix by adding some key verification code. For example, you could precede every usage of an "Item(#)" object with something like <font class="small">Code:</font><hr /><pre>If (MyOjectProperties <> WhatIExpect) Then
Call Log.Error("Not the object I expect.")</pre><hr />
Anyway, have you considered using the NameMapping/Aliases features? They might solve the problems you're having, here.