Repository navigation
Unexpected failing test when mixing promises and useEffect #1093
Description
Describe the bug
I've written a small test case demonstrating issues I've had when combining user event (press) -> promise -> setState -> useEffect. The test case fails for RNTL but passes on @testing-library/react.
test.only('async event with fireEvent', async () => {
const Comp = ({ onPress }: { onPress: () => void }) => {
const [state, setState] = React.useState(false);
React.useEffect(() => {
console.log('useEffect');
if (state) {
console.log('onPress');
onPress();
}
}, [state, onPress]);
return (
<Pressable
onPress={async () => {
console.log('waiting');
await Promise.resolve();
console.log('setting');
setState(true);
}}
>
<Text>Trigger</Text>
</Pressable>
);
};
const spy = jest.fn();
const { getByText } = render(<Comp onPress={spy} />);
fireEvent.press(getByText('Trigger'));
await waitFor(() => {
console.log('checking');
expect(spy).toHaveBeenCalled();
});
});Logs go:
useEffect
waiting
checking
setting
checking
... a bunch of other `checking`
checking
useEffect
onPress
Note that the final onPress call (the one that we're waiting for) happens after the last check.
Expected behavior
It works as expected on web, with those logs
useEffect
waiting
checking
setting
useEffect
onPress
checking
I'll do more investigation to figure out what's happening, but if anyone manage to fix it, feel free to do so :) I kind of expect this issue to be related to a lot of the ones we've had around problems with waitFor, or async act ....
Versions
Latest main, commit of cb46ae2689cc661879e8609766041bf93f1d3137.
Activity
AugustinLF commentedon Sep 4, 2022
Changing the way we handle async update to the way it's handled in the newer versions of
@testing-library/react, i.e. dropping theawait actand changing the globalIS_REACT_ACT_ENVIRONMENTvariable works (not changing the global variable still works but leads to someconsole.error.https://github.com/testing-library/react-testing-library/pull/1031/files#diff-2ef28f1bd92d5dcd1f2a04d56814d3adaee10cc939b4a7d7c861af3a3cbbccb7R22
I'll need to investigate a bit more on what are the consequences of this change. @mdjastrzebski we officially support
react@>16, right? Have we considered running bothreact@17andreact@18in the CI?mdjastrzebski commentedon Sep 8, 2022
@AugustinLF that's interesting, I will need some more time to understand that RTL approach here. Regarding support we run our test against
react@18(matching RN version). Previously we ran it against previous RN versions, some of which werereact@17.If we want to support many RN version we can duplicate
examples/basicwith various RN & React version and plug them into proper CI job. Note thatexample/*tests are run against published RNTL version(s), not local one.AugustinLF commentedon Sep 12, 2022
Reading a bit about react@18 this behaviour seems to be mandatory, quoting:
reactwg/react-18#102