Forum Discussion

Novari-QA's avatar
Novari-QA
Frequent Contributor
7 years ago

NameMapping inconsistant method of finding objects on screen

When name mapping my radio buttons I found out something very strange.

I would name map Radio Button #1 with no problem. The software states that I also have to map its parent panel. No problem. However, Radio Button #2 and #3 both require to name map the parent.parent.parent.parent.parent. etc etc etc etc. 

Why is it that one object on the screen in the exact same location on the DOM tree requires less mapped objects while the other radio buttons require a ridiculously long list of parent objects? I dont care about 90% of the objects it is trying to map, how can I avoid this.

 

 

 

4 Replies

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    It all depends on what you already have mapped versus whether or not it had extended find turned on, etc.

    Basically, what you're seeing for Radio #2 and #3 is the way it should work when you initially map something... without seeing, all I can do is guess but I'm expecting that Radio #1 is being mapped as a child of an object with the Extended Find flag set.  

     

    Mapping multiple parents is actually what I've found to be best practice.  It's the Aliases where you can "telescope" things to be more manageable.  To avoid this inconsistency, in the future, make sure that the "Use extended find when possible" under Tools | Options | Engines | NameMapping is unselected when you start mapping a new application.

  • NisHera's avatar
    NisHera
    Valued Contributor

    Also to add tristaanogre to do a good stable mapping you better have awareness of particulate object have organized.

    in your case it could be Radio btn # 1 's parents parent have already mapped and # 2 and #3 is not inherited these mapped object.

    Try to find the common parent of #1,#2 and #3 then think of how would be the best way to to map.

     

    Also in your shared picture you don't have to map all the intermediate parents. you can skip most of them if you feel no need. 

    • Novari-QA's avatar
      Novari-QA
      Frequent Contributor

      Id love to skip them, but it won't let me

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor

        You won't be able to skip them in the initial mapping... and I honestly think that, unless you have good reason to do so, you shouldn't "collapse" them using Extended Find if you don't need to. When you get to editing the Aliases, then, you can "collapse" the tree of parent objects there without losing the mapping themselves.

         

        Use the same care in mapping the parent objects as you do in mapping the child objects as TestComplete's engine for NameMapping still needs to be able to accurately and reliably identify the parent objects as well.