Efficient Search for Children

[timostark]

Hi,

Comment from #7

So you could simply get the table and assert the rows or get the rows and assert their count, etc. The aggregation matchers are an artefact from the past of OPA, before having the synchronisation (autoWait: true) and we keep them for backward compatibility

Unfortunatly I found no clear example (ancestor: locators.md for "getting the rows and assert their count".

Therefore to be sure - Would the following code be, what you expect for matching count of Rows within the categoryList of ui5 demo?

        expect(
            element(by.control({ id: /homeView--categoryList$/, interaction: "root" }))
                .all(by.control({ controlType: "sap.m.StandardListItem" })).count()).toBe(16);

If yes, i can also raise a pull request, for an extended example of ancestor matching.

Thanks for confirming, Regards, Timo

[maximnaidenov]

Hi Timo,

exactly. I would find the table by ID and then find its items with controlType. You don't need this interaction type, it is used only when resolving the DOM for the click/enterText

Maxim

[maximnaidenov]

BTW: I would use PageObjects, we support at least 3 patterns. Otherwise you will end up with lot of repetitive selectors.

[timostark]

Hi Maxim,

Yap - Certainly Page-Objects are much better. Regarding "interaction", you can have a look on #9 . Without the interaction type on "auto", i will get:

INFO: Expectation FAILED: Failed: unknown error: Control Element sap.m.List#container-cart---homeView--categoryList has no dom representation idSuffix was triggerError: Control Element sap.m.List#container-cart---homeView--categoryList has no dom representation idSuffix was trigger

Reason for that is mentioned in the closed issue (i closed, as that is mentioned in locators.md).

Regards, Timo

PS: Thanks for confirming!

[maximnaidenov]

Hi Timo,

the requirement of interaction type to suppress an exception is definitely a bug, after checking our backlog I see we already identified the rootcause some time ago and will work on fixing it.

Maxim

[timostark]

Hi Maxim,

Thanks - Last question: I assume the fix will be applied to OpenUI5 itself. Will such a fix be downported up to 1.52 (as supported version mentioned here: https://github.com/SAP/ui5-uiveri5/blob/master/docs/usage/locators.md ) - or will only the latest nightly builds get such a fix?

Thanks, Timo

[maximnaidenov]

Hi Timo,

Depending where the fix will be necessary, we will either submit in uiveri5 itself or openui5. If in openui5, we could downport mostly to latest LSTs which is 1.58 currently.

Regards, Maxim

[timostark]

Ok thanks for the feedback. That more or less confirms, that also the "code-to-be-tested" should be very new (ok for me).

Thanks, Timo