Component testing in Storybook

“Writing your component UI tests in Jest can feel a little like stabbing at your components with a blindfold on.”- Michael Chan

This nails it. I used to think my stumbling over testing design system component libraries was a personal deficiency, but I’ve come to realize it was largely due to a number of reasons:

• The “feeling around in the dark” nature of prior testing setups, which Michael elegantly describes in the video
• Categories of testing that are largely irrelevant to testing UI components
• Weird, unnecessary duplication of effort to write stories and write tests for a component

I’ve been absolutely loving all the focus, improvements, and integrations the Storybook team has made regarding testing over the last couple years. In our client work, we’re increasingly recommending our teams lean into Storybook’s testing capabilities rather than trying to stand up bespoke testing setups. By leaning into Storybook’s capabilities, teams take care of a ton of stuff just by way of writing solid stories:

• Visualize the component in Storybook, which unlocks design review, visual regression testing, prototyping and more
• Automatic prop tables and code snippets
• Live component manipulation (e.g. toggle disabled and see the result)
• Unit tests and interaction tests

And it’s worth noting that working with the grain of Storybook positions the library to capitalize on any future features or improvements to the tool.

At the end of the day, a design system’s component library should deliver high-quality, predictable components that do what they say they do on the tin. Any tests associated with a design system should work towards achieving those outcomes.