Forum Discussion
AngularJS web apps should be easily testable via TestComplete. You shouldn't have to do anything fancy.
When you use the Object Spy to examine one of your elements, do you have something that indicates Object Type and/or ObjectIdentifier? Also, if you expand the property list to include the Advanced list (should be a link at the top), there are probably a lot of other identifying factors like caption, text, innerText, contentText, etc., that you can use as identifying factors as well.
Throw up a screenshot of one of your components and the Object Spy properties and we should be able to help with something.
tristaanogre:
The problem (as described by @Lagencie and according to what I saw once or twice) is that Angular-based pages do not provide web elements with any id/stable class/etc.
The page I saw (and that I believe was Angular-based) was an absolute horror: all elements were named in the Object Browser by indexes only.
Your best option is to try your best and provide stable identifiers (id/class name/whatever else) at least to some subset of core elements on the page to be able to use these element as a search roots.
I believe you understand it clearly and will let everyone know that even if it is possible to create NameMapping using XPath (or implement a set of 'locator' functions), this approach will be highly unstable and expensive in support.
The reason is that XPath like 'second text field within first panel within first div' :
a) Will break immediately when the page design changes;
b) Is absolutely not descriptive. As soon as the page design changes and XPath breaks, it is near to impossible to say what exact object it was expected to work with. In almost all cases you will have to get a previous working copy of the page, find the target element, find this element on the new version of the page and correct XPath to match new page design.
Summarizing: While technically TestComplete has no problems to work with such web page(s), you should triple-consider if identifiers can be added to page elements and whether it is reasonable to start automation of such page(s) at all in case identifiers cannot be provided.
Note: obviously this is not a problem of TestComplete, one will have absolutely the same reliability and support prolems with any other automation tool.
- tristaanogre8 years agoEsteemed Contributor
Egads, really? That's horrible.
- Lagencie8 years agoFrequent Contributor
Sadly yes ... There are a lot of "object identifiers" but none of these work to match an element longterm ... as these object ids are generated by the page during runtime - meaning if an elements loads faster / slower it gets the id first.
As it is a rather static page with no or close to no changes I would have chosen to do it with xpath as this doesnt change - But i dont want to script it, as we wouldnt use testcomplete if we had to use scripts anyway, because we have a fully working C# Selenium Testsuite for these purposes...
- AlexKaras8 years agoChampion Level 3
Hi,
> [...] it is a rather static page [...]
Well, as you are aware about the possible problems...:)
Back to your initial question: no, it is not possible in TestComplete use pure XPath to define elements within NameMapping tree. But you can easily effectively emulate it.
For example, let you like to namemap a text box with index 0 that is a child of div(0) with @class='aaa' that in its turn is a child of another div(0). I.e. XPath is like \div[0]\div[@class = 'aaa']\
You can do an initial NameMapping from Object Browser or Object Spy, switch then to the NameMapping editor and check/specify the following identification criteria for the elements:
-- For the first-level div: ObjectType = panel and ObjectIdentifier = 0;
-- For the second-level div: ObjectType = panel and ObjectIdentifier = 0 and ClassName = aaa;
-- For the text box: ObjectType = TextBox.
Note, that it is recommended to use (wrapping) properties provided by TestComplete wherever possible instead of the native ones provided by the browser. The reason is that properties provided by TestComplete ensure cross-browser support while native properties do not. For example, TestComplete-provided property contentText may correspond to either contentText or textContent native property depending on the browser.
You may make use of the Extended Find namemapping property if you like to emulate the XPath that searches down the tree (but remember that this increases search result uncertainty and search time depending on how deep you are searching).
https://support.smartbear.com/testcomplete/docs/testing-with/object-identification/name-mapping/index.html help section should provide you with more details.
And the last but not the least: https://support.smartbear.com/screencasts/testcomplete/reliable-tests-for-dynamic-objects/ recording from the https://support.smartbear.com/screencasts/testcomplete/ page might appear to be useful.
Related Content
- 3 years agoLuukdb
- 3 years agoEgg
- 3 years agoenriquebravo
Recent Discussions
- 6 hours agodhundley