Namemapping with extended find - invisible Alias?

Kresten,



Have you tried to use Flat "Object Tree Model" for Smoke project mentioned here:

http://support.smartbear.com/viewarticle/11302/

It might work, if you organize NameMapping based on UIDs.



I would suggest try to keep "Tree Model" for Regular project. Because UI complexity can make flat view very hard to understand and maintain.

Hi Dmytro,



Thanks for the suggestion. I tried it but as luck would have it, it does not work with my AUT. Perhaps it is a MDI and thus parent/child relations are mapped in TC :-(



So right now I am faced with three options:

1. Use extended find (and loose the ability to see which objects are mapped)

2. Use manpower to edit the namemapping with each new build (not really a practical option)

3. Try to implement a framework for binding UIDs with Aliases or global variables (sounds like a lot of wotk)

4. Forget about running smoketests until the AUT has stabilised (project management & developers will be unhappy)





Again thanks to you all for your input,

Kresten

Hi Kresten,





I have a suggestion that may work for you: use the Required Children functionality in your Name Mapping tree.





Since the objects have unique IDs, you can map them reliably, but for the parent object, leave only a minimum set of recognition criteria (e.g. only ObjectType) and mark the child object as Required. Build a chain of "Required Children" up to a stable parent object.





If the number of intermediate objects between the stable parent and the sought-for tested object does not change, this approach should work fine.





To learn more about this functionality, check the Creating Reliable Tests For Dynamic Objects with Name Mapping webinar recording, and the Specifying Child Objects Required for Mapped Object Identification help topic.





I hope this helps!

Hi Alex,



Thanks for the input. Although this is a clever approach I don't think it will work for this particular AUT. The number of parent objects/levels do sometime change and also the path. So a child may have different parent objects from build to build.



This is why the extended find option is really great except that it makes it difficult for out testers to create scripts.



Best regards

Kresten

Hi Kresten,





Since the Extended Find option makes TestComplete perform a heavy search operation every time an object is accessed, our abilities for improvements are quite limited here. But anyway, we will try to make things a bit simpler in one of the future releases - the objects that are mapped with the Extended Find option will be correctly used during test recording (which is not the case right now due to performance considerations).





This will not make the MappedName property have a real value in the Object Browser, but it will simplify tests creation a bit. The work is ongoing, but no ETA so far.

Hi Alex,



Thanks for the feedback!



For our team a performance penalty would be OK given that we could see the Aliases of objects with extended find enabled. But others may have a different opinion :-)

May I suggest a Project option alone the lines of "Use Alias on objects with extended find enabled during recording" [On/Off]. And also I would be very happy if you consider making a button of checkbox in the object spy window along the lines of: "Search for Alias in entire tree?" [On/Off].



This would allow most users to get the faster performance but also allow others to get the information that they need. Please consider this last suggestion as it would be very useful to us :-)



Best regards

Kresten

Hi Kresten,





OK, we will consider implementing this functionality in the next major version of TestComplete.

No specific information / details/ ETA yet, but this will be discussed appropriately, since this seems to be a reasonable request.





Thank you!