-
Notifications
You must be signed in to change notification settings - Fork 8
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
Make Get Element Text match WinAppDriver more closely. #30
Conversation
Some are failing. To test this effectively, list controls really need a selection, so edited the test application to give a default selection.
[Test] | ||
public void GetText_Label_ReturnsRenderedText() | ||
[TestCase("TextBox", "Test TextBox")] | ||
[TestCase("PasswordBox", "●●●●●●●●●●")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This differs from WinAppDriver in that there a ????????
string is returned, however I feel that the existing behavior of returning ●
characters is less ambiguous so I left it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks for the contribution again!
|
||
Assert.That(text, Is.EqualTo("Test TextBox")); | ||
|
||
// Seems that the order in which the selected items are returned is not guaranteed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this is a FlaUI issue to report?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be but given that we're essentially just calling the COM pattern, I suspect it's what WPF is actually returning? WinAppDriver from what I can see though doesn't have this issue, but I'm not sure whether they're normalizing the selection themselves or not. Regardless, didn't feel like a big enough issue for now to spend much time investigating, got quite a few other PRs incoming ;)
https://www.w3.org/TR/webdriver2/#get-element-text says about this:
Because it's implementation-defined, FlaUI.WebDriver's currently behavior is technically correct, however I feel the behavior from WinAppDriver is more useful. This PR tries to emulate that behavior by looking for various implemented patterns and using those to get the text value.
Tested against WinAppDriver's behavior and seems to match so far, with one exception noted in the comments.