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
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.My main problem with this is sharing framework code across 100s of projects. If something requires a change to name mapping and it is used by a share utility all projects name mappings must be updated at that point.
If you have a single or a mall number of projects and are not sharing a lot of utilities with a larger team, namemapping is fantastic.
Once you start using utilities across A LOT of projects it becomes impossible to maintain name mapping for all of them. I know there is the merge option, but that hardly ever works without conflict, and TC doesn't not prompt to accept or deny conflicts or even specify which part of the map had issues.
It also is (in my experience) unreliable when testing responsive sites where the layout of the page might change depending on browser size.
cunderw wrote:
My main problem with this is sharing framework code across 100s of projects. If something requires a change to name mapping and it is used by a share utility all projects name mappings must be updated at that point.
If you have a single or a mall number of projects and are not sharing a lot of utilities with a larger team, namemapping is fantastic.
Once you start using utilities across A LOT of projects it becomes impossible to maintain name mapping for all of them. I know there is the merge option, but that hardly ever works without conflict, and TC doesn't not prompt to accept or deny conflicts or even specify which part of the map had issues.
It also is (in my experience) unreliable when testing responsive sites where the layout of the page might change depending on browser size.
That's why I don't include object designations themselves in the framework. Any methods, functions, etc., in the framework that need to access a UI object take that object as a parameter passed in from the test data. That allows the framework to be application agnostic and usable across multiple platforms. Or, as in the simple framework that I have published, the classes that perform the actions are specific to the project and not to the framework.
As for responsive sites and browser size... that comes down to standardizing test environments. Make sure you develop your tests with a particular resolution and browser window size that you can then replicate across your testing environments. If you need to test with different browser size and resolutions, again, control those within your tests within the parameters of your known testing environments.
