-
Notifications
You must be signed in to change notification settings - Fork 243
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
Enable setting global default setup options #904
Comments
I took a shot at implementing what I'm imagining here and when using it to upgrade my projects, it was a much better experience. I'd love to hear what you think! |
First of all thanks for taking the time to contribute to this library ❤️ Let's try to keep issues separate. That makes it easier to discuss them and reference them later. (No harm in filing multiple short issues at once.) I fear a global config does more harm than good. Regarding the fake timers: A PR resolving #585 would be welcome. type Config = {
// ...
advanceTimers: (delay: number) => Promise<void>
} |
Understood! I'll separate the fake timers into another PR and we can discuss more over there. My thought with the global config was a few things:
Can you elaborate on how it does more harm? People would still need to use |
The PRs have been split. Thanks for taking a look. Hopefully we can come up with a solution that is best for the users! 😃 |
Changes to properties on imported modules have the potential to obfuscate what is happening in a test. |
So just to be clear, you disagree with the standards set by the |
If exposing the I've never used it in any tests and never seen any bug reports or questions that were resolved by pointing out a configuration issue with the documented properties. |
Okay. Just to confirm, So instead of needing a global config method, we can instead do: myUserEvent.js
myTestFile.test.js
If so, this seems like a much easier option for migration than what is in the docs (returning it bundled with the render method). |
Correct, for the workarounds it doesn't matter where it is called. But in accordance with "Avoid Nesting When You're Testing" we recommend to import userEvent from '@testing-library/user-event'
const user = userEvent.setup()
test('type something', async () => {
render(<input/>)
// If you move this after the following test,
// it won't type because Ctrl+Char has no `keypress`.
await user.type('something')
// ...
})
test('click with control', async () => {
render(<button/>)
await user.keyboard('{Control>}')
await user.click(screen.getByRole('button'))
// ... Control is still pressed
}) |
Got it. I guess this will never be accepted so I'll close this issue and the related PR. Thanks for discussing with me. |
Problem description
This is related to #833.
If we are using fake timers in all tests, that means that we now must specify
{ delay: null }
in every test when we calluserEvent.setup
.Suggested solution
In the spirit of dom-testing-library's configure method it'd be nice to have a top-level function which can set the default options for
userEvent.setup
so we don't have to pass them in every time.Additionally, having an option to bypass the fake timers for this library rather than having to turn off the delay entirely would be even better! (I'd argue this should be default since it's a very difficult bug to track down when upgrading this library and suddenly having tests timeout.)
Additional context
No response
The text was updated successfully, but these errors were encountered: