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

Upgrade user event #4426

Merged
merged 24 commits into from Sep 8, 2023
Merged

Upgrade user event #4426

merged 24 commits into from Sep 8, 2023

Conversation

snowystinger
Copy link
Member

@snowystinger snowystinger commented Apr 22, 2023

Closes

Prep to help us with @LFDanLu's RFC

I've managed to completely replace typeText in our test utils. I think we can also replace triggerPress and instead just rely on userEvent. I think we'll also be able to expand on different kinds of users so that we can export those for people looking to test more than just their mouse workflows.

We'll also be able to finally stop doing the pattern keyDown followed by keyUp, we'll nearly always be able to call the keyboard press and it'll do the cleanup keyUp that we frequently forget.

Tips for after merge:
all user event interactions are now async, so userEvent.click has become await user.click
don’t forget to put async on the surrounding it if it doesn’t already have it

await user.tab implementation details have changed substantially, in general this is a no-op change for us, but some of our tests relied on some of the bugs the previous implementation had, reach out to me if you encounter one of these

await user.keyboard implementation details have changed substantially, the result is we could do away with our util function for typing

if you’ve written a new test file, please see other files for an example of new setup
docs are here https://testing-library.com/docs/user-event/intro/
i suggest reading through all of it, again, things are pretty different
for example user.keyboard does not take an element as it’s target in the first argument, instead it just types on whatever currently has focus, i recommend focusing by using tab or click or something other than focus directly so it’s more of a user-centric test

I also suggest looking through breaking changes from 12 -> 13 and 13 ->14 https://github.com/testing-library/user-event/releases

✅ Pull Request Checklist:

  • Included link to corresponding React Spectrum GitHub Issue.
  • Added/updated unit tests and storybook for this change (for new code or code which already has tests).
  • Filled out test instructions.
  • Updated documentation (if it already exists for this component).
  • Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

Base automatically changed from upgrade-jest to main May 8, 2023 22:35
# Conflicts:
#	package.json
#	packages/@react-aria/color/test/useColorWheel.test.tsx
#	packages/@react-aria/grid/test/useGrid.test.js
#	packages/@react-aria/ssr/test/SSRProvider.test.js
#	packages/@react-spectrum/actiongroup/test/ActionGroup.test.js
#	packages/@react-spectrum/calendar/test/Calendar.test.js
#	packages/@react-spectrum/calendar/test/CalendarBase.test.js
#	packages/@react-spectrum/calendar/test/RangeCalendar.test.js
#	packages/@react-spectrum/card/test/CardView.test.js
#	packages/@react-spectrum/checkbox/package.json
#	packages/@react-spectrum/color/test/ColorField.test.js
#	packages/@react-spectrum/datepicker/test/DatePicker.test.js
#	packages/@react-spectrum/datepicker/test/DateRangePicker.test.js
#	packages/@react-spectrum/datepicker/test/TimeField.test.js
#	packages/@react-spectrum/dialog/test/DialogTrigger.test.js
#	packages/@react-spectrum/menu/test/ActionMenu.test.js
#	packages/@react-spectrum/searchwithin/test/SearchWithin.test.js
#	packages/@react-spectrum/tag/test/TagGroup.test.js
#	packages/@react-spectrum/tooltip/test/TooltipTrigger.test.js
#	packages/@react-stately/utils/test/useControlledState.test.js
#	packages/dev/test-utils/package.json
#	packages/dev/test-utils/src/events.ts
#	packages/react-aria-components/test/ComboBox.test.js
#	packages/react-aria-components/test/GridList.test.js
#	packages/react-aria-components/test/ListBox.test.js
#	packages/react-aria-components/test/Tabs.test.js
#	yarn.lock
let onAction = jest.fn();
let tree = renderSelectionList({onSelectionChange, selectionMode: 'multiple', onAction});
userEvent.click(document.body);
describe('still needs pointer events install', function () {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocks like this aren't quite compatible with new User Events
this may reflect on our code or may be a bug in User Event, until that's resolved though, I've broken down some of the single calls to their actual event makeup that we rely on

jsdom still doesn't support pointer events, jsdom/jsdom#2527
we may be able to move the call to install back to where it originally came from, didn't have time to check before sabbatical. it's useful where it is because it tells us where we are actively using it and there is a bug in User Event that I've addressed here testing-library/user-event#1121

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bit of a shame that we can't get rid of the installPointerEvent, but we can handle setting that up + performing the requisite events calls via our triggerLongPress util I guess

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, it'd be good to just enable pointerEvents everywhere, i don't think any browser is still using the mouse/touch alternate code paths that we are primarily testing anymore anyways. but I decided that was a separate PR as well.

I'd also love to delete those code paths, haha

# Conflicts:
#	packages/@react-spectrum/color/test/ColorArea.test.tsx
#	packages/@react-spectrum/combobox/test/ComboBox.test.js
#	packages/@react-spectrum/datepicker/test/DateField.test.js
#	packages/@react-spectrum/datepicker/test/DatePicker.test.js
#	packages/@react-spectrum/slider/test/RangeSlider.test.tsx
#	packages/@react-spectrum/switch/test/Switch.test.js
#	packages/@react-stately/datepicker/src/useTimeFieldState.ts
#	packages/react-aria-components/test/DropZone.test.js
#	packages/react-aria-components/test/FileTrigger.test.js
#	packages/react-aria-components/test/RadioGroup.test.js
#	packages/react-aria-components/test/Table.test.js
#	packages/react-aria-components/test/TextField.test.js
#	yarn.lock
@rspbot
Copy link

rspbot commented Aug 22, 2023

@rspbot
Copy link

rspbot commented Aug 22, 2023

@snowystinger snowystinger marked this pull request as ready for review August 22, 2023 07:20
@@ -213,24 +199,26 @@ describe('ActionGroup', function () {

let buttons = tree.getAllByRole('button');

orders.forEach(({action, result}, index) => {
action(document.activeElement);
let index = 0;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the same loop as before, just is able to do async now

@rspbot
Copy link

rspbot commented Aug 24, 2023

@rspbot
Copy link

rspbot commented Aug 28, 2023

Copy link
Member

@LFDanLu LFDanLu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some small questions but otherwise looks great! Thanks for doing this upgrade, I'll need to think on how users will affect the test util api, your comment from #4835 (review) makes sense to me, just weighing the pros and cons between the PageObject classes vs util functions. As for allowing the user to pass in their user object, that makes complete sense.

What do you think about enforcing user-event 14 in our test utils vs making the user object optional for user-event 13 backwards compatibility?

packages/dev/test-utils/src/userEventMaps.ts Show resolved Hide resolved
it('handles defaults', () => {
let user;
beforeAll(() => {
user = userEvent.setup({delay: null, pointerMap});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wonder if we can handle this setup in the global beforeAll step or do this setup + return the user object via a util function call. Would make it easier for external users to do the same setup when we eventually expose these test-utils.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that, decided it was better to do it individually to make it easier to swap out users if we need to. Not saying this couldn't be improved, I'm just not sure setting up one globally beforeAll is the best way to go about it. A util function call seems fine, I was thinking something like

import {keyboardUser, mixedPointerKeyboardUser...} from 'whatever-util'

One interesting thing we could possibly do with this is enforce a specific interaction type for a set of tests. I think I we don't supply pointers to the pointerMap, then the user can't user mouse, so they would have to either use touch or keyboard only. But I haven't tried it yet.

let onAction = jest.fn();
let tree = renderSelectionList({onSelectionChange, selectionMode: 'multiple', onAction});
userEvent.click(document.body);
describe('still needs pointer events install', function () {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bit of a shame that we can't get rid of the installPointerEvent, but we can handle setting that up + performing the requisite events calls via our triggerLongPress util I guess

@snowystinger
Copy link
Member Author

What do you think about enforcing user-event 14 in our test utils vs making the user object optional for user-event 13 backwards compatibility?

I would be open to enforcing user-event ^14, I think it'd be difficult to support both.

Copy link
Member

@LFDanLu LFDanLu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, looks like there is a conflict now, but will approve after that is updated

@snowystinger
Copy link
Member Author

snowystinger commented Aug 29, 2023

LGTM, looks like there is a conflict now, but will approve after that is updated

yeah, you'll probably have to do this a number of times, we are constantly updating tests, so this constantly has conflicts. it's why I want to get it in sooner rather than later

@rspbot
Copy link

rspbot commented Aug 30, 2023

LFDanLu
LFDanLu previously approved these changes Aug 30, 2023
@rspbot
Copy link

rspbot commented Sep 4, 2023

# Conflicts:
#	packages/react-aria-components/test/Select.test.js
@rspbot
Copy link

rspbot commented Sep 6, 2023

# Conflicts:
#	packages/react-aria-components/test/Select.test.js
@rspbot
Copy link

rspbot commented Sep 8, 2023

@rspbot
Copy link

rspbot commented Sep 8, 2023

## API Changes

unknown top level export { type: 'identifier', name: 'Column' }
unknown top level export { type: 'identifier', name: 'Column' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }
unknown type { type: 'link' }

Copy link
Member

@devongovett devongovett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Saw a few remaining TODO comments added. Do you have a plan/ticket to address those?

@@ -1043,11 +1048,11 @@ describe('useDraggableCollection', () => {
expect(options).toHaveLength(3);

fireEvent.focus(options[0]);
act(() => userEvent.click(options[0], {pointerType: 'touch'}));
await user.pointer({target: options[0], keys: '[TouchA]'});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wonder why there is no userEvent.tap helper similar to click...

@@ -227,25 +236,28 @@ describe('SearchAutocomplete', function () {
expect(onOpenChange).not.toHaveBeenCalled();
expect(onFocus).toHaveBeenCalled();

fireEvent.keyDown(searchAutocomplete, {key: 'ArrowDown', code: 40, charCode: 40});
fireEvent.keyUp(searchAutocomplete, {key: 'ArrowDown', code: 40, charCode: 40});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should use user event?

await user.keyboard('[MetaLeft>]');
fireEvent.pointerDown(getRow(tree, 'Bar'), {pointerType: 'mouse', metaKey: true});
fireEvent.pointerUp(getRow(tree, 'Bar'), {pointerType: 'mouse', metaKey: true});
fireEvent.click(getRow(tree, 'Bar'), {metaKey: true});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

user.click?

{name: 'MouseMiddle', pointerType: 'mouse', button: 'auxiliary'},
{name: 'TouchA', pointerType: 'touch', height: 1, width: 1},
{name: 'TouchB', pointerType: 'touch'},
{name: 'TouchC', pointerType: 'touch'}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should they all have height/width? More descriptive names if they are actually supposed to be different?

@snowystinger snowystinger merged commit 0b5321d into main Sep 8, 2023
26 checks passed
@snowystinger snowystinger deleted the upgrade-user-event branch September 8, 2023 22:12
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

Successfully merging this pull request may close these issues.

None yet

4 participants