Upgrade user-event to v14

[iansan5653]

We are currently on @testing-library/user-event@13.1.9, which is deprecated and not recommended. As I've been working on the Markdown editor tests, I've run into a number of issues with this outdated version. Rather than hack around them, I figured I would just update the dependency to v14+, which is far more reliable.

There are some breaking changes here. Notably:

• Instead of firing events off of the import directly, you call events off of the result of setup.
• Events always return promises.

In code, this means all tests need to be updated slightly:

- it('example test', () => {
+ it('example test', async () => {
+   const user = userEvent.setup()
    const target = doSomeSetup()
-   userEvent.click(target)
+   await user.click(target)
  })

Merge checklist

• Added/updated tests
• [ ] Added/updated documentation
• [ ] Tested in Chrome
• [ ] Tested in Firefox
• [ ] Tested in Safari
• [ ] Tested in Edge

[changeset-bot]

⚠️ No Changeset found

Latest commit: 77ae087

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

size-limit report 📦

Path	Size
dist/browser.esm.js	68.58 KB (0%)
dist/browser.umd.js	68.95 KB (0%)

[iansan5653]

This strategy of using setTimeout to wait for an action to resolve was actually failing silently because the assertion would fail after the test completes. Introducing async tests exposed this problem because the failure would actually happen during the next test, because async calls get put at the end of the stack. await waitFor is what we want here anyway.

Before, this looked like:

1. suite start
2. test 1 start
3. test 1 end
4. test 2 start
5. test 2 end
6. suite end
7. ⚠️ test 1 assertion completes silently

With async tests, it looked like:

1. suite start
2. test 1 start
3. test 1 end
4. test 2 start
5. ⚠️ test 1 assertion fails, causing test 2 to fail
6. test 2 end
7. suite end

[iansan5653]

Here fixing the setTimeout actually exposed an assertion failure that was previously hidden. Array.sort does not call the sort function once per element like filter or map would; a sorting algorithm has to run more than one single pass over the array to fully sort it. In this case, it was calling the sort function 18 times on an array of 10 elements. Rather than test the number of calls, which depends on the JS engine's sort implementation, I changed it to just test that at least one call was made.

[Lukeghenco]

Quality improvement here for better testing.

[colebemis]

This is a nice upgrade. Thank you, @iansan5653 ✨