-
Notifications
You must be signed in to change notification settings - Fork 141
Webdriverio : touch events #4446
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
base: main
Are you sure you want to change the base?
Changes from 6 commits
bdd762d
39211af
c1ee833
58e7060
cc699e9
fa959ef
0c95a27
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| import $ from '../helpers/$' | ||
| import getEditingText from '../helpers/getEditingText' | ||
| import paste from '../helpers/paste' | ||
| import tap from '../helpers/tap' | ||
|
|
||
| /** Retrieve the innerHTML of the first note on the page. Assumes that there will be only a single note. */ | ||
| const getFirstNoteText = async () => (await $('[aria-label="note-editable"]')).getHTML({ includeSelectorTag: false }) | ||
|
|
||
| it('Can change the background color of a thought that already has the same background color applied to part of its text, then change the text color', async () => { | ||
| const content = '- some <font color="#000000" style="background-color: rgb(255, 87, 61);">formatted</font> text' | ||
| await paste(content) | ||
|
|
||
| await tap('[data-testid="toolbar-icon"][aria-label="Text Color"]', { horizontalTapLine: 'center' }) | ||
| await tap('[aria-label="background color swatches"] [aria-label="red"]', { horizontalTapLine: 'center' }) | ||
| await tap('[aria-label="text color swatches"] [aria-label="red"]', { horizontalTapLine: 'center' }) | ||
|
|
||
| const thought = await getEditingText() | ||
| expect(thought).toBe('<font color="#ff573d">some formatted text</font>') | ||
| }) | ||
|
|
||
| it('Can change the background color of a note that already has the same background color applied to part of its text, then change the text color', async () => { | ||
| await paste( | ||
| ` | ||
| - a | ||
| - =note | ||
| - Multi-word <font color="#000000" style="background-color: rgb(255, 87, 61);">note</font> | ||
| `, | ||
| ) | ||
|
|
||
| await tap('[data-testid="toolbar-icon"][aria-label="Note"]', { horizontalTapLine: 'center' }) | ||
|
|
||
| await tap('[data-testid="toolbar-icon"][aria-label="Text Color"]', { horizontalTapLine: 'center' }) | ||
| await tap('[aria-label="background color swatches"] [aria-label="red"]', { horizontalTapLine: 'center' }) | ||
| await tap('[aria-label="text color swatches"] [aria-label="red"]', { horizontalTapLine: 'center' }) | ||
|
|
||
| const result = await getFirstNoteText() | ||
| expect(result).toBe('<font color="#ff573d">Multi-word note</font>') | ||
| }) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,14 +1,20 @@ | ||
| /** | ||
| * Hide iOS keyboard by tapping done button above the keyboard. | ||
| * Uses the global browser object from WDIO. | ||
| */ | ||
| /** Dismisses the iOS keyboard via Safari's native "Done" button and blurs the active element to ensure subsequent taps trigger a fresh focus event. */ | ||
| const hideKeyboardByTappingDone = async () => { | ||
| const oldContext = ((await browser.getContext()) as string) || 'NATIVE_APP' | ||
| await browser.switchContext('NATIVE_APP') | ||
| const done = await browser.$('//XCUIElementTypeButton[@name="Done"]').getElement() | ||
| await done.click() | ||
| await done.waitForExist({ reverse: true }) | ||
| await browser.switchContext(oldContext) | ||
|
|
||
| await browser.execute(() => { | ||
| const active = document.activeElement | ||
| if (active instanceof HTMLElement) active.blur() | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What happens on a physical iPhone when the keyboard is closed by tapping Done? Is We want to make sure our tests don't deviate from actual behavior.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do you mean when you say we don't want tests to deviate from actual behavior in this case?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 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. |
||
|
|
||
| return new Promise<void>(resolve => { | ||
| requestAnimationFrame(() => requestAnimationFrame(() => resolve())) | ||
| }) | ||
| }) | ||
| } | ||
|
|
||
| export default hideKeyboardByTappingDone | ||
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default value for
horizontalTapLineisleft. However, for toolbar icon buttons, calculating the tap coordinates from the left edge does not consistently target the button accurately. To address this, thecenteroption was introduced, which calculates the tap coordinates at the horizontal center of the button, resulting in more reliable and accurate tap interactions.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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about making
centerthe 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.
tapis 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 leasthorizontalTapLineis general.