Is there any benefit to using the Namemapping feature in TC as opposed to referencing the object locations in code? Currently, I have functions that will give me certain parts of the application, and if a location changes, i just need to change one function to update the location. We have recently gotten into performance issues when coding tests, and I am concerned that I have too many functions in the codebase for TC to handle. When using the NameMapping, if a root object changes, would you have to goto all the items that reference that root and update them? Thanks.

My preference is to use FindChildEx for a lot of the share utilities and framework. Namemapping is great for individual tests, but if you have to change a share utility that is referencing a mapped object, then all projects namemapping would need to be updated which is unrealistic when you have 100s of projects.

cunderw wrote: My preference is to use FindChildEx for a lot of the share utilities and framework. Namemapping is great for individual tests, but if you have to change a share utility that is referencing a mapped object, then all projects namemapping would need to be updated which is unrealistic when you have 100s of projects. Assuming your framework requires you to have many projects... if your framework is data driven where there is a single project but the tests that are executed are driven by the data, then it's not so bad... you only have the one NameMapping repository and everything uses that. But that's a matter of framework design.

Agreed, definitely depends 100% on how you have your framework set up and the type of application as well. Responsive websites are a PAIN with namemapping. Desktop applications that remain much more static don't cause as much maintenance. Again, personal preference too.

My usual tuppence worth .... I use a combination of both. On both desktop and web applications. I tend to map the larger, more static, parts. And use "helper" functions to find smaller, more dynamic, parts on the fly during a run. I also heavily modify my Alias references to make them much more direct mappings to how a user sees an object within the application when it's running. For me, you need to take care with both ... 1. With name mapping, it HAS to be robust. You need good identification properties. But if you establish those early, and have a nicely named and structured Alias map, I find long-term maintenance is minimal. You need to edit things manually when mapping in most cases in my opinion. The automatic capture carries no guarantee's that it will hold up in any given scenario. That's usually something you can only work out yourself with understanding of how your application is built. Also, having a helpful dev team on hand is a massive benefit. 2. With "helper" functions, I prefer to start the search as close to the target as possible. If you are always searching for things from "Page" level down (in a web app - for example), that can come with a considerable performance hit if it has to search through everything, every time. You also need to make sure you give all your helper functions "escape clauses" (number of attempts and/or a timeout usually). Things getting stuck in endless loops when an object fails to appear/disappear, is not good! The well named Alias map is crucial. As mentioned above, I use a keyword AND data driven framework. So the test guys need to be able to specify the objects they want to work with in the input data. They use locators which translate directly into Alias names. Which wouldn't work if my Alias map was not set up to so closely resemble the front end. In both cases, I find that a little donkey work up front to make the foundations strong, pays dividends in the long run. :) Biggest, most obvious tip? (and my pet bugbear on here) ..... if your Alias map is a straight copy of your name map, complete with big horrible system names, you're doing it wrong!

Hi Ryan, I definitely only use name mapping... Name mapping allows you to factorise every mapped item. For example, if you imagine that there is several types of "buttons" objects. Then you put this mapped name everywhere in your script (say a hundred times). And then the dev team decides to change the button object type. For example, in delphi you could go from a TButton to a TXpBitBtn. You won't have to change the hundred of occurence of this object... no, you just edit the mapped object and change its object type property.

NameMapping vs Objects Defined In Code

16 Replies

cunderw
Community Hero
8 years ago
My preference is to use FindChildEx for a lot of the share utilities and framework. Namemapping is great for individual tests, but if you have to change a share utility that is referencing a mapped object, then all projects namemapping would need to be updated which is unrealistic when you have 100s of projects.
- tristaanogre
  Esteemed Contributor
  8 years ago
  cunderw wrote:
  
  My preference is to use FindChildEx for a lot of the share utilities and framework. Namemapping is great for individual tests, but if you have to change a share utility that is referencing a mapped object, then all projects namemapping would need to be updated which is unrealistic when you have 100s of projects.
  
  Assuming your framework requires you to have many projects... if your framework is data driven where there is a single project but the tests that are executed are driven by the data, then it's not so bad... you only have the one NameMapping repository and everything uses that. But that's a matter of framework design.
  - cunderw
    Community Hero
    8 years ago
    Agreed, definitely depends 100% on how you have your framework set up and the type of application as well. Responsive websites are a PAIN with namemapping. Desktop applications that remain much more static don't cause as much maintenance. Again, personal preference too.
m_essaid
Valued Contributor
8 years ago
Hi Ryan,

I definitely only use name mapping...

Name mapping allows you to factorise every mapped item. For example, if you imagine that there is several types of "buttons" objects.

Then you put this mapped name everywhere in your script (say a hundred times). And then the dev team decides to change the button object type. For example, in delphi you could go from a TButton to a TXpBitBtn.

You won't have to change the hundred of occurence of this object... no, you just edit the mapped object and change its object type property.
- ryan_perneel
  Contributor
  8 years ago
  But you could also have a function that give you the "button". You could then only have to change one reference in code (the button function) and you would be up and running again, right?
  - m_essaid
    Valued Contributor
    8 years ago
    yes, it's correct, but the name mapping manager gives you so much possibilities, such as several properties, conditionnal properties, and all that with a user friendly interface...
tristaanogre
Esteemed Contributor
8 years ago
The beauty about NameMapping is that, if a component changes, you simply edit the identification criteria in your NameMapping repository and all the objects then reference off that. There's no need to update any references to the object.

For example, let's say I have something like Aliases.MyApp.MyForm which has child objects of MyOKButton, MyCancelButton, MyTextEdit, and MyToolBar. Some developer decides to change MyForm to a different class or change the caption or something. My code has 40-11 zillion references to MyForm and various calls to the child objects.

With NameMapping, all I need to do is edit the repository information for MyForm. So long as the child objects are still child objects of MyForm, everything should then just translate. I don't need to make any code changes in any of my tests, I don't need to change any of my references to those child objects, everything just "works".
- ryan_perneel
  Contributor
  8 years ago
  Thanks for the update.
  
  So in code (i have spent all of 30 minutes playing with namemapping) I have references to Alias.MainForm.Grid.Button1. so if Grid, gets changes to something else, say "class1", when I make the change in the namemapping file, then all references in code will autoupdate?
  
  Also, are there perceived performance benefits to changing to namemapping? This is a project that has been around for going on 5 years, and would be alot of work to make the change (though i am tempted to propose a change to using javascript instead of jscript)
  
  Thanks.
  - tristaanogre
    Esteemed Contributor
    8 years ago
    So long as all you do is change the mapping criteria and not the actual name of the alias, then yes, everything should work... it's not a matter of it updating the "code"... just that if your code is referencing Aliases.MainForm.Grid, that will point to whatever you have Grid mapped to, no matter how often you change it. Now, if you change the name from Aliases.MainForm.Grid to Aliases.MainForm.Grid2... then we have a bit of a problem. Keyword tests will automatically update, but script code will not.
    
    I don't know about performance but, honestly, you'll be writing a LOT less code. instead of this:
    
    function test1() { var myButton =Sys.Process('myApp').WinFormsObject('MainForm').WinFormsObject('Grid1').WinFormsObject('Button1'); myButton.Click(); }
    
    All you need is
    
    function test1 () { var myButton = Aliases.MainForm.Grid1.Button1; myButton.Click(); }
    
    Much more readable, really. And you don't have to worry as much about when components change classes, hierarchy, etc... you can "fix" that but just playing with your NameMapping configuration and, if you do it right, you won't need to make any code changes.