How to shorten Aliases?

In the Alias panel, you can click on a child object and drag it up to a grandparent object to reorganize the Alias.  NameMapping should, as much as possible, preserve the hierarchy, but the Alias can be shortened this way.



So, technically, on the Alias panel, you can drag Startdate_Text and make it a child of any object in the hierarchy up to the final cell.  You could make your alias as short as Aliases.Stardate_Text if you want to.  see http://smartbear.com/support/viewarticle/12465/

That will work, but it still doesn't help with the problem that the name mapping is still > 20 layes deep.  It is almost impossible to find the correct object without expanding multiple branches.  What would be nice would be adding additional properties to identify object, then have TC use those to find the object, regardless of the hierarchy.  So there could be 25 "panels" somewhere on the screen, but since there's only 1 text box called "Start Date", it just maps it without the extra panels to get to it.

Hi,



[Just rumbling to myself, so don't take it seriously...]



>That will work, but it still doesn't help with the problem that
the name mapping is still > 20 layes deep.

This is because NameMapping makes direct map of the the physical GUI structure to user-friendly names. [This is developers' or used tool problem that they put an enormous stack of useless intermediate objects that maybe make the life of the tool's developers a lot easier but degrade both performance and end-user's experience.]

Aliases is the means that was created to ease exactly this problem by logically reducing objects' hierarchy depth. And I think that the best approach here is to follow the advice by Robert Martin, the essence of which is not to start recording immediately and then fight with the NameMapping and Aliasing created by default, but first identify the GUI objects the test will use, than map them manually, then reorganize Aliases tree so that it is convenient for your needs and only then start test recording (so that TestComplete use existing Aliases tree but not create it during recording).

It is possible to reduce the depth of the NameMapping tree by using Conditional mapping (see the relevant TC help topic for more details), but this should be done in advance as well, but not during recording.

I think that the above is the only reasonable approach (not considering the pure coding one utilizing the FindChild() function) to have a maintainable tests created using modern web and WPF technologies.



> It is almost impossible
to find the correct object without expanding multiple branches.

Thoroughly considered Aliases should help with this problem.



> What
would be nice would be adding additional properties to identify object,
then have TC use those to find the object, regardless of the hierarchy. 
So there could be 25 "panels" somewhere on the screen, but since
there's only 1 text box called "Start Date", it just maps it without the
extra panels to get to it.




This might work indeed (not considering performance penalties because in this case TC will have to analyze the whole objects' tree to ensure that the object being mapped is unique for the given page/window/etc.), but only until developers later decide to add one more similar object within the scope of the already existing one. And how to manage this case is not clear for me at the moment...

An alternative to using the built in NameMapping and Aliases feature is to use FindChild, FindAllChildren, and similar methods.  So, you have an application and you want to find a particular box using a set of properties, you can do something like this.

var MyApp = Sys.Process("MyApp")

EditBox = MyApp.FindChild(["Property1Name", "Property2Name", "Property3Name"], ["Property1Value", "Property2Value", "Property3Value"], 30)

The above code will find the particular child object desired based upon the mapped array of properties and their corresponding array of values, searching down to a depth of 30 child objects.



IMO, this is a bit more cumbersome as you need to write this kind of code all over to manually find the components where as the NameMapping tool, essentially, does this already for you.  The true beauty of NameMapping is in the Aliasing... as Alexei said, spend some time up front mapping those objects, components, etc, that you know you'll be interacting with and then adjust the Aliasing to "flatten" out the hierarchy to something more maneagable.



Also, IMO, recording is not the best way to populate the NameMapping because you have little control over it.  Even after you record, you will still need to go back and adjust what properties are being used for the mapping, what names are being assigned to the component (so it has a name like "StartDate" instead of panelcalendarstartDate51231), and how deep the hierarchy is.  I don't think recording is any time saving in this case but actually adds time.  It's much more efficient, IMO, to do all the mapping up front and then do the recording... or, for that matter, I rarely bother with recording anymore except to give me a general "What is the order of the steps in this task" and I usually hand write library code to do what I need it to do.

Under what circumstances can't you move objects up in the Alias?  I have the follow:

Toolbar->cell->button1 and Toolbar->cell1->button2.  I would like it to end up as:

 

Toolbar->button1

Toolbar->button2 (both buttons under toolbar).



TC let's me move button2, but then won't let me move button1.  The buttons are uniquely identifed by their "alt" name property.



JBC

What is the best way to learn all the objects in an application?  In some tools, there a feature in the object map to automatically learn all items in a window recursively.  I've found how to map objects 1 at time, but is there some way to have TC map all the objects recursively in a window?

You can't move items up in the alias if the NameMapping does not correspond... if I have MyApp -> MyPanel -> Button1 and MyApp2 -> MyPanel -> Button2, I cannot move button 2 to MyApp because it is not in the hierarchy.



I suspect that, in your example, one of two things is the problem... either there already exists a child item off of ToolBar with the same name or mapping criteria so it is preventing you from putting them on the same level to avoid ambiguous or duplicate mappings...  Or, your mapping is not necessarily the same between the two components.  I'd double check the NameMapping hierarchy and make sure the relationship exists there properly.



As for "learning", in NameMapping, if you right click on an item already mapped (like your application), and select "Map Child Objects", it will map all child objects off there... it won't recursively drill down, but you can map upward from a lower level.

I'll try mapping some of the application first and organizing the Alias map to see if that helps.  Unfortunately, due to the insane number of "dummy" objects, it'll take longer since I have to map 3 or 4 iterations of child object until I get to the real one that I want.



This must be something specific to using Eclipse as a development tool.



Thanks



JBC