With msw enabled, flushPromises from vue-test-utils must be called multiple times to wait for component render

[vincerubinetti]

I have a Vue and vue-test-utils project that I'm trying to use MSW with. I have unit tests for components that call api functions when mounted. Vue exports a function called flushPromises, which is intended to be a simple function you can await to make sure the api calls have returned and the component has finished rendering before continuing with the test.

import { flushPromises, mount } from "@vue/test-utils";

mount(someComponent, mountOptions);

await flushPromises();
await flushPromises(); // <-- need this extra call for MSW to work properly, but not axios-mock-adapter

// some assertions

The component that I'm testing looks like this:

export default defineComponent({
  data() {
    return {
      status: null
    };
  },
  async mounted() {
    this.status = "loading";
    try {
      this.blah = await axios.get(...blah...);
      this.status = null;
    } catch (error) {
      this.status = "error";
    }
  },
});

For some reason, with MSW, I need two flushPromises calls for my tests to pass. The odd thing is, I was using axios-mock-adapter before trying out MSW, and it was working with just one call. Can anyone think of any reason why MSW might be different?

Another funny thing is that MSW is working in my e2e tests in Cypress (setupWorker), but the problem I describe above is happening in my unit tests in Jest (setupServer), which is setup like this:

const server = setupServer(...handlers);
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

[kettanaito]

Hey, @vincerubinetti. Thanks for raising this.

Can you please share more info about the state of your app/test when you're using only one flushPromises? I'm specifically interested in the state of the this.blah Promise returned by axios.get. Is it pending? Is it resolved just not propagated to flushPromises somehow?

MSW uses a different interception mechanism than axios-mock-adapter. That's one of the reasons MSW doesn't depend on axios and can be used with any request library without the need for adapters/plugins.

When looking at the flushPromises function, I can see that it basically defers the setTimeout/setImmediate tick:

   
const scheduler = typeof setImmediate === 'function' ? setImmediate : setTimeout

export function flushPromises() {
  return new Promise((resolve) => {
    scheduler(resolve, 0)
  })
}

This may have an implicit issue when using Fake timers in Jest. Make sure you're using fake timers correctly if you are.

Could you please prepare a reproduction repository where I could look into this issue? That'd be the most efficient way for me to help you. Thanks.

[vincerubinetti]

Thanks so much for your swift reply. I'll try to make a minimal reproduction today.

In the meantime though I'd just like to note that flushPromises is the way recommended by Vue to wait for async operations to complete:

https://next.vue-test-utils.vuejs.org/guide/advanced/async-suspense.html#resolving-other-asynchronous-behavior

[vincerubinetti]

Here is a barebones Vue CLI project with jest unit tests and cypress e2e tests set up:
https://github.com/vincerubinetti/msw-test (archived for posterity)

You can run the unit tests with yarn test:unit and the e2e (with gui) tests with yarn test:e2e. This demonstrates the behavior that msw needs two calls to flushPromises whereas axios-mock-adapter only needs one.

edit I forgot to add... you can verify that msw and axios-mock-adapter are both correctly mocking the call by adding expect(wrapper.text()).toMatch("foo"); expect(wrapper.text()).toMatch("bar");.

[vincerubinetti]

Hi @kettanaito, wondering if you had a chance to take a look at my test repo. This isn't a big deal -- I have a solution that works consistently -- it's just very unusual and I'm curious to understand why it's happening, and perhaps I could learn something in the process.

Also, could you elaborate more on this so I can try to help test/debug:

I'm specifically interested in the state of the this.blah Promise returned by axios.get. Is it pending?

[gfot]

Hi all, I have also tried to use Vue + jest + unit test + msw + flushPromises but having similar problem. In my case, I needed to add 3 await flushPromises in a row to make the test pass. I don't know if that is due to I have imported flush-promises instead of using it from @vue/test-utils.

[vincerubinetti]

That shouldn't make a difference as the code appears to be exactly the same:

https://github.com/kentor/flush-promises/blob/master/index.js
https://github.com/vuejs/test-utils/blob/main/src/utils/flushPromises.ts

Also, that code being so simple is one of the reasons I've filed the issue here and not with vue-test-utils. It must be something odd/funky about the way MSW is scheduling or timing things.

[vincerubinetti]

Another thing to note. I just tried replacing axios with regular old fetch (node-fetch in this case, cause it's jest), and msw still had a problem. So the issue is not in Axios.

[xaviertremel]

Hi everyone! I was also wondering why I have to call flushPromises() 3 times in my tests. My setup: vue 3 + vitest + msw

[vincerubinetti]

The amount of people commenting on this seems to warrant an actual issue. I'm going to create one from this discussion.

#1163