No Storybook tutorial would be complete without testing. Testing is essential to creating high quality UIs. In modular systems, miniscule tweaks can result in major regressions. So far we encountered three types of tests:
Unfortunately, the aforementioned testing methods alone aren’t enough to prevent UI bugs. UIs are tricky to test because design is subjective and nuanced. Visual tests are too manual, snapshot tests trigger too many false positives when used for UI, and pixel-level unit tests are poor value. A complete Storybook testing strategy also includes visual regression tests.
Visual regression tests are designed to catch changes in appearance. They work by capturing screenshots of every story and comparing them commit-to-commit to surface changes. This is perfect for verifying graphical elements like layout, color, size, and contrast.
Storybook is a fantastic tool for visual regression testing because every story is essentially a test specification. Each time we write or update a story we get a spec for free!
There are a number of tools for visual regression testing. For professional teams we recommend Chromatic, an addon made by Storybook maintainers that runs tests in the cloud.
Chromatic is a hassle-free Storybook addon for visual regression testing and review in the cloud. Since it’s a paid service (with a free trial), it may not be for everyone. However, Chromatic is an instructive example of a production visual testing workflow that we'll try out for free. Let’s have a look.
Create React App has created a git repo for your project; let's check in the changes we have made:
$ git add -A
Now commit the files.
$ git commit -m "taskbox UI"
Add the package as a dependency.
yarn add storybook-chromatic
Then login to Chromatic with your GitHub account (Chromatic only asks for lightweight permissions). Create a project with name "taskbox" and copy your unique
Run the test command in the command line to setup visual regression tests for Storybook. Don't forget to add your unique app code in place of
npx chromatic --app-code=<app-code>
--do-not-startis an option that tells Chromatic not to start Storybook. Use this if you already have Storybook running. If not omit
Once the first test is complete, we have test baselines for each story. In other words, screenshots of each story known to be “good”. Future changes to those stories will be compared to the baselines.
Visual regression testing relies on comparing images of the new rendered UI code to the baseline images. If a UI change is caught you get notified. See how it works by tweaking the background of the
This yields a new background color for the item.
Use the test command from earlier to run another Chromatic test.
npx chromatic --app-code=<app-code>
Follow the link to the web UI where you’ll see changes.
There are a lot of changes! The component hierarchy where
Task is a child of
Inbox means one small tweak snowballs into major regressions. This circumstance is precisely why developers need visual regression testing in addition to other testing methods.
Visual regression testing ensures components don’t change by accident. But it’s still up to you to determine whether changes are intentional or not.
If a change is intentional you need to update the baseline so that future tests are compared to the latest version of the story. If a change is unintentional it needs to be fixed.
Since modern apps are constructed from components, it’s important that we test at the level of component. Doing so helps us pinpoint the root cause of a change, the component, instead of reacting to symptoms of a change, the screens and composite components.
When we’ve finished reviewing we’re ready to merge UI changes with confidence --knowing that updates won’t accidentally introduce bugs. If you like the new
red background then accept the changes, if not revert to the previous state.
Storybook helps you build components; testing helps you maintain them. The four types of UI testing are covered in this tutorial are visual, snapshot, unit, and visual regression testing. You can automate the last three by adding them to your CI script. This helps you ship components without worrying about stowaway bugs. The whole workflow is illustrated below.