Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Visually Testing React Components Using the Eyes Storybook SDK

DZone's Guide to

Visually Testing React Components Using the Eyes Storybook SDK

Learn how to use React Storybook to create a library of React's reusable components that you can browse visually, increasing its usability.

· DevOps Zone ·
Free Resource

Easily enforce open source policies in real time and reduce MTTRs from six weeks to six seconds with the Sonatype Nexus Platform. See for yourself - Free Vulnerability Scanner. 

React is, first and foremost, a library for creating reusable components. But until React Storybook came along, reusability of components between applications was very limited. While a library of common components could be created, it was very difficult to use, as there was no useful way of documenting it.

Yes, documenting the common components via a Readme file is possible, even useful. But a component is, in its essence, something visual. A Readme file just doesn’t cut it, neither for a developer and definitely not for a designer that wants to browse a library of shared components and choose the one that fits their purpose.

This limited the usefulness of React’s component reusability.

And then React Storybook came along. React Storybook has changed the way many companies approach React by allowing them to create a library of components that can be visually browsed so as to be able to pick and choose the component they want:

React Storybook

React Storybook.

Finally, a real library of shared components can be created and reused across the company. And examples abound, some of them open-source: from Airbnb's set of date components to Wix’s styled components.

But a library of widely used company-wide components brings its own set of problems: how does one maintain the set of components in a reliable way? Components that are internal to one application are easily maintained — they are part of the QA process of that application, whether manual or automated. But how does one change the code of a shared component library in a reliable manner? Any bug introduced into the library will immediately percolate to all the applications in the company. And in these agile days of continuous delivery, this bug will quickly reach production without anybody noticing.

Moreover, everyone in the company assumes that these shared components are religiously tested, but this is not always the matter. And even when they are tested, it is usually their functional aspect that is tested, while testing how they look is largely ignored.

Testing a Shared Library

So how does one go about writing tests for a library of shared components? Let’s look at one of the Shared Components libraries out there — Airbnb’s React Dates. I have forked it for the purpose of this article so that we can look at a specific version of that library, frozen in time.

Let’s git clone this fork:

$ git clone git@github.com:applitools/eyes-storybook-example.git
$ cd eyes-storybook-example

To run the storybook there, just run npm run storybook, and open your browser to http://localhost:6006.

To run the tests, run the following:

$ npm install
$ npm test

This runs the tests, which generate the following output:


Airbnb React Dates test output.

Wow! 750 tests. I have to say that this component library is very well tested. And how do I know that it is very well tested? It’s not just because there are a lot of tests, but also (and mainly!) because I randomly went into some source file, changed something, and ran the tests again.

Let’s try it. Change line 77 in file: src/components/CalendarDay.jsx to:

if (!onDayMouseEnter) onDayMouseEnter(day, e);

(I just added the if to the line). Now let’s run the tests again using npm test:

Tests failing due to a change in the code


Tests failing due to a change in the code.

Perfect! The tests failed, as they should. Really great engineering from the Airbnb team.

(if you’re following with your own repository, please undo the change you just made to the file.)

Functional Testing Cannot Catch Visual Problems

Let’s try again. Edit line 6 in the file src/svg/arrow-right.svg, by changing the first M694 to M94, thus:

Now let’s run the tests again using npm test:

Oops. They’re passing. We’ve changed the source code for the components, and yet the tests pass.

Why did this happen? Because we changed only the visual aspect of the components, without changing any of the functional aspects of it. And Airbnb does only functional testing.

(This is not to denigrate the wonderful engineers at Airbnb who have given us this wonderful library (and other open-source contributions). This library is tested in a way that should make Airbnb proud. And I am sure that manual testing of the components is done from time to time to ensure that the components are OK.)

If you’re following with your own repository, please undo the change you just made to the file.

Visual Testing of a Shared Library

So how does one go about testing the visual aspects of the components in a shared library? Well, if you’re using React Storybook, you’re in luck (and if you’re building a shared component library, you should be using React Storybook). You are already using React Storybook to visually display the components and all their variants, so testing them automatically is just a simple step (are you listening, Airbnb?).

We’ll be using Applitools Eyes, which is a suite of SDKs that enable Visual Testing inside a variety of frameworks. In this case, we’ll use the Applitools Eyes SDK For React Storybook (yes, I know, a big mouthful…)

(Full disclosure— I am a developer advocate and architect for Applitools. But I love the product, so I have no problem promoting it!)

To install the SDK in the project, run:

npm install eyes.storybook --save-dev

This will install the Eyes SDK for Storybook (locally for this project). If you’re following with your own repository, please undo the changes you made to the files; otherwise you will get failures. To run the test, just run:

./node_modules/.bin/eyes-storybook

You will get this error:

Yup. To use the Eyes SDK, you need an API Key, which you can get by registering at the Applitools site, here. Once you have that, log in and go to the Eyes admin tool, here. You will find the API using the following menu:

Getting the Applitools API Key


Getting the Applitools API Key.

To make Eyes Storybook use the API key, set the environment key APPLITOOLS_API_KEY to the key you have:

// Mac, Linux:
$ export APPLITOOLS_API_KEY=your-api-key
// Window
C:> set APPLITOOLS_API_KEY=your-api-key

Now run it again:

./node_modules/.bin/eyes-storybook

Eyes storybook will run Chrome headless, open your storybook, take a screenshot of all your components and variants, and send them to the Applitools service. When the test ends, as this is the first test, it will establish that these screenshots are the baseline against which all other tests will be checked against. You can check the results with the link it adds to the end of the tests, or just go to http://eyes.applitools.com:

Visual testing results

Visual testing results.

Failing the Test

So let’s test if the change we made to the SVG will fail the test. Re-edit line 6 in the file src/svg/arrow-right.svg, by changing the first M694 to M94, thus:

Now let’s run the test again using ./node_modules/.bin/eyes-storybook.

Success! Or rather, failure! The test recognized that some of the component screenshots differed from the baseline ones we created earlier. We can see the result of the diffs in the Applitools Eyes management UI:

Showing diffs of components in Storybook

Showing diffs of components in Storybook.

We can either select these changes as the new baseline (which in this case we don’t want to!) or fix the bug and run the test again, in which case it will be green.

And that is the beauty of Storybook. Because it enables you to create a central repository of components, it feeds three birds with one bird feed (I’m sorry, I can’t kill three birds, even if it is with one stone…):

  • Creating and documenting a shared React components library, with little effort.
  • Testing that the functionality of the components works (albeit with lots of effort).
  • Visually testing the components with literally zero code.

Summary

React Storybook is a game changer for frontend development— it enables the creation and maintenance of a shared component library for the whole company.

And the best thing about React Storybook is that if you’ve already invested the effort to set it up, you get a suite of tests that check the visual look of your components… for free!

Automate open source governance at scale across the entire software supply chain with the Nexus Platform. Learn more.

Topics:
visual testing ,storybook ,react storybook ,sdk ,software testing ,qa ,test automation ,devops

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}