Changing versions of software breaks name mapping

I'm OK with helper functions such as those outlined by cunderw. I use them myself - alongside mapping. My caveat for those though is beware of the performance hit they can come with.

If you start every search at a very high level of an application, and the application has a busy object model, things can get very slow as it has to search for every object it needs before it can use it.

Not a "don't do it", more of a "beware".

Also, depending how you set these up, if you have reference calls to them all over your scripts, and something gets updated, I can see the situation arising where you're left raking through huge piles of script units looking for calls to helper functions to update the search parameters you're sending them.

Neither way is perfect. They both have their pro's and con's (hence why I use both). But both require a little forethought and planning to make them last well in the long term.

Anything mapped using a property that contains some sort of version number as an identifier has no chance.

Reliable long term name maps, in my experience, require a bit of donkey work up front. Choose rock solid, reliable properties. If you can, make sure your dev team know that you're using these properties. A helpful dev team will give you properties which work well with automated tests.

But I map everything manually and am very selective of the properties I use.

Making good use of the Alias map can make maintaining the integration of mapped objects into scripts much, MUCH, easier as well.

I have lost track of how many times I've said it on here but ......

If you are using Aliases which are a straight copy of a mapped object, complete with big horrible long name as captured by the system ..... YOU'RE DOING IT WRONG!!!!

The Alias objects should be shortened, human readable, and have a MUCH more direct mapping to how THE USER sees the application.

Systems need lots of invisible layers to build themselves. Users don't know, or care, about most of these invisible layers. You Alias map should reflect that.

eg.

screenCFS1911.frame-x371bv4.panelz51a.container1.container2.buttonbar.containerb1z3922yy.button1xSV

... is NOT a good alias.

CustomerPage.ButtonBar.Save

... IS a good alias.

Which also has the advantage that if container layers change (as they often do) but the logical layout of a screen does not (at least, as far as the end user is concerned) then you fix the object map. Make sure the Alias is still tied to the fixed object, and you scripts don't need any updating.

ie. Aim to only have to update the low level (object) map. Not the high level (alias) one. Obviously, it's impossible to guarantee you'll never have to update both. But a little careful planning and prep keeps it to a minimum.

.

Some of the parent windows would use the WndCaption property for mapping, and that property had the version number of the software. Now when I update the software, and run an automated keyword test it goes out and looks for that object with the WndCaption of Version XYZ. Since they no longer match the test fails stating the object does not exist. I was having to go in and remove that property, and since I was already putting my hands on it I was renaming everything so that it was more to clear to me what that object was. After performing this task on all my name mapping I was rerunning the tests with different version numbers, and thus far it's been executing the tests without any errors.

.