Built-in testing?

[kentcdodds]

Might be helpful. My idea is basically a @remix-run/test package with all the utilities.

• Built on top of @testing-library/react and re-exports everything + a custom render that includes all providers our route components have access to when they're run + any utilities to set the loader/action data both on initial render as well as re-rendering with those values.
• @testing-library/user-event should be built-in as well
• As @sergiodxa suggested, Jest assertions for Responses
• Potentially some helpers for E2E tests with Cypress and MSW 🤔

[sergiodxa]

Aside of a testing setup, it would be helpful to have Jest assertions for Responses so you could test loaders and responses easily

[andrewgadziksonos]

Would it be possible to spin up a checklist of items that are needed to implement this? It seems like the community is eager to get this in and with a checklist we could help out!

so you could test losers and responses easily

I giggled at this @sergiodxa 😂 (assuming you mean loaders here)

[kentcdodds]

spin up a checklist of items that are needed

This is probably something I'll need to work on myself to get the package off the ground I think. But I did put a couple high-level ideas. I'm sure the package will evolve.

[wladpaiva]

I wonder if this render could also be used for the storybook rendering system. It would be really nice tweek things like transition and see things changing.

Also, since remix ins't going to be react only (as far I have seen), we'll probably have to split up the package

[kentcdodds]

That's a good point. It's possible that we'll want multiple packages. I've had to put this work on hold for a little bit while I work on higher-priority things, but I'll be thinking more on this. I do want to be the one who does this work though so thank you all for your patience.

[sergiodxa]

I think at least two libraries for now will make sense, one for server-side testing helpers (like the Jest assertions for response objects or helpers to test loaders/actions that throw responses), and another one with the React helpers (the render function).

That way in a future it could be more packages for more the UI part.

[wladpaiva]

I don't know how MSW have been doing for you guys but for me it has made my tests freaking slow. Any request to the server is taking ~1.2 seconds... On those cases where I need to POST a form to a /reaally/long/route/like/this any of subsequents GETs take more than 2s where normally it takes 20ms.

We'll probably need a way to narrow down the route where the MSW we'll be listening.

[kentcdodds]

@wladiston that is unusual. My MSW handlers don't take much time at all. I would suggest trying to make a minimal reproduction (https://kcd.im/repro) and (if you can) reporting that to the MSW project.

[wladpaiva]

Just an FYI, while I was recreating the minimal reproduction env I stumbled in the real problem. The bottleneck was that I was compiling the msw typescript files via ts-node during runtime. Using esbuild-register made it faster but not faster enough. For now, I've just changed all mock files to JS.

[luanlucho]

Any progress on the testing lib?

[kentcdodds]

I've been on break. I'll update this issue when there are updates. No need to ask 😁

[kettanaito]

This sounds like a great plan. Let me know if I can be of any help.

[luistak]

I was thinking of an API suggestion for this test package in something like:

import type { LoaderFunction } from  'remix';
import { json } from 'remix';
import { render as customRender } from '@remix-run/tests';

import SomeRoute from '../routes/some-route';

it('should render <SomeRoute /> Accordingly', async () => {
  type MockedData = any;
  const customTestLoader: LoaderFunction = async ({ request }) => {
    // you could do something with the request

    const mockedData = faker.something();

    return json<MockedData>(mockedData);
  };

  const { rerender, remixUtils } = customRender(<SomeRoute />, { loader: customTestLoader });

  // Changing a loader value
  rerender(<SomeRoute />, { loader: otherCustomLoader })
  // Or
  remixUtils.reload(otherCustomLoader)
});

[kentcdodds]

Thanks for sharing @luistak! I'll give that consideration when I work on this more in the future (sorry, this was a high priority until I got into that accident 🥴)

[sergiodxa]

I was thinking of an API suggestion for this test package in something like:

import type { LoaderFunction } from  'remix';
import { json } from 'remix';
import { render as customRender } from '@remix-run/tests';

import SomeRoute from '../routes/some-route';

it('should render <SomeRoute /> Accordingly', async () => {
  type MockedData = any;
  const customTestLoader: LoaderFunction = async ({ request }) => {
    // you could do something with the request

    const mockedData = faker.something();

    return json<MockedData>(mockedData);
  };

  const { rerender, remixUtils } = customRender(<SomeRoute />, { loader: customTestLoader });

  // Changing a loader value
  rerender(<SomeRoute />, { loader: otherCustomLoader })
  // Or
  remixUtils.reload(otherCustomLoader)
});

This looks good, also would be cool to pass an action function so you can test when useActionData returns something.