test-utils package for common setup needed
See original GitHub issueš Feature Request
As adoption has increased, the common issues related to testing have also increased - should we include common helper functions such as mockRequestAnimationFrame or mockClientWindow into a package that we can export with RSP? Iām thinking maybe @react-spectrum/test-utils?
š¤ Expected Behavior
Users shouldnāt need to worry about mocking animation frames or client windows
šÆ Current Behavior
Currently, users have to run into the error and figure out that they need to mock those methods/values
š Possible Solution
Option A: Figure out a jest setup that we can export and users can add to their config
Option B: Absorb this npm package, add it to an exportable test-utils folder and add it to the documentation.
Iād prefer option A but donāt have a current solution for it, the package in option B is already typed and being used in production but itās not the optimal dev experience (still involves the user facing the issue first, connecting the dots and then adding the mock function) .
š¦ Context
Seems like engineers are now facing this issue while testing almost daily, itād be nice if we can address it
š» Examples
Similar methods are already being used within our RSP tests, such as
ListView mocking client window
ComboBox mocking request animation frame
š§¢ Your Company/Team
Adobe
š Tracking Ticket (optional)
Issue Analytics
- State:
- Created a year ago
- Comments:7 (7 by maintainers)

Top Related StackOverflow Question
I have a DnD test util at https://github.com/adobe/react-spectrum/compare/main...dnd-test-util that might fit in here well.
This is where Iāve been arriving as well and something Iāve implemented before in another project. Iām curious though on your thoughts if we implement it all as real or fake timers. Does that present issues if the person testing has decided one or the other for themselves.
In the previous project, we had some issues with these higher level test utils being brittle themselves. Though they were written for browser based integration tests which at the time were not great technologies. We also didnāt see great adoption of use for them, though that could have been a documentation issue.