I have been trying to automate our MS Dynamics 2016 application with TestComplete for a few months and keep running into issues with object identification. I reviewed this thread and it is suggested that Microsoft UI Automation be used to help with identifying objects: https://community.smartbear.com/t5/TestComplete-General-Discussions/Microsoft-Dynamics-Name-Mapping-...
However, our CRM application is a web application. We only have a license for Web Testing because we only develop web applications at my company but it seems like the UI Automation functionality is only available through the Desktop Module according to this article: https://support.smartbear.com/testcomplete/docs/testing-with/object-identification/improving/using-u.... We looked into getting a Desktop license and it looks like we need an exe to drop into TestComplete to map the objects but like I said above, our MS CRM system is a web application so no exe exists. Can anyone shed any light on how to make object identification work smoother for MS CRM in TestComplete?
Current behavior we are seeing is significant delays in object recognition (2-3 minutes per step) which is making it basically unusable. I have tried mapping additional parent objects to improve the object recognition performance but I haven't seen a significant improvement after doing so. Any help would be appreciated!
Here are some screenshots of the Keyword Test in question and the name mapping/object browser for the test. I am having issues starting on the textboxFirstnameI field and it continues for the remainder of the test.
I see Extended Find selected for many of your objects. That can certainly add to the search time. This link can help you reduce some of that:
Thanks for the reply! I tried different variations with having all of the textbox objects Extended Find unchecked and leaving everything else checked, leaving textbox objects Extended Find checked and the parent levels unchecked and it seems to get worse if I turn Extended Find off for any of the objects. I have also tried this from the link that you sent without seeing a performance improvement:
Searching for objects in large applications may take a long time. If you get warnings in the test log that a search takes too much time, try doing the following:
Add more objects to the object’s parent hierarchy in the Mapped Objects tree to narrow the search. For instructions, see About the 'Search for a Mapped Object Took Too Much Time' Warning.
Have you tried contacting Support? You can use this link:
Simply turning off extended find does not resolve performance issues... in fact, it could make things worse in your automation. Extended Find "compresses" the mapping tree by telling the NameMapping engine to search the entire tree of descendants for the object that matches the properties. So, if you want to turn off extended find, you need to more fully map your objects.
For example, say in the Object Browser, you see the following:
And you tell TestComplete to map the TextNode. If TC is configured to use extended find whenever possible, you may see in your NameMapping the following
The TextNode will have the Extended Find flag checked. If you want to uncheck it, you will need to manually add mapping for the three panels that were skipped. That's what that article means when it talks about mapping additional parent objects.
I think we should use Extended find only if one or more of the parent components in the object hierarchy cannot be identified uniquely(For EG : Property values get changed dynamically). In this case we will identify a parent object that can be identified uniquely and will enable Extended Find for the child object we are trying to map and child will be dragged and placed under the parent control that can be identified uniquely. But this have the following short falls : It will search all the child controls under the parent control that can be uniquely identified for a match which will be indeed time consuming. Also this approach will have an issue if we have more than one control matching the property value selected for the child control even at a different object hierarchy