How to setup MSW for Vitest browser mode?

[foxaltus]

I'm trying Vitest browser mode (still experimental) and I'm wondering what's the canonical way to setup MSW in this mode? I tried:

// src/vitest-setup.ts
import { worker } from "./mocks/browser";
import { cleanup } from "@testing-library/react";

// from https://mswjs.io/docs/getting-started/integrate/node#setup
// Establish API mocking before all tests.
beforeAll(async () => {
  await worker.start({ onUnhandledRequest: "error" });
});

// Reset any request handlers that we may add during the tests,
// so they don't affect other tests.
afterEach(() => {
  worker.resetHandlers();
  cleanup();
});

// Clean up after the tests are finished.
afterAll(() => {
  worker.stop();
});

with:

// vitest.config.ts
import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    setupFiles: ["src/vitest-setup.ts"],
    globals: true,
    browser: {
      enabled: true,
      name: "chromium",
      provider: "playwright",
    },
  },
});

While this seems to work, I'm not sure this is 100% correct.

Also, I am not able to override a request in a single test using:

  worker.use(...);
  render(<MyComponent />);

The override doesn't seem to have any effect or to be taken into account.

EDIT: the override works if I move whatever I have inside vitest-setup.ts into the test file instead. I'm not quite sure why.

[kettanaito]

Hi, @foxaltus.

I suspect that setup files aren't applied in the browser. That's still the setup file for your Node.js run of Vitest.

@sheremet-va, please correct me if I'm wrong.

[sheremet-va]

Setup files are imported in the browser mode.

[foxaltus]

Do I need to file a bug in Vitest with a repo to repro? But is the "normal"/"recommended" setup for MSW in browser mode anyway?

[kettanaito]

@foxaltus, we are still exploring the recommended setup. I will provide more info once I get to use the Browser mode more. I think what you have above should work. If it doesn't, file an issue.

[foxaltus]

I have reported the bug at: vitest-dev/vitest#6690

[kettanaito]

I've added the Vitest Browser Mode recipe to the MSW docs. Please follow it to integrate MSW with Vitest Browser Mode. Thanks!

[foxaltus]

Thanks, this looks neat! Excited to try it!

[RafaelFerreiraTVD]

I'm not sure if this an issue of MSW or vitest, but I'm having some inconsistencies during the tests.
Even after following this recipe I have some calls that are not handled by the MSW, which cause my tests to fail because it's expecting to return some data and I receive 404, and to make it worse it's not consistent which initially caused a lot of stress debugging what could be wrong. 😆

I can workaround this, if I actually retry the call (using tanstack query btw). I tried to debug for a bit, but without any conclusions.

Seems like the worker is registered but somehow is not yet ready to handle the requests.
I'm not sure if the worker.start Promise returns the "ready to handle" state, if that's the case, then it becomes really strange why this happening.

Have you seen something similar to this? @kettanaito

[jamesg1]

Likewise I'm getting inconsistent results with vitest (playwright browser)+msw+react-query+playwright did you manage to work out a solution? Must be how the server's are being init'd.

[RafaelFerreiraTVD]

Oh, sorry @jamesg1
Only noticed this now! My workaround to this, has been applying the retries that react-query already has.
So, for tests, I defined a different queryClient which includes those retries.

Basically I do have this:

beforeEach(() => {  
  queryClient.setDefaultOptions({
    queries: {
      retry: 3,
      throwOnError: true,
    },
   ....
  });
});

[jamesg1]

I ended up abandoning due to the inconsistencies between test runs with vite browser mode and msw.

[RafaelFerreiraTVD]

apart from this, I didn't face anything else! so, might be good to give it a try again 🚀

[JoaoCnh]

I'm having some weird behaviour when tests are defined in the same file.

If first test uses default handler it passes but next text that overrides fails as if it didn't override.

But if I reverse the order, the second one (which is now first one) gets overridden well and passes and both pass.

Does anyone have any idea why?

[JoaoCnh]

Essentially I have the exact same setup as the docs recipe.

The handlers file has the default successful api return data.

extendedTest(
    'should render the thing if data is returned from API',
    async () => {
      const screen = render(
        <Thing />
      );

      await expect.element(screen.getByText('thing')).toBeInTheDocument();
    }
  );
  
  extendedTest(
    'should not render the thing if data is not returned from API',
    async ({ worker }) => {
      worker.use(
        http.get(
          '/api',
          () => new HttpResponse(null, { status: 500 })
        )
      );

      const screen = render(
        <Thing />
      );

      await expect.element(screen.getByText('thing')).not.toBeInTheDocument();
    }
  );

The second test will fail and the logs show data being returned. Even tried with { once: true } in the worker settings.

If I define the second test first both will pass even though logs still show data being returned.

If only the second test is define the test passes and logs show the 500 error being returned.

I'm a bit stumped as I would prefer to keep these related tests together in the same file.

[thetobber]

I had a similar issue and found that in my case it happened because @tanstack/vue-query was caching the results, so adding queryClient.clear(); in the start of every test fixed it.

[jamesg1]

I'm also trying to use a similar setup of Vitest + @testing-library/react + react-query msw but I'm getting really inconsistent results for my tests. Considering switching to vitest-browser-react instead.

[JoaoCnh]

I am using vitest-browser-react and I still have the issue I described above.

[jamesg1]

I seem to have the same test pass outside of a describe but fail within a describe? Is there gotcha's for using 'describe'/suites?

Moving the code out of the describe appeared to help here as I'm expecting button-abc to not be disabled.

// handler.ts
let currentMockUser = 'abcAdminUser'; // Default user for tests

// example.test.tsx
beforeEach(() => {
  setMockUser('abcAdminUser');
});

test("renders basic component", async () => {
  const screen = render(
    <QueryClientProvider client={queryClient}>
      <BrowserRouter>
        <AuthContext.Provider value={authenticatedAuthContextValue}>
          <ExampleFormComp />
        </AuthContext.Provider>
      </BrowserRouter>
    </QueryClientProvider>
  );
  await expect.element(screen.getByTestId("button-abc")).not.toBeDisabled();
  await expect.element(screen.getByTestId("button-def")).toBeDisabled();
  await expect.element(screen.getByTestId("button-zzz")).toBeDisabled();
  await expect.element(screen.getByTestId("button-xx")).toBeDisabled();
});

From the console debug when its in a describe stdout goes to unknown test. Outside of describe the stdout is always referring to the test.

with a describe

isEnabled false
stdout | src/components/settings/me/me.test.tsx > MeForm > renders basic component
isEnabled false
stdout | src/components/settings/me/me.test.tsx > MeForm > renders basic component
isEnabled false
stdout | src/components/settings/me/me.test.tsx> MeForm > renders basic component
isEnabled false
stdout | unknown test
isEnabled true
stdout | unknown test
isEnabled false
stdout | unknown test
isEnabled false
stdout | unknown test
isEnabled false
stdout | unknown test

[jamesg1]

I'm using it too with

// test-extend.ts
import { test as testBase } from 'vitest';
import { worker } from './browser-vitest';

export const test = testBase.extend({
  worker: [
    async ({}, use) => {
      // Start the worker before the test.
      await worker.start({
        quiet: true,
      });

      // Expose the worker object on the test's context.
      await use(worker);

      // Remove any request handlers added in individual test cases.
      // This prevents them from affecting unrelated tests.
      worker.resetHandlers();
    },
    {
      auto: true,
    },
  ],
});

And i keep getting these errors

stderr | src/components/settings/comp/Comp.test.tsx > renders component for regular user
[MSW] Found a redundant "worker.start()" call. Note that starting the worker while mocking is already enabled will have no effect. Consider removing this "worker.start()" call.
stderr | src/components/settings/comp/Comp.test.tsx > renders slack command component
[MSW] Found a redundant "worker.start()" call. Note that starting the worker while mocking is already enabled will have no effect. Consider removing this "worker.start()" call.

It seems pretty clear msw with vitest browser is still experimental. Most examples I see that are working still target jsdom.