Writing Storybook stories for your React components is insanely helpful when you are working on a team, documenting how components look and behave, or creating a open source library of components.

The only line we needed to add to turn our stories into tests (excluding that test-boot stuff 👀 )

When working on these stories, however, I found that when doing large rewrites, I’d often break the stories without knowing about it. Storybook by itself does not have any sort of test runner that ensures all of the stories work. This makes it difficult to ensure that when you, developers on your team, or other contributors make changes to your code, they don’t forget to update the stories.

In order to fix this, I looked into ways to turn my stories into tests that we could add to our test runner to ensure they still worked when developers made changes. What I found was Storyshots.

What is Storyshots?

Storyshots is a testing tool for generating snapshots of your Storybook stories. If you aren’t familiar with snapshot testing, it takes the a textual (object-like) snapshot of what your component looks like when it renders, and saves that as a file. When you re-run the test, it takes a new snapshot and compares it to the old one.

Snapshot testing does not take any visual snapshots like images, but instead uses a textual representation of what the React components and properties look like.

I currently use version 2 of Storyshots since it didn’t require that I use Jest and made it a lot simpler to integrate with my current CI runner. I won’t go into exactly how Storyshots work, you can read more about that at Kadira Voice. Instead I’d like to focus more into how I use Storyshots and my philosophy when using it.

Testing Through Snapshots

In my projects, Storyshots do not replace actual tests. In fact, I wouldn’t recommend snapshots for actually testing functionality at all.

When a snapshot test fails, all that means is that the output looked different than what was expected.

It doesn’t tell you what actual behavior failed or why. When working on a team, that is pretty important. If you are working on a component and you break a test, you want to be able to quickly diagnose the problem and fix it. When a story test fails, all you know is that a specific story does not look like it did before. Take this example from Snapshot Testing in React Storybook:

Image from Snapshot Testing in React Storybook

Notice that all you know is that the link button story failed and that some text was different. Is this because a specific behavior changes? Is that text static?

You’ll find that you’ll simply blindly update the snapshots when running Storyshot tests, simply because that’s not why they are useful. Storyshots are helpful when they make sure developers don’t break stories or introduce weird artifacts with the rendered output of their components. They only test that the story and component still work.

Use Storyshots and catch breaking changes to your stories.

Don’t try to test all of your behavior for your components in stories or snapshots. Instead, focus on adding Storyshots to your testing pipeline so that you can ensure your Storybook is up-to-date, bug free, and stable.