Add (full) support for Client Data to @remix-run/testing

[silvenon]

I don't see unit testing being mentioned as part of Client Data conversation. I noticed that it's possible to add HydrateFallback, but not clientLoader or clientAction, so I'm a bit confused. Could the team fill in the gaps here, please, and make it possible to test Client Data with @remix-run/testing?

[ondrejsevcik]

We're running into the same issue during our migration from ReactRouter.

[MattyBalaam]

Doesn’t make sense to me - I want to test the associated logic in my clientLoader or clientAction while developing and don’t see how spinning up an e2e is useful.

[silvenon]

I also think it's inconvenient, I don't think that not supporting this was an active decision, it's likely a significant amount of work, but I'm with you that extending the area of unit testing is in everyone's best interest.

[sergiodxa]

The loader function in createRemixStub is there to help you test your component inside the Remix context, so things like Form, Link, useNavigation, useLocation, etc. work

It's not intended to test your loaders or client loaders, the loader function it receive for the route it only accepted to let you stub the loader data, since useLoaderData is shared for the client and server loaders you don't have to think about client or server when testing a component.

They recommend E2E if you want to test how the client loader, the component and probably the server loader behave all together, if you only want to test your client loader you can call it as a normal function.

test("the client loader returns true", async () => {
  let request = new Request(url) // Add a valid URL and headers here
  let params = {} // Add route params here

  let response = await clientLoader({ request, params })

  // assert the response
});

And if you move your actual logic to outside the loader/clientLoader you can simplify testing it even more, and leave the client and server loaders as mere points of coordination of your logic, validations, and format functions.

[MattyBalaam]

Personally I see a lot of value in having isolated tests for a route, rather than a full e2e tests - I want to test the integration between the moving parts.

[silvenon]

if you only want to test your client loader you can call it as a normal function

It would be nice if tests don't have to worry about this more than passing clientLoader to the stub. It would be convenient if loader data just ended up with joint data.

Although I see the other side of that coin as well, like having to pass all that stuff anyway is inevitably letting the test know about the client data, the "detail" that I wanted to hide altogether, also the potential complexities of accurate implementation, but I still think it would be worth it, without it the testing story feels unfinished.

Also, I haven't quite mastered performant E2E testing in CI, just my blog test suite takes almost 2m, I'd prefer to do as much as I can in unit tests.