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
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!
