[code-infra] Optimize @testing-library/user-event
#43804
Conversation
Janpot
changed the title
@testing-library/user-event
Netlify deploy previewhttps://deploy-preview-43804--material-ui.netlify.app/ Bundle size report |
| @@ -301,7 +301,7 @@ function render( | |||
| ); | |||
| const result: MuiRenderResult = { | |||
| ...testingLibraryRenderResult, | |||
| user: userEvent.setup(), | |||
| user: userEvent.setup({ delay: null }), | |||
There was a problem hiding this comment.
Going off topic, but would this works instead?
| user: userEvent.setup({ delay: null }), | |
| export const userEventInstance = userEvent.setup({ delay: null }); |
There was a problem hiding this comment.
I think you want to initialize it per test. At least that's seems to be recommended on their docs. I understand the instance hold state and you can avoid interference between parallel tests this way.
We discourage rendering or using any userEvent functions outside of the test itself - e.g. in a before/after hook
There was a problem hiding this comment.
This is what I'm not clear about. In the source, I didn't see logic that required it to be initialized once for all the tests, this would save CI time for each test and make the DX simpler as well.
There was a problem hiding this comment.
Not sure I follow @oliviertassinari. I think we should just follow the Testing Lib recommendation here i.e. setup userEvent once per test.
There was a problem hiding this comment.
I have found testing-library/user-event#1036 (comment) about this. It could be ok
You should use userEvent.setup() after creating the document and before you render() your component. [...] if you hit one of the rare edge cases, it might be hard to debug - especially since most environments don't create a new document for each test.
prepareDocumentbails out if it's already called. https://github.com/testing-library/user-event/blob/d0362796a33c2d39713998f82ae309020c37b385/src/document/prepareDocument.ts#L19attachClipboardStubToViewbails out if it's already called. https://github.com/testing-library/user-event/blob/d0362796a33c2d39713998f82ae309020c37b385/src/utils/dataTransfer/Clipboard.ts#L113
So I don't really see why it's needed in our case since we share the same document between tests.
But no hard point of view. Just that if we want to be greedy, there is maybe an opportunity, but maybe not.
There was a problem hiding this comment.
With Vitest, the need to have a document always setup for each test could become an issue, depending on how parallelism is implemented. I imagine that it's OK, but it might not.
Technically yes, but unlikely. We could try it out before merging.
We could add a parameter to |
|
🙂 Yep, trying this in X breaks the tests, Edit: Looks like it now fails consistently |
See this thread
I've seen this reduce the time of running
userEvent.keyboardby an order of magnitude, eliminating the motivation to avoid using this library. It comes at the cost of slightly changed semantics. But even with these different semantics, we'd be better off compared to the way we currently test.It would be best for us to primarily optimize our tests for refactorability. Tests that require updates on every implementation detail change miss the mark. We should aim at tests that maximize interfacing with public API and minimize reliance on implementation details. Therefore, unless we specifically want to test an implementation detail, we should prefer
userEvent.Closes mui/mui-x#14668