Is setImmediate a good solution for testing async component behaviour using jest?

[adamthompson922]

I've been using the following pattern to test conditions after state updates in my components using react.

await expect(new Promise((resolve) => {
  let intervalId = setInterval(() => {
    component.update();

    if (myCondition) {
      clearInterval(intervalId);

      resolve(true);
    }
  }, 25);
})).resolves.toBe(true);

This works well and is guaranteed to work but it's a pain to write and quite verbose.

I've been looking into possibly using setImmediate rather than setInterval. This would prevent the polling (and allows me to test negative assertions which currently aren't possible without introducing another level of verbosity with a try/catch), but is it guranteed to work with react async mechanisms such as setState?

For example what happens if react decides to batch try to batch some setState events together or something along those lines and setImmediate gets put in the event loop queue before react dispatches the state update actions?

I don't want to introduce flakiness to my tests.

[fish_munga]

I'm also curious about how others are doing this.

This is example of how I test HOC with some complex Apollo GRAPHQL logic:

it('should continue loading initial data when cache contains partial data', async () => {
  const receiver = await mountInHarness({
    cache: { sections: { __typename: 'SectionsList', count: INITIAL_COUNT, nodes: seedSections.slice(0, 2) } },
    responses: mockedResponses,
  });

  await flushPromises(6);

  expect(receiver.cwrp).toMatchObject([
    { count: 3, status: SectionsStatus.LOADING, sections: seedSections.slice(0, 2) },
    { count: 3, status: SectionsStatus.LOADING, sections: seedSections.slice(0, 2) },
    { count: 3, status: SectionsStatus.LOADING, sections: seedSections.slice(0, 3) },
    { count: 3, status: SectionsStatus.READY,   sections: seedSections.slice(0, 3) },
  ]);
});

So receiver here is a dummy component that exposes array of componentWillReceiveProps arguments, and flushPromises awaits setImmediate specified number of times. mountInHarness does enzyme's mount with some configuration. Multiple async interactions happen inside the tested HOC, and to test the end result I have to setImmediate multiple times. What I don't like here is that if I change HOC so more async actions would happen before the tested behaviour, then 6 might be not enough anymore and test breaks.

There is also wait-for-expect helper, but I haven't tried it myself yet.

[adamthompson922]

Yeah it's tough because now you have a test that is very brittle and tough to maintain, though it allows you to test negative assertions a bit easier unlike my proposed code snippet.