This approach should make your second and third test warnings go away.
As for the first test (which also throws this warning)
// const wrapper = ...expect(wrapper.exists()).toEqual(true);expect(wrapper.text()).toEqual('Loading store data...');// warning actually is being thrown after this line /\
So what actually happens? Well, you make an assertion for loading state which passes, then, very loosely named, next tick happens and state updates to an error (asynchronously) and the test finishes. What you have to do in such situations is to queue a task (task-queue) that contains an act, after the assertion, like so:
// const wrapper = ...expect(wrapper.exists()).toEqual(true);expect(wrapper.text()).toEqual('Loading store data...');awaitact(async()=>awaitPromise.resolve());
The error will go await. act will put your callback inside batch update when React flushes tasks, guaranteeing that any left-overs async updates are taken care of.
You should give @testing-library/react a shot! in my opinion, it's much better than enzyme.
I'm not an expert and the things I said about the task queue and stuff may be wrong. It's just how I think about it.
Wojciech, if I'm following your notes correctly, the difference is in how the testing-library/react appends to the action queue the callback versus how wait-for-expect isn't allowing the other asynchronous tasks to complete.
Sorry for being stubborn before, the event loop is still a new concept to me. Thanks for the overall help. I was able to put together a simple commit that swaps the libraries and gets me to a more green test suite.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi there!
waitForExpect
is not wrapping your callback withact
(like it should in react), thus causing that error.My recommendation would be to use
@testing-library/react
wait
function.This approach should make your second and third test warnings go away.
As for the first test (which also throws this warning)
So what actually happens? Well, you make an assertion for loading state which passes, then, very loosely named, next tick happens and state updates to an error (asynchronously) and the test finishes. What you have to do in such situations is to queue a task (task-queue) that contains an act, after the assertion, like so:
The error will go await.
act
will put your callback inside batch update when React flushes tasks, guaranteeing that any left-overs async updates are taken care of.You should give
@testing-library/react
a shot! in my opinion, it's much better thanenzyme
.I'm not an expert and the things I said about the task queue and stuff may be wrong. It's just how I think about it.
Cheers!
Thanks again for the updated response.
I'll go back through and update my tests to try following this pattern. Will update when I have some new findings.
Thanks for the tip, Wojciech.
I looked into the library you referenced for a few minutes and found that
@testing-library/react
has await()
function, which is documented as a small wrapper around the await-for expect module.I don't think that is much gained from using it. There's even a callout in the readme about suppressing the very warning that I'm complaining about.
Wojciech, if I'm following your notes correctly, the difference is in how the
testing-library/react
appends to the action queue the callback versus howwait-for-expect
isn't allowing the other asynchronous tasks to complete.Sorry for being stubborn before, the event loop is still a new concept to me. Thanks for the overall help. I was able to put together a simple commit that swaps the libraries and gets me to a more green test suite.