This is the third article in a series of four about StoryBook and how it impacts developer workflow. You can read the previous ones.

Having a file where you explicitly combine props of your components and show the output is starting to feel a lot like a unit test, let’s see our Employees component example:

import React from ‘react’;
import { storiesOf } from ‘@kadira/storybook’;
import Employees from ‘../components/Employees’;

storiesOf(‘Employees’, module)
 .add(‘with empty list’, () => <Employees list={[]} />)
 .add(‘with one element’, () => <Employees list={[employee1]} />);
 .add(‘with one element and sortable’, () => <Employees list={[employee1]} sortable />);

This code is pretty similar to how we write unit tests, in fact, the only missing piece is that we are not expecting anything as a result of mounting the component, we just show it. Here is where StoryShots comes to play, but first some announcements from our sponsors.

Jest & snapshot testing

Hang in there with StoryShots, it’s great, but it will be much easier to grasp if you understand Jest and snapshot testing. Jest is a testing framework developed by Facebook, it’s already integrated with Create React App, works out of the box with React and enables snapshot testing.

The idea is simple. Jest stores the result of a component render in a file and every time we run a test it compares the previously stored output with the actual one. This testing is an effortless way to check UI components without writing time-consuming tests that more often than not break due to the nature of an evolving project.


This image shows a snapshot test failing because it expected the icon to be iconweb.png image and instead, it got icontxt.png. Jest was able to tell the difference since it stored a snapshot file containing the old value.

At this point, I can choose to update the snapshot making this new version the good one or fix the component if it's a real issue.


We are back, thanks for waiting there. Ok, where we left… oh right, we concluded that writing stories are similar to writing tests, but with a small caveat, there is no expected value to fail or succeed in our stories.

Thanks to snapshot testing that’s easy to fix. Since Jest stores and compares different render output versions and StoryBook is already rendering our components, we can use StoryShots to close the gap and make a snapshot of every story we have.

StoryShots does just that; it allows us to use the stories we created on StoryBook as tests by telling Jest to do a snapshot of each story saving us from writing UI tests by hand if we have a story for it.


Not going to dive deep into this, the website got you covered the only glitch I found is the need to change the .storybook/config.js File from ES6 module imports to CommonJS ones, since I was experiencing this issue. There is a merged PR that should have fixed it, but it didn’t in my case and changing the config.js wasn’t much of a deal for me, so I left it in CommonJS.

Running the tests

StoryShots works like any Jest test, running npm run test will also run your snapshot testing for all the StoryBook stories you have.

📷 Happy snapshot testing!