Once upon a time there were three strangers: Object Browser, Mapped Objects, and Name Mapping (Aliases). Each one had their own panel in TestComplete land but none knew of the other. The Object Browser was the oldest and wisest because he saw everything on a screen. Despite his knowledge and vision he was “old school” and never learned to refactor/rename or speak abstractly (spin*). He was long winded and spoke gibberish:
Sys.Browser("firefox").Page("http://localhost/CMWebTest/Go/?p=/CMWebTest/cribbin/cribbingridproperties").Panel("primaryWrapper").Section("primaryContent").Frame("t_CMWebTest_cribbin_cribbingridproperties_content").Section("actionWrapper").Section("actionContent").Panel(0).Table("splCribBin").Cell(0, 0).Panel("splCribBin_0_CC").Table("gridView_CRIB").Cell(0, 0).Panel(1).Table("gridView_CRIB_DXMainTable").Cell(1, 1)
Using this approach was highly fragile and broke when the object hierarchy changed (and they always do).
TestComplete land had a social program which attempted to help (Map objects automatically) but was unfriendly and somewhat dangerous - especially if ‘Use extended find when possible’ was enabled.
The next oldest was Mapped Objects. He learned about objects while traveling down the Keyword Test highway and the ‘Map New Object’ button was used during object recognition while creating test steps. However, Name Mapping(s) are not generated and leaves a disconnect between Mapped Objects and Name Mapping (Aliases).
His approach wasn’t browser friendly (sys.browser v. Alias.Browser)
and left a gap between Mapped Objects and Aliases. He was somewhat convincing but had only his own self interest at heart. There was a social gathering in town where he would show town folk this ‘Map New Object’ button but didn’t tell them of it’s shortcomings.
He could map objects but many assumed this included Name Mapping and many were fooled. He later shared there was more which needed to be done to be useful (Manual Name Mapping). Had the townsfolk realized how tedious and pearlous this journey was they would have never listened to him had they known.
The youngest, fastest, and smartest was Name Mapping. He could refactor/rename at the speed of light and provided the most use of anyone in town. And he was browser friendly (Alias.Browser) and a little bit wild (*). His wildness provided great benefit and flexibility never before seen. The problem was there was only one place they could meet and the townsfolk were not told.
And then one day at a town gathering the Object Browser spoke out and said, “I may be the oldest but don’t forget I am also the wisest.” And then he proceeded to share his magic. He said, “If you map from me I’ll give you both Object Mapping and Name Mapping (unlike those younger whipper snappers). He said, “It is easy - let me show you how.”
"Before using the object in a test, map it using me", said the Object Browser ...
First, use the ‘Object Spy’ button to identify the object.
Then use the “Highlight Object in Object Tree” to easily and quickly find the object in the Object Browser.
And map from there by right-click on the desired object.
Object Browser said,“You will get both Object Mapping and Name Mapping speaking to each other and the entire town will be in harmony” and the townspeople were in awe and elected him mayor.
So far so good.....The story had happy ending with election of Object browser as mayor.
But in some paralal univers some forks were ignorance to choose Object Mapping or Name Mapping.
Which have filled their testing kingdom with darkness course by curse of "Object Not Found ............"
They had to toil lot manullay changing mappings and re mapping things.
According to legends they belive that some day a bear (of course a smart one) would come and teach a magic of how to clean up the mapping mess they have created.
Good story... 🙂
...And it absolutely corresponds to what was said here several times - when you start tests automation for some program, spend some time to investigate the structure of its UI structure and think what elements of it will be most useful and handy for you. Then map those elements manually and put them in the Aliases tree so that Aliases provides you with the most simple, handy and reliable structure. It is not necessary to put everything in the Aliases tree. Put there only stable elements that give you access to the root functional (logical) areas of the tested application. And then make a decision what is better for you for the given application - either to map the child elements as well or not to map them and search for them using FindXXX() methods with the mapped objects used as a root for the search.
Othrwise, how on Earth the one might expect that the automatic NameMapping can make a decision of what and how should be mapped for your best convenience?
And finally - Tests automation is a development project within another development project. And like with any project (*any*, not necessarily the development one), if you spend some time for planning and design before you start to dig a pit or turn the screws, the chances are higher that you will be able to do your work more easily, faster (in the long-term run), reliably and without the necessity to redo what has already been done...
...and until the day the Great Wise Bear cometh, there shall be much strife and needless suffering caused by the Golem of Mapping. Hence, unto the wisest, I embolden you to admonish the seduction of Mapping but for a few Aliases, and steadfastly secure your place in the Code Writing Kingdom, where you shall learn to ascertain objects of all forms dynamically by finding children into the specific depths of the DOM, with the wisdom of the Great OB [Object Browser], and to even locate the elusive native web objects [NWO] in dire situations; Thus, taking firm control of your automation destiny my friend.
[translation: Imo, I'd suggest to limit most forms of mapping at all, and do it all in code (except for a single top-level "browser" alias for multi-browser-compatibility, and maybe some key levels as the very eminent AlexKaras indicated in his post; but personally, I don't even bother with those because 1 line of code finds them easily). Write some wrapper functions to eliminate redundancy, which would include logging, object finding (.FindChild, etc.), scrollIntoView (for browsers), clicks (as a parameter), performance counters, checkpoints, etc... It all works without mapping, and it's lots of fun when you're in control of it.]