Namemapping with extended find - invisible Alias?

Kresten,



Could you please explain:

"...move the mapped object to a grandparent
object..."

My understanding you are changing the map how object is searched.

Ability to change relationships in NameMapping (not Alias tree), I used only for cases when actually UI is slightly changed, like:

- added/remove panel in the middle

- middle objects reorganized.

That is why you can get lost of object identification.





"Another
thing that confuses me is that you cannot click on a mapped object and
'Show Alias'. you can only go from the Alias and 'Show Mapped object'."

I think this was done due to several reasons.

The biggest one is that to one NameMapping object you can have several Aliases. And this case would require to ask user witch particular Alias he would like to see.

I agree that this would be useful.

The first what I miss is the highlighting of mapped object:

- green - has alias or aliases

- blue - does not have aliases

As I understand it, Extended Find is a run-time, dynamic find of the object.  So, you might not see it as an Alias in the object spy because that particular code is not being executed.  This is information simply from observation, not necessarily from actual fact.  I leave that up to the SmartBear folks to answer.

Hi Robert,



Thanks for your input. Even if TestComplete needs to search for the object I would still expect a 'link' between the mapped object and the Alias.



Another thing that confuses me is that you cannot click on a mapped object and 'Show Alias'. you can only go from the Alias and 'Show Mapped object'.



Regards

Kresten

Hi Margaret,



If I enable 'extended find' and move the mapped object to a grandparent object I am not seeing what you see. Please see my attached image (TC_Aliases.png), marked with red arrows.

I tried on the calc.exe application.

I agree with Dmytro.

If you change manually the hierarchy of mapped object by drag and dropping them to their grand parents, that will not work.

According to support page, you have to enable Extended find on a child, and delete his parent. When confirmation dialog popup, simply click no to keep children object mapped.



The thing is, even if you follow instruction of the support page http://support.smartbear.com/viewarticle/12466/, you may have others difficulties using them as I wrote earlier http://community.smartbear.com/forum/post/?mode=singleThread&thread=75c33127-e966-4d05-8088-8178db103112



Regards.

Hi all,



Thanks for the input. I have tried to clarify what I want to do and my problem.

I have an application under development where the GUI elements move around from build to build. I want to create a namemapping that will allow me to run tests without having to do a new namemapping with each new build.



My solution to this is to move my mapped objects up in the hiarchy to a point where there are no changes from build to build, i.e. a 'stable grand parent'. This works fine when I use the 'extended find' option. I am able to highlight the GUI element from both the Aliases panel and the Mapped Objects panel. Also when running a script I can access the GUI element by using the Alias. However the Object Spy will no longer show the Alias name for the GUI element. This is my problem.







To illustrate the problem, try to follow these steps:

1. Create a new Suite

2. Create a new project

3. Record the following script (I use VB. and have set auto namemapping on)

4. Start Calc.exe

5. Click "4" button

6. Stop recording

7. You should now see the same as the included project "CalcNameMapping.zip"

8. Also please see 'TCalias_01_BeforeMoving.png'

9. For the 'btn' object in the namemapping, enable Extended find

10. In the 'Mapped Objects', move the 'btn' object to sit under the 'wndCalculator' object

11. Please see 'TCalias_02_AfterMoving.png'

Kresten,



Now I see what you mean. :-)

It looks this is feature according to following answer:



Old SQAForums thread by Allen_AQA :

"In this case,
the behavior is expected as getting mapped names for objects retrieved
via the Extended Find feature can lower your test's performance
significantly due to complex tree processing. So, the MappedName
property is not available to objects that can be found using the
Extended Find feature, and the behavior is unlikely to change in the
future."



From my own, I would NOT suggest to use Extended Find widely. Only if object is really "jumping" on hierarchy in one run, not from build to build.

Being on you place I'd try to use Aliases structure for your tests and try to keep NameMapping organized.

Especially imagining what Extended Find means internally and what impact it can have on performance for object recognition during run.

Hi Dmytro,



Ok so this seems to be a design decision from SmartBear.

I see their point of view but it also means that, when going through the AUT, you cannot see if an object has an Alias or not :-(



I agree with you that you should avoid the extended find if possible. Here is my problem: we would like to run a smoke test on a new build of our AUT without having to spend time on correcting the namemapping. We wish to run the smoketest as part of our Continuous Integration cycle so we need a procedure that is lightweight, dynamic and fast --> having to manually update the namemapping does not seem to fit this :-)



Any suggestions you may have are very welcome as I don't quite know how to overcome this.

P.s. I should mention that we have unique UIDs on all objects. I was thinking about making a script that would search the AUT for these UIDs and then try to link the Alias with this UID but it seems I would be making the namemapping functionality all over again - something I would rather not get into :-)



Thanks for your input!

Regards

Kresten