Webdriverio : touch events#4446
Conversation
…port native touches
…lbar-color-swatches
…lbar-color-swatches
|
|
||
| await browser.execute(() => { | ||
| const active = document.activeElement | ||
| if (active instanceof HTMLElement) active.blur() |
There was a problem hiding this comment.
What happens on a physical iPhone when the keyboard is closed by tapping Done? Is document.activeElement already cleared?
We want to make sure our tests don't deviate from actual behavior.
There was a problem hiding this comment.
What do you mean when you say we don't want tests to deviate from actual behavior in this case?
There was a problem hiding this comment.
I mean that we don't want integration tests to do anything that the user can't do with their device. The user closes the keyboard by tapping the Done button and they don't have access to blur(). So why is the test doing something "special" that the user can't do?
We don't want to give integration tests special powers. Then we end up having test coverage of those special powers instead of test coverage over the actual behavior that the user is capable of.
|
|
| await tapElementBySelector('[data-testid="toolbar-icon"][aria-label="Text Color"]') | ||
| await tapElementBySelector('[aria-label="background color swatches"] [aria-label="red"]') | ||
| await tapElementBySelector('[aria-label="text color swatches"] [aria-label="red"]') | ||
| await tap('[data-testid="toolbar-icon"][aria-label="Text Color"]', { horizontalTapLine: 'center' }) |
There was a problem hiding this comment.
Why doesn't the default horizontalTapLine work?
Color tests should not have to worry about where to tap the button.
There was a problem hiding this comment.
The default value for horizontalTapLine is left. However, for toolbar icon buttons, calculating the tap coordinates from the left edge does not consistently target the button accurately. To address this, the center option was introduced, which calculates the tap coordinates at the horizontal center of the button, resulting in more reliable and accurate tap interactions.
Color tests should not have to worry about where to tap the button.
You're right about this part. I was thinking if we want to keep this functionality within tap, we could introduce a new option that indicates the target is a toolbar icon, allowing the tap coordinates to be calculated accordingly.
There was a problem hiding this comment.
What about making center the global default? This more closely matches user semantics. If you tell a user to tap on a button, they're more likely to tap somewhere near the center than tap the exact edge.
The question is whether that will break other tests. If other tests depend on the tap occurring on the left edge (for example to set the cursor at the beginning of the thought), then arguably those tests should make that dependency explicit by specifying horizontalTapLine.
Please try to avoid phrases like "reliable" or "accurate" without going into the details. We're dealing with exact pixels. The button is rendered in the same place every time. You should understand exactly why left edge tap breaks on toolbar buttons. Only then can we determine the best solution. If we lack understanding, then our solution may be based on false assumptions and we may fail to apply the lesson properly in future scenarios.
I was thinking if we want to keep this functionality within
tap, we could introduce a new option that indicates the target is a toolbar icon, allowing the tap coordinates to be calculated accordingly.
tap is a general function. General functions should not be concerned with specific usage. Your gut feeling should tell you that parameterizing general functions with context-dependent behavior is a bad idea. At least horizontalTapLine is general.
|
@karunkop Is this ready for review or are you still working on it? Thanks! |
2 participants
Close #4251
Implementations as per discussion in