Testing in-progress state after user-event

[rvsia]

Hello,

I have a lot of tests, that cover in-progress states after actions (e.g. click) and before the async method (e.g. api call) is resolved.

Example

// Component.js
   ...
   onClick = () => { 
       setLoading();
       reloadData().then(data => setData(data));
   }
   ...

Before

// Test.test.js
   ...
   reloadData = jest.fn().mockResolvedValue(data);

   userEvent.click(component)

   expect(screen.getByRole('progressrole')).toBeInTheDocument();

   await waitFor(....)
   ...

But because all user events are now returned as promises, it immediately resolves the async request too, so it is not possible to check the in-between state:

After

// Test.test.js
   ...
   reloadData = jest.fn().mockResolvedValue(data);

   await userEvent.click(component)

   ??? expect(screen.getByRole('progressrole')).toBeInTheDocument(); ???
   ...

Is there a way how to test the in-progress state without using setTimeouts in the mocked async methods?

[ph-fritsche]

The Promise returned by .click() resolves when the library is done simulating the interaction.
The asynchronous request is not resolved instantly, just before this is finished.

One way to test such things is to await the state you want to test on:

// Get a Promise and the callback to resolve it
let resolveWaitForLoadingState = () => {}
const waitForLoadingState = new Promise(r => { resolveWaitForLoadingState = r })

// Resolve the Promise when the mock puts your component in the state to be observed
reloadData = jest.fn(() => {
  resolveWaitForLoadingState()
  return data
})

// Start the click simulation and wait for the right moment to run your assertion
await Promise.all([
  user.click(element),
  waitForLoadingState.then(() => { expect(screen.getByRole('progressrole')).toBeInTheDocument() }),
})

Another is to implement the reloadData to not settle during the same macrotask:

// Let `reloadData` take 5ms
reloadData = jest.fn(async () => {
  await new Promise(r => setTimeout(r, 5))
  return data
})

await user.click(element)
// Still 5ms of reloading data ...
expect(screen.getByRole('progressrole')).toBeInTheDocument()

A third way is to control when your mock resolves from outside:

let resolveReloadingData = () => {}

reloadData = jest.fn(() => new Promise(r => { resolveReloadingData = r })

await user.click(element)

expect(screen.getByRole('progressrole')).toBeInTheDocument()

resolveReloadingData(data)

[rvsia]

Hmmm however I found that this approach is not very stable - sometimes it passes, sometimes it's not.

[ph-fritsche]

If you don't want to take the first approach (await the desired state), you'll need to increase the delay and/or use fake timers.

I also added a third suggestion to control the mock from outside.

[rvsia]

I would like to use the first approach as it is similar to what happens in the real environment. Increasing delay helps, but I set the timeout value to 60 by random guesses as it was the first value that worked for me.. is there some delay value (resp. does RTL waits form some specific time?), that would work all the time?

[ph-fritsche]

No, this is either other code occupying the JS engine or the engine itself is delayed by other threads occupying the CPU.

[rvsia]

Understand, thank you for your help!