-
Notifications
You must be signed in to change notification settings - Fork 33
Add ability to await fireEvent #30
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
Comments
Would it make sense to make it a "thenable" instead of a actual promise to avoid dangling promise chains in the tests? |
This isn't actually necessary due to how Svelte's updates work. Svelte batches updates and processes them in the next microtask, in order to ensure changes have been flushed to the DOM we can simply test('clicking the button should change the text', async () => {
const { getByText } = render(Hello);
const button = getByText('Change');
const button2 = getByText('Change Again');
const h1 = getByText('Hello World');
await fireEvent.click(button);
expect(h1.innerHTML).toBe('Hello Everybody');
await fireEvent.click(button2);
expect(h1.innerHTML).toBe('Hello Nobody');
}); This also works when performing multiple actions: test('updating Checkbox inputs should work', async () => {
const { getByText, getAllByLabelText } = render(Inputs);
const inputs = getAllByLabelText(/Rice|Beans|Cheese|Guac/);
const output = getByText(/Value CBG:/);
await inputs.map(element => fireEvent.click(element));
expect(output.innerHTML).toBe('Value CBG: Rice,Beans,Cheese,Guac (extra)');
}); I don't think this is a commonly known detail and perhaps warrants documentation, there may be times when this approach fails but a simple |
I'm fairly certain awaiting something that is not a Promise does not have the effect you are describing - it just returns immediately as if the await wasn't there. I think we exolored this before @kentcdodds? |
I believe so. Either way what you really want to use is findBy and findAllBy queries instead of awaiting the fireEvent API. |
Actually, based on the example above what you probably should be doing is wrapping the assertion inside |
This is incorrect. Awaiting a non-promise/ thenable wraps the value in a promise or something to that effect. As I understand it, Regardless, the above code snippets are not theoretical examples but taken from actual tests that run and pass as expected, removing Examples of the aforementioned tests in action can be found here and here |
Thanks for clarifying @pngwn 👍 |
Uh oh!
There was an error while loading. Please reload this page.
As was outlined in this issue, you sometimes need to wait for the next microtask to run before changes in the DOM have been flushed.
Maybe we could create a small abstraction over
fireEvent
fromdom-testing-library
and return atick
promise so thatfireEvent
can be awaited directly?The text was updated successfully, but these errors were encountered: