What gap does @remix-run/testing fill in that msw & @playwrightweb can't fulfill for my Remix app's testing needs?

[cliffordfajardo]

Background Context
Currently in my team's Remix app we are using msw & @playwrightweb to do unit, integration & E2E tests.

Question
What gap does @remix-run/testing fill in that msw & @playwrightweb can't fulfill for my Remix app's testing needs?

I have a tiny runnable Remix app example in this Github Repo showing our setup:
https://github.com/cliffordfajardo/remix-msw-node-with-playwright:

msw-nodejs-example.mp4

References

• MSW/Playwright example repo: https://github.com/cliffordfajardo/remix-msw-node-with-playwright
• Twitter Thread: https://twitter.com/cliffordfajard0/status/1634267245768749057
• Discord Thread: https://discord.com/channels/770287896669978684/770287896669978687/1084455847918317658

[cliffordfajardo]

Responses from community:

Kent:

If you want to test a component in isolation from the full remix app then that's where remix-run/testing comes in very handy. Also, storybook

James:

When using Playwright for e2e tests you won't need @remix-run/testing since Playwright will be running in the full Remix context e.g. code is wrapped in <RemixBrowser />.

In unit tests using just vitest you might be testing individual forms or components that rely on Remix hooks and route data but since they aren't wrapped in <RemixBrowser /> then @remix-run/testing is useful to setup that context.

The advantage of using vitest and @remix-run/testing is that you can very quickly test individual components rendering and behaviour without a full browser instance. So I generally use unit tests for 90% of our UI testing and then Playwright for integration testing entire flows at a higher level since jsdom in unit tests can't do page transitions/navigations.

Both our vitest and Playwright tests use the same msw mocks though which is nice.