Improving support for Storybook and other test harnesses

[davidhousedev]

In our project, we make heavy use of Storybook and Chromatic for visual regression testing purposes. In an ideal world, we want to represent all pages in our application, along with their individual components within Storybook stories. This allows us to do component testing, basic interaction testing, and visual regression testing all as a part of our normal workflow.

When we've tried to get this working with Hydrogen, we've encountered challenges at the Hydrogen context provider layer. For example, <Link /> throws if it's not rendered within a <Router />. However, when we try to render a <Router /> within Storybook's preview.js function, we encounter a number of lower-level errors within the router. It is challenging to replicate the context provider state necessary to have Hydrogen framework components render without an error.

The only workaround we've thought of is to write a custom Vite plugin to rewrite usages of Hydrogen components with components that don't require context providers, e.g. <Link />. However, this is not ideal because some UI components will contain logic that is relevant to our visual regression tests, requiring that we mock out large parts of Hydrogen framework components.

I suspect this challenge will not be specific to Storybook. I suspect issues like this will crop up if someone wanted to do component snapshot testing on components that included e.g. Hydrogen's <Link />.

I might be missing something here! Please let me know if you have any questions 🙇🏻

[frehner]

Yeah, I think this is partially related to the task of making our components framework agnostic - if we were to make them agnostic, then it would lead to testing situations such as yours here being much simpler to do.

However, that probably wouldn't solve the problem for all components; in your case, the <Link/> component and its provider is likely to remain specific to Hydrogen, so in the end it will probably continue to rely on Hydrogen+Vite magic under the hood, which doesn't help your situation. It's hard to say whether this could be refactored to not do magic Vite replacements, or use SSR checks, etc.

If it can't be refactored to not use those checks, perhaps we need to document what steps a developer needs to take in order to mock out those things, or maybe we could even expose something like a @shopify/hydrogen/test entrypoint that you could use in testing situations to mock them out? Don't know, just spitballing here.

Any thoughts @blittle ?

[davidhousedev]

All this makes sense to me! I like the idea of e.g. import { Router, ShopifyProvider, CartProvider } from '@shopify/hydrogen/test'

[blittle]

It would be nice for these components to be more resilient in a test environment without bespoke test wrapper components. But that might be be difficult. I'll look into it.

[kcarra]

Adding additional context with this pr link Shopify/hydrogen#2127. Outlines use cases for these providers and a potential path moving forward

[kcarra]

Release@1.5.0 Introduces better support for storybook testing via test providers