NameMapping vs Objects Defined In Code
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,...
Forum Discussion
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.
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?
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...
m_essaid wrote:
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...
Not to mention being able to define an object based upon property values that are wild-carded or even stored within project level variables.
Additionally, ESPECIALLY with web pages, NameMapping is a LOT easier to specify which of the 40-11 zillion links on the web page are the link you REALLY want to click simply by identifying it based upon a reliable set of properties. Doing it in code is possible with things like Find, FindChild, FindAllChildren, etc., but programmatically creating the two arrays of properties and property values and then making sure that, yes, the one you found IS the one you want and is not on the wrong level of the object, etc... Meanwhile, I know EXACTLY what object Aliases.MyApp.MyForm.Button4 is EVERY time.
ryan_perneel wrote:
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?
True... but that function would need to be in a unit that you would need to add to a USEUNIT clause on EVERY code unit that you want to include it in... meanwhile, NameMapping/Aliases is already available.
Basically, by doing what you're doing, you're "reinventing the wheel". It is what I used to do in AQTest 1.51 (before it became TestComplete 2) before they implemented NameMapping. If you have legacy code that is using programmatic expressions for mapping objects, obviously there is an overhead involved in conversion... but it's worth it, really. Less overall maintenance (Did I remember to add the function to the USEUNIT clause?, etc) and a much higher integrated functionality.
You already noted the performance factor. The more code you need to process through, the more units that need to call back, the more of a performance hit. NameMapping is natively built into the automation engine so there's no need to engage the scripting engine of your code base (JavaScript, JScript, VBScript, etc) to do the processing.
Overall, I'm with Colin_McCrae... there is a distinct advantage of using NameMapping for the static objects in your AUT and then using "helper functions" to find the more dynamic ones (like cells in a grid, dynamically generated links on a page, etc).
