How to shorten Aliases?
I'm working on a Java app which is built in Eclipse. The object names tend to go very, very deep. For instance, the start date on a parameter form to a report is mapped as: Aliases.WCAN.BIRT_...
Forum Discussion
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...
[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...
