Usage with Remix and Playwright

[kirillkurko]

I'm looking for a good example of using MSW with Remix and Playwright. There are some examples on the internet like this one, but what I'm looking for is the usage of server.use(...) inside my tests. The problem that I'm facing is that while handlers are prepended (verified using server.printHandlers()), override is not working.

[kettanaito]

Hey, @kirillkurko. Take a look at our Official Remix + Playwright + MSW usage example.

Using the runtime handlers (worker.use()) is a matter of exposing worker on window and accessing it in page.evaluate() in your Playwright tests.

[kettanaito]

Can you tell me more about what you're trying to do?

Using Playwright implies running in the browser, and the way to use MSW in the browser is via the setupWorker API. I may be missing the point of what you're trying to achieve, would like to learn more.

[kettanaito]

Note that the example I linked features both client-side and server-side API mocking in Remix at the same time. You cannot use server.use() in Playwright tests because your app and your test are running in two separate processes. I'm playing around with a solution for this in #1617, which is going to be huge. Until then, you cannot have test-based server-side API mocks with MSW, just as you can't have them in general at the moment.

[kirillkurko]

Thanks for the reply, you actually answered my question and worker is a way to go for me. "setupRemoteServer" API looks really interesting, but it's definitely a huge milestone

[pauloricardos]

hey @kettanaito this page Official Remix + Playwright + MSW seems broken

[kettanaito]

@pauloricardos, thanks for letting me know! So GitHub repo redirects do have an EOL. Fixed the link, it leads to the correct example now.

[dadamssg]

I know this is an old post but i came up with something that works. I created a remix action to interact with server.use() from my playwright tests.

Super low tech solution to the remote server concept. This might be extremely dumb though 🤷‍♂️😅

[jumpcutfindo]

Hi, thanks for the comment, we were facing something similar in our project and this led us down a similar path :)

We implemented an action similar to yours, but to add more fine grained control we implemented a simple API to control the mock server:

// mocks/mock-controller.ts

export async function action({ request }: ActionFunctionArgs) {
  // Parse the request here and switch according to some fields in the request body
  // Depending on the action specified, route to the appropriate functions
}

async function startup() { ... }
async function shutdown() { ... }
async function reset() { ... }
async function override(request: OverrideRequest) { ... }

To make it more elegant inside each Playwright test, we added some Playwright fixtures, inspired in part by the implementation in playwright-msw:

// tests/fixtures.ts

interface TestFixtures {
  mockServer: {
    startup: () => Promise<void>;
    shutdown: () => Promise<void>;
    reset: () => Promise<void>;
    override: (data: OverrideRequestBody) => Promise<void>;
  };
}

const test = base.extend<TestFixtures>({
  mockServer: {
    startup: async () => {
      await fetch(MOCK_CONTROLLER_ENDPOINT, {
        method: 'POST',
        body: JSON.stringify({
          action: 'startup',
        }),
      });
    },

    shutdown: async () => {
      await fetch(MOCK_CONTROLLER_ENDPOINT, {
        method: 'POST',
        body: JSON.stringify({
          action: 'shutdown',
        }),
      });
    },

    reset: async () => {
      await fetch(MOCK_CONTROLLER_ENDPOINT, {
        method: 'POST',
        body: JSON.stringify({
          action: 'reset',
        }),
      });
    },

    override: async (data) => {
      await fetch(MOCK_CONTROLLER_ENDPOINT, {
        method: 'POST',
        body: JSON.stringify({
          action: 'override',
          data,
        }),
      });
    },
  },
});

export { test, expect };

This allows us to configure the mock server response like so in individual tests:

// tests/login.spec.ts

// Note:
// - Need to start, reset and stop mock server with `test.beforeAll`, `test.afterEach` and `test.afterAll` with this
// - Probably have to run the test suite with `test.describe.serial` instead of in parallel

import { expect, test } from 'tests/fixtures';

test('should show error when trying invalid credentials', async ({
    page,
    mockServer,
  }) => {
    await mockServer.override({
      method: HttpMethods.POST,
      url: '/user/login',
      statusCode: 401,
      body: { error: 'Incorrect username or password' },
    });
   
   ... rest of the test
 });

We also configured it such that the mock controller is registered only if process.env.NODE_ENV is test:

// vite.config.ts

export default defineConfig({
  plugins: [
    ... other plugins,
    routes(defineRoutes) {
        return defineRoutes((route) => {
          if (process.env.NODE_ENV === 'test') {
            // Register mocked route for handling
            route('/__mock', '../mocks/mock-controller.ts');
          }
        });
      },
   ],
});

[dadamssg]

nice!

[AriPerkkio]

@dadamssg & @jumpcutfindo, are you running these setups against the Vite dev server or Remix production build?