How to Automate Storybook Testing With Test Runner

Let's use the Storybook test runner to automate our tests!

Project Source Code

Get the project source code below, and follow along with the lesson material.

Download Project Source Code

To set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.

This lesson preview is part of the Storybook for React Apps course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.

This video is available to students only
Unlock This Course

Get unlimited access to Storybook for React Apps, plus 70+ \newline books, guides and courses with the \newline Pro subscription.

Thumbnail for the \newline course Storybook for React Apps
  • [00:00 - 00:17] In order to avoid having to manually check every story and their interactions after every change that we make, Storybook provides a test runner which turns every single story into tests. And the features are every story that does not have play functions will just be smoke tested, so if it renders correctly then the test will pass.

    [00:18 - 00:29] And for the stories that contain with play function, the test runner will execute the play function and check whether the assertion is working correctly. And all of the tests they run in parallel in a headless browser, which means that you're running tests against a real browser.

    [00:30 - 00:40] And because it uses just and playwright, you get both the power and flexibility from just as well as playwright. And that means that you can run tests in parallel, you can reuse watch mode, and you can even do cross browser testing if you want it.

    [00:41 - 00:46] So let's go ahead and add it to our project. The first thing we have to do is essentially just to install it.

    [00:47 - 00:51] So we just copy this here. So yarn add Storybook test runner as a dev dependency.

    [00:52 - 01:02] So we go here, we kill storybook because we need to install new dependencies and we just install it. And once we're done, the test runner actually needs storybook to be running.

    [01:03 - 01:09] So let's just run storybook. And this time let's pass a flag -ci so that storybook doesn't open a browser once it's ready.

    [01:10 - 01:21] And once storybook is running, we open a new instance of the terminal and then we essentially just need to run yarn test - storybook. And that's going to execute the binary that comes from the library.

    [01:22 - 01:30] So just by doing this, it's enough for this test runner to visit every single one of our stories and check whether they're passing or not. In this case, we see that everything is passing.

    [01:31 - 01:43] And because the test runner is based on just, we can run yarn test storybook - watch to check only for the changes that we are making. So for example, let's just force a failure in one of the tests that we have.

    [01:44 - 01:55] So let's open the restaurant card and then change this to to have been called. Because we're running in watch mode, as you can see, there's only one test running which is really nice in performance.

    [01:56 - 02:11] And then over here, we're going to get the feedback from the restaurant card in the closed story which is failing. And not only we get the feedback from the CLI which is the original test error, but also we get this link which if you click, you can debug directly in the browser with the other interactions panel open.

    [02:12 - 02:21] So basically we get the nice experience from the CLI, but also connecting to a headed experience to the browser. So basically we can just fix our interaction and then the tests are passing in.

    [02:22 - 02:26] And that's pretty much it. You see how simple it is now to test every single one of our stories.

    [02:27 - 02:38] And now we can be pretty much confident that every change that we make as long as the components are part of a story, then they will be running correctly. So for instance, if we ever update any library that ends up breaking a component, the test runner is going to tell us.

    [02:39 - 02:51] If we change the API of a component but forgot to update in storybook, the test runner is going to tell us. If a bug is introduced in the restaurant detail page and the model doesn't open anymore for some reason, because of the story that we created in the previous lesson, the test runner is going to tell us.

    [02:52 - 02:58] And you can do so much more with the test runner and you can get more information about the documentation over here. There are a bunch of CLI options.

    [02:59 - 03:08] You can configure as much as you like and there are different modes and you can also run this in CI if you want it. Additionally, you can also run your tests against Chrome, Firefox, Safari and Edge.

    [03:09 - 03:14] And that's it. With the combination from the interactions and the test runner, you don't really need to write tests for your component in node anymore.

    [03:15 - 03:28] You can just get this full experience in storybook and playwright. And the test runner has experimental test hooks that we can execute anything that we wanted, such as snapshot tests or accessibility tests, which we'll be talking about in the next lesson.

    [03:29 - 03:29] I'll see you then.