Hi,I am new to Testcomplete and having trouble with namemapping. I am using Testcomplete to test a WPF based application. The issue is that UI on the application keeps changing, and each time I have to update the namemapp as well as the tests that use onscreen actions. This is a nightmare as it takes a lot of time, and most of my time is spend on updating namemapping and the tests.1) Namemap is like a tree, so if something is added near the root then I need to remapp all the child nodes even when they did not change. There is no mechanism to copy paste the nodes or to insert a node in between the tree. Is there a workaround or feature to do this easily?2) Also, even after updating the namemapping I need to update the refereneces in the tests and onscreen actions. Is there a better way to do it?Is there a better alternative to namemapping or a better way to handle this scenario?

Forget name mapping and use small scripts that search your entire app for the object you need, sending as parameters the properties they have, for example (this works for me because i'm testing a webapp, but I think it works for anything):function clickObject(propName, propValue,depthOfSearch){ Sys.Process("yourApp").FindChild(propName,propValue,depthOfSearch).click(0,0);}Now you can use this for any action your object supports, use object spy to see all the details about the object you're looking for.This solves your issue because it always finds your object, unless their properties change, wich they shoudn't.Name mapping is only usable if your app will never change, otherwise you need to take a crash course on how to be able to configure it to work with wildcards and stuff....

After spending some time investigating name mapping for testing a rather large and complex web app I ended up taking the same approach as Jose suggests. I wrote a small function that searches the page for an object by its property value and then returns the associated property name. Returning the property name is useful because I call the function in other routines I wrote to perform different actions on the found object. My function for locating objects stores property names in an array. When I find I want to support a new property name I can simply add it to the array. When writing the tests I use object spy to get a supported property value from the object I want to interact with. This lets me write test scripts like this:Call Click("PropertyValue")Call AddText("PropertyValue","some_text")Call KeyPress("PropertyValue","Enter")

If I am understanding you correctly, the development team is making changes to the UI that changes your mapping such that the tests you've written no longer work. I had the same issue and asked dev to find a property on each form that is decriptive in nature and not being used. I had them put a unique 'name' in this property (frmLogin, scrnEntry) and used this plus a FEW other properties that will not change to map the screen. As you have noted the closer the form/screen is to the root of the app, the more critical it is that this property is maintained as poorly executed changes here definitely screw up the mapping.I also asked dev to ensure that if a control on a screen is deleted, replaced, or modified that the unique property carry the same name as the one used for mapping.The company spends good money for TC and your paycheck, dev can help you and the company maximize the return on this money by doing this. Good luck!Jon

+1 both for using small utility functions to search for the objects dynamically and for Name Mapping on unique properties and then searching down the tree rather than mapping every single object in the tree branch (Extended Find option would be your friend here).If you decide to write script functions to find the objects for you, you can always move them out into a Script Extensions Runtime Object, which can make them much like Aliases in TestComplete. I've done this on a few different products to allow sharing the functions between multiple TestComplete Projects.

And finally, don't forget about Extended Find and Required Children functionality in NameMapping that I found working pretty great in a lot of cases since TC 9.x.See TC help for more details, but as a quick example, using Extended Find (and don't forget about Simplified WPF Tree parameter in the project properties) you can name-map your |- region |- wrapper |- button |- wrapper |- wrapper |- name = "Button1"tree as |- region |- button (*) |- name = "Button1" (*)(where (*) indicates items with the enabled Extended Find option. Also button object must have 'name = "Button1" object specified as its required child.). Actually, enabled Extended Find functions pretty like the implicit call to FindChild.With the namemapping from above you may have an Alias like this:Aliases.<appAndParentObjects>.region.buttonwhich can be used in the test code with much more convenience.Hope, the above will help...

Hi, First of all........ what you showed is your Alias, not your mapping. There's a difference. The Alias has no need to be that long. you can collapse a LOT of those "panel" objects down in the Alias while preserving it in your mapping. That way, when you need to what you've currently described, you can move objects around in your mapping and preserve the Alias.Second of all - FindAll/FindChild are good for occasional searches... but they are searches. NameMapping processing has a lot of optimization built into it so the recommended way is to map everything you can and use FindNNNN methods for those things that are variable enough (like tables of data that have variable length, etc) that make it cumbersome to map accurately.

Namemapping nightmare | SmartBear Community

21 Replies

HD
Contributor
11 years ago
Thanks guys for helping me out.

I took Jose's suggestion and now I am using a mixed approach.

1) For features in my application where UI keeps evolving I implemented a script to find UI objects and perform on screen actions.

2) For features that don't change that often, I use Namemapping.

I will gradually replace operations involving namemap with the script.

rgratis

Frequent Contributor

11 years ago

Jose Pita

"R. Gratis

If you decide to write script functions to find the objects for you, you can always move them out into a Script Extensions Runtime Object, which can make them much like Aliases in TestComplete. I've done this on a few different products to allow sharing the functions between multiple TestComplete Projects."

Yesterday I was investigating this option but I found some forum entry saying that you can't debug \ catch errors from Script Extensions. Haven't tried it yet, but I don't think I'm willing to.

I write in VBScript, so I use VBScript's native error handling mechanism to catch exceptions inside the Script Extension code. If an exception makes it through, it pops up an exception window during a TestComplete run. I can get the line number / unit in the Script Extension from the popup text, but that same information doesn't make it into the TestComplete log Call Stack, so if you're trying to fix an issue in an unattended test run that you can't replicate locally, it can be difficult. It certainly makes you write defensive code.

nnguyen_1

Contributor

11 years ago

Thanks guys for helping me out.

I took Jose's suggestion and now I am using a mixed approach.

1) For features in my application where UI keeps evolving I implemented a script to find UI objects and perform on screen actions.

2) For features that don't change that often, I use Namemapping.

I will gradually replace operations involving namemap with the script.

HD: one question.

Did you compare the speed of your automation test after applying "search" at step 1 above against the speed by using name mapping you implemented previously? Does "always search" slow down your test?

joe_2
Contributor
11 years ago
I tried this findchild method as described by Joel and ran into a problem.

Specifically, if something fails, it will fail in the script routine at the line that's supposed to actually click the item.

Clicking on the failure in the test log WITHOUT this script will jump to the line in the keyword test that actually failed.

Clicking on the failure WITH the script just shows you the script line, which is very generic.

The log doesn't tell you what it was trying to click at the time...

It makes the tests a bit easier to write, but a lot harder to debug, as far as I can tell.

How did you all get around that?
AlexKaras
Champion Level 3
11 years ago
Hi Joseph,

Don't double-click on the log record but instead switch to the Call Stack pane of the log (usually it is below main log grid). Double-click on the call stack record will navigate you to the relevant line and this greatly simplifies debugging.
joe_2
Contributor
11 years ago
Ah, I see.

Well, while I was trying to figure out what to do about this, I figured out some stuff about how to create custom messages using event handlers.

I now have messages that read: "Clicked <item identifier> " instead of "The window was clicked with the left mouse button"

And failures that read: "Failed to click <item identifier> " instead of "You tried to click something that doesn't exist."

Should make the failure logs a bit easier to follow, and using the stack to get back to the actual failing line item will make troubleshooting easier.

So... learned two things today, not just one. Thanks.

Forum Discussion

Namemapping nightmare

21 Replies

Related Content

Web testing namemapping

Query Around NameMapping

Project without NameMapping

reload NameMapping

TestComplete NameMapping

Recent Discussions

QWidget_setFixedWidth in TestComplete v15

How to run execution plan Group by using test execute?

Assistance with Fetching Values from Grid Identified by 'AcuGridClass' property

Continue on error

How to adjust sequence of cases run