We are building a new experience for our SmartBear Community.
This site is now read-only. You can still browse and search as usual. Learn More
This site is now read-only. You can still browse and search as usual. Learn More
zdanov wrote:
I did not modify identification/mapping criteria; just left the defaults as TC captured it during test recording.
Just as a note... while TC does a decent job of automatically mapping items, as you have experienced, it's not perfect. I rarely, if ever, keep the default mapping TC supplies me for the very same reason that you have experienced.
I'm looking at your components and yes, definitely, you need to remap these things.
First of all, in Tools | Options | Engines | NameMapping turn off the option for use extended find when possible. Having this automatically turned on can cause issues in situations like yours where there are a LOT of objects that are very similar with minimal distinguishing characteristics.
Secondly... it's obvious that the controls you're using are in some way custom controls... the fact that you have a dropdown list that TestComplete recognizes simply as a textbox means that this is a bit complicated. You're going to have to do some digging around. one thing I'd STRONGLY recommend is go back to your developers and see if they can help you out by applying unique identifiers to the objects. Textbox(0) and Textbox(6) are very ambiguous.
Unfortunately, this is effort that will take a LOT of work to do via web forums. But your first step is to go back and manually edit all your objects in NameMapping, removing the Extended Find where you can and inserting parent objects, etc. NameMapping uses two sets of criteria for identifying an object. It looks first at the hierarchy... Starting with NameMapping.Sys, it works it's way down the tree of objects to find the specific one. Then it uses the properties to identify specific objects. So, the more specific you can be with hierarchy and the more specific you can be with properties, the less likely you'll have the issues you're experiencing. This will take time, but in the end it's worth it.
My guess is that the problem is due to improperly selected identification criteria for your components. You don't want to "bypass" the member not found... you want to correct your identification so a) you do not get the Ambiguous recognition message and b) don't get the "member not found" exception.
so... each filter needs to be properly identified as a control in NameMapping. The "Ambiguous recognition" means that the identification criteria you've given TestComplete to identify that object actually resulted in TestComplete finding more than one matching object... so, it gives the warning and then attempts to move forward. The "member not found" means that, then, the second control is, for some reason, not found at all. I expect that if you fix the first one with proper identification, the second one will go away as well.
If you need help making these modifications, please post the following:
1) A screenshot showing the Object Browser property listing (all properties, please)for one of the drop down controls that you're having problems with.
2) A screenshot showing the mapping criteria for the object in nameMapping. Please include the hierarchy of objects for the control in question.
With this information, we should be able to give you a general idea of how to fix your problem.
Hi Robert,
Thank you for your reply! :)
I did not modify identification/mapping criteria; just left the defaults as TC captured it during test recording.
Attached are the Object Browser properties (2 screenshots, top and bottom properties) for the drop-down control itself, and then the screenshots (2 screenshots, top and bottom) for the Object Browser properties for the actual list when drop-down is expanded for selecting an item (the one that triggers "member not found" exception).
Also, I have attached the screenshots for the drop-down list that triggers the error from the NameMapping.
Thank you very much!
Regards,
Serge.
zdanov wrote:
I did not modify identification/mapping criteria; just left the defaults as TC captured it during test recording.
Just as a note... while TC does a decent job of automatically mapping items, as you have experienced, it's not perfect. I rarely, if ever, keep the default mapping TC supplies me for the very same reason that you have experienced.
I'm looking at your components and yes, definitely, you need to remap these things.
First of all, in Tools | Options | Engines | NameMapping turn off the option for use extended find when possible. Having this automatically turned on can cause issues in situations like yours where there are a LOT of objects that are very similar with minimal distinguishing characteristics.
Secondly... it's obvious that the controls you're using are in some way custom controls... the fact that you have a dropdown list that TestComplete recognizes simply as a textbox means that this is a bit complicated. You're going to have to do some digging around. one thing I'd STRONGLY recommend is go back to your developers and see if they can help you out by applying unique identifiers to the objects. Textbox(0) and Textbox(6) are very ambiguous.
Unfortunately, this is effort that will take a LOT of work to do via web forums. But your first step is to go back and manually edit all your objects in NameMapping, removing the Extended Find where you can and inserting parent objects, etc. NameMapping uses two sets of criteria for identifying an object. It looks first at the hierarchy... Starting with NameMapping.Sys, it works it's way down the tree of objects to find the specific one. Then it uses the properties to identify specific objects. So, the more specific you can be with hierarchy and the more specific you can be with properties, the less likely you'll have the issues you're experiencing. This will take time, but in the end it's worth it.
Hi Robert,
Thanks for the info. I will try your suggestions and will check with developers if they can optimize these controls a bit, but I think I know what the dev manager's response will be, since our up is full of them and in many, many places... :)
Thanks again for your time and effort!
Regards,
Serge.
> but I think I know what the dev manager's response will be
Then at least *your* manager will be aware why it takes you that much time to create and stabilize tests and why tests' execution is not lightning fast.
While the above might sound rude, I think that it is good to keep management to be informed.
Hi Robert,
While looking through the properties of this control, I see the "FullName" property is probably the only one that has a more "to the point" information that TC could use. However, I see in the documentation for this property the following:
It is not recommended to use the FullName property for name mapping. If you map an object using this property, TestComplete will not use the mapped name when recording scripts. It will use the ordinary (non-mapped) name. Also, using the FullName property may cause performance problems during the recording.
I'm a bit confused here; why would TC not use the mapped name when recording, if you instruct it to map a control with "FullName" property? Wouldn't this property make it a bit more identifiable and unique, since it has the control's lable/name (groupofLoans_list):
Sys.Browser("chrome").Page("http://lpamsqa.lnrproperty.com/Loan/Search").Panel(1).Panel("groupofLoans_list").Panel(3).TextNode(6)
Using Full Name is, really, no different than using the unmapped object. That's all the Full Name is... the name as it shows up, unmapped, in the object browser. This is why it will not use the mapped name for recording and identification... there is no benefit using the full name and the internal code of TestComplete knows it.
What I would recommend is not to focus on finding one singular property for identification but a combination of several. You may need to get fancy... but even more so... your best bet, really, is to get your developers to give you something to work with.