An onUnhandledRequest error does not make the test fail

[bennettdams]

I just started using MSW and found out that an onUnhandledRequest error does not make the test fail:

Here's my config:

jest.config.js

module.exports = {
  ...
  setupFilesAfterEnv: [
    "<rootDir>/jest.setup.js",
    "<rootDir>/__mocks__/global-mocks.ts",
    "<rootDir>/__mocks__/msw/msw-setup.ts",
  ],
  ...
};

msw-setup.ts

import { setupServer } from "msw/node";
import { handlers } from "./handlers";
// for polyfill
import "whatwg-fetch";

export const server = setupServer(...handlers);

beforeAll(() =>
  server.listen({
    onUnhandledRequest: "error",
  })
);
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

Is there something specific that has to be configured for my test to fail in such situations?

---

BTW: As a beginner of MSW, I looked for a solution to block all requests that are not handled via MSW. I still wanted to get notified of missing handlers, so using wildcards (e.g. rest.get("*")) was not an option. The docs and also the console message when onUnhandledRequest is "triggered" do not make this clear in my opinion. Without this discussion, I would've never known that the requests are also blocked (which is exactly what I wanted).

[kettanaito]

Hey, @bennettdams.

Could you please ensure you're using the latest version of the library? npm ls msw should print 0.36.0.

As a beginner of MSW, I looked for a solution to block all requests that are not handled via MSW

You've chosen the right API: setting onUnhandledRequest: 'error' will prevent any unmocked requests in your tests.

[kettanaito]

The version seems correct, so could you take a look if there's this code in the installed library?

msw/src/utils/request/onUnhandledRequest.ts

Lines 171 to 180 in ac0a62a

	switch (strategy) {
	case 'error': {
	// Print a developer-friendly error.
	devUtils.error('Error: %s', message)
	// Throw an exception to halt request processing and not perform the original request.
	throw new Error(
	'Cannot bypass a request when using the "error" strategy for the "onUnhandledRequest" option.',
	)
	}

Clicking on the first frame from the error message you see should lead you right to this spot in the compiled bundle.

It should throw an exception after the error you're seeing.

Also, check if your test doesn't silently swallow such exceptions. If you included the test itself I could help you check that.

[bennettdams]

It should throw an exception after the error you're seeing.

Yup, it does (at least the code is there in my local node_modules):

Also, check if your test doesn't silently swallow such exceptions.

I already checked by throwing an error in a) the component that I'm testing and b) the test itself, both variants will correctly make the test fail.

If you included the test itself I could help you check that.

The test is very, very basic for testing MSW out. The component internally fetches some data as well, which is the request that is unhandled and should throw the error.

Which more information could be helpful?

describe("Header", () => {
  it("renders", () => {
    render(<Header />);

    expect(
      screen.getByText("some header")
    ).toBeInTheDocument();
  });
});

For the test, I did a manual fetch in this Header component to see if it makes the test fail:

useEffect(() => {
  async function test() {
    await fetch("https://jsonplaceholder.typicode.com/todos/1");
  }
  test();
}, []);

...which produces the right error, but does not make the test fail:

[bennettdams]

Here's a few more things I've tried:

• using React's Test Renderer instead of React Testing Library
• I'm using WSL 2 with VS Code, so I executed the tests "natively" in Windows as well
• remove different parts of my jest.config.js
• move my __mocks__ folder (where the MSW config lives) into the __tests__ folder
• remove node_modules
• disable all <ErrorBoundary>.. I have in my code
• Write a test that just executes a fetch, which has nothing to do with React/rendering. I don't even think this would work, because the function is not throwing the error but MSW is:

describe("General test setup", () => {
  it("fails when an API is called that is not handled by MSW", () => {
    // fetch from a random API point
    const randomAPICall = async () =>
      await fetch("http://localhost/some-api" + Math.random());

    expect(randomAPICall).toThrowError();
  });
});

Nothing helped resolving this.

BTW: I'm using MSW with Next.js & TypeScript

---

For reference, here's my full jest.config.js:

module.exports = {
  collectCoverageFrom: [
    "**/*.{js,jsx,ts,tsx}",
    "!**/*.d.ts",
    "!**/node_modules/**",
  ],
  moduleNameMapper: {
    /* Handle CSS imports (with CSS modules)
      https://jestjs.io/docs/webpack#mocking-css-modules */
    "^.+\\.module\\.(css|sass|scss)$": "identity-obj-proxy",

    // Handle CSS imports (without CSS modules)
    "^.+\\.(css|sass|scss)$": "<rootDir>/__mocks__/styleMock.js",

    /* Handle image imports
      https://jestjs.io/docs/webpack#handling-static-assets */
    "^.+\\.(jpg|jpeg|png|gif|webp|svg)$": "<rootDir>/__mocks__/fileMock.js",
  },
  testPathIgnorePatterns: [
    "<rootDir>/node_modules/",
    "<rootDir>/.next/",
    "<rootDir>/__tests__/test-utils.tsx",
    "<rootDir>/__tests__/test-setup.ts",
  ],
  testEnvironment: "jsdom",
  reporters: [
    "default",
    [
      "jest-junit",
      {
        suiteName: "Bla Bla",
        outputName: "blabla-test-report.xml",
        outputDirectory: "__tests__/reports",
      },
    ],
  ],
  transform: {
    /* Use babel-jest to transpile tests with the next/babel preset
      https://jestjs.io/docs/configuration#transform-objectstring-pathtotransformer--pathtotransformer-object */
    "^.+\\.(js|jsx|ts|tsx)$": ["babel-jest", { presets: ["next/babel"] }],
  },
  globalSetup: "<rootDir>/__tests__/test-setup.ts",
  setupFilesAfterEnv: [
    "<rootDir>/jest.setup.js",
    "<rootDir>/__mocks__/global-mocks.ts",
    "<rootDir>/__mocks__/msw/msw-setup.ts",
  ],
  transformIgnorePatterns: [
    "/node_modules/",
    "^.+\\.module\\.(css|sass|scss)$",
  ],
};

[bennettdams]

I can reproduce this with a fresh installation of everything and their default configurations in a new "Create Next App" project, will upload a reproduction repo soon. I think it's worth creating a "real" issue for that.

Update: Created an issue: #946

[kettanaito]

Thank you for following up on this.