Depends what you are testing for. When testing your React components, Jest and snapshot testing are perfectly fine. You do not need to test these in the app provider context and if you do, you can always mock the provider. When testing app state you definitely want to use mocks. This does depend on your React app architecture, but I'll assume you aren't building stateful components and the state is mutated via React context, Redux, MobX or whichever you prefer. Much of the state may of course depend on data sources such as the GraphQL API - again, mocks! That is one of the foremost advantages of GraphQL in that it lends itself so nicely to mocking. No need to touch real endpoints ever as long as you have the latest schema and are aware of some snags. Same goes for REST API though that will require hand-crafted mocks for lack of any API spec such as OAS, RAML et al. If you have your state mutators, say reducers, further abstracted to use a service layer, then I'd test the service layer (which does the actual API calls) using Jest or Ava (I prefer Ava for that, but it really is just a matter of preference which varies greatly among us JS hipsters). And again, you distinguish between unit tests and integration tests. I mostly write unit tests with a lot of mocking simply because running proper integration tests against Shopify APIs is nigh to impossible due to the fact you cannot remotely set most of the store settings that will affect behaviour. Major PITA! Finally we arrive at e2e tests where you can take advantage of test runners such as Cypress. Again, I would avoid doing these integration tests against a real installed instance of your app. It is more likely you will want these e2e tests to be run upon each PR merge to trunk. Once you do tag a release and initiate deployment (which in itself is a terrible automation experience on Shopify for apps) you would run the same e2e tests on your dev store with your app. Runners such as Cypress will allow you to login to your dev store but it is another PITA setting all that up and I've had transient issues where it would fail (hello too many logins and Captcha) so you must factor those nu(is)ances in. Now as for the classical node + React: why do they run on separate ports? I understand that your express server may be on one port and your webpack dev server (or whatever you're using) might be on another, but do take note of "dev server" so this is really only for local dev IMO and even there it's not really a smart choice other than being a quick and dirty convenience approach. If you still insist on that, setup a reverse proxy on your express. What I prefer and what I do is have a static middleware to serve my build destination folder - so while I can serve my React UI with a dev server if need be, I typically just have my build pipeline transpile to the dest, and with static middleware and HMR setup serve it via koa (another preference of mine and one you might also wish to look in to as Shopify are also moving away from express judging by their more recent github projects and activity). Hope some of this made sense :)
... View more