Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Binding-Context / Object Access #25

Closed
timostark opened this issue Feb 28, 2019 · 7 comments
Closed

Binding-Context / Object Access #25

timostark opened this issue Feb 28, 2019 · 7 comments

Comments

@timostark
Copy link

timostark commented Feb 28, 2019

Hi,

I already asked a similar question in #12 - I am not 100% sure though if i got you correctly here.
Example: I want to select Order Id 7991 in your demo-application browse-orders ( https://openui5.hana.ondemand.com/test-resources/sap/m/demokit/orderbrowser/webapp/test/mockServer.html ).

image

The order ID however is not available as "clean-technical-identifier". I can only ask for the Property title ("Order 7991"), which might be language dependent. If I check the binding context of this object, i see that the information I want, is perfectly available.
image

So I would expect a matcher:
BindingContext: { model: undefined, path: 'OrderID', value: 7991}

Unfortunatly the documentation of openui5 does not seem to provide such a matcher.
So the question: Where am I missing something here in that use case? Or are you "accepting" tests to be based on language dependent texts?

Regards,
Timo

@vobu
Copy link
Contributor

vobu commented Feb 28, 2019

hi,
sounds as if

element(by.control({
  viewName: "myViewName",
  controlType: "sap.m.StandardListItem",
  bindingPath: {
    path: "/products/7991", 
    propertyPath: "OrderID", 
    modelName: ""
  }
});

is what you‘re looking for (freehand coding of the above, so read with caution :)
hth, v.

@maximnaidenov
Copy link
Contributor

We recently added an example in OPA docs: https://openui5nightly.hana.ondemand.com/#/topic/21aeff6928f84d179a47470123afee59.html
Everything applied equally to uiveri5 of course.

@timostark
Copy link
Author

Hi Volker, Maxim,

OK - I've chosen a bad example again :-) Yes - in this case the absolute binding path would be perfect, as I am searching for the primary key. You are right. Thanks for this.

Still it is not 100% the flexibility I'd hoped for. As a more general requirement, I'd like to have full access to the model-object behind the binding path. So another example (for the same URL) - I have a complex search, and if I am searching for a specific "value" i am only expecting results with "ShipVia": 6419 - even though there is no single visible control on the screen, which is showing the Ship-Via.

image

In such a case I really do not see a way to use that binding path, right?

Thanks again,
Timo

@maximnaidenov
Copy link
Contributor

Hi Timo,
uiveri5 and OPA are intended to simulate user interactions. And because the user can't interact with invisible controls, you are not supposed to locate such. In OPA, due to historical reasons, you can avoid this limitation by adding visible: false in the selector but we do not support this in uiveri5 very intentionally. As for exposing "model object", this is not practical in uiveri5 as the locators are executed in UI5 runtime, not in test(nodejs) environment.
By the way, the BindingPath matcher is very powerful, we are not aware of a single practical use case that is not supported. If you ever met such, please share it so we could possibly plan and extend the binding path matcher.

@timostark
Copy link
Author

timostark commented Feb 28, 2019

Ok - perfect. That is an answer i can totally agree with.

One last question: You are using the MatcherFactory internally ( https://github.com/SAP/openui5/blob/2fc8e8ebc9ee447c5976062f59e243d193484b0d/src/sap.ui.core/src/sap/ui/test/matchers/ ).

Unfortunately this one is hardcoding the supported matchers.
image

Theoretically it is possible to create custom matchers (inherting from sap.ui.test.matchers.Matcher - we did that a few times in former projects ).
They will not get recognized by uiveri5 due to that hardcoding.
Do you have any plans of opening this stuff up?

Thanks,
Timo

@maximnaidenov
Copy link
Contributor

Hi Timo,
if there is interest and realistic use case, we could work on support for custom matchers.

timostark pushed a commit to timostark/ui5TestAutomation that referenced this issue Feb 28, 2019
@timostark
Copy link
Author

Ok Great :-) I adjusted my test-recorder to comply with the guideline to focus on binding paths (and visible properties). Working pretty well without the need for a custom matcher at the moment.

Thanks again for your help --> closing this issue.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants