Introduction
Storybook provides an environment where you can build components in isolation, and checking edge case UI states became easier with Storybook. What’s more, you can write tests in Storybook. Also, testing environment comes with zero configuration. Aren’t you excited? In this post, I will talk about what made me start testing in Storybook, how you can set up testing in Storybook, some issues I had with Storybook Addons.
Motivation to do testing in Storybook
jsdom in Jest cannot mock real DOM fully
React Testing Library has become a go-to option for testing React applications since you can write tests from a user perspective. Here is its core principle in their official docs.
The more your tests resemble the way your software is used, the more confidence they can give you.
So I tried Jest/React-Testing-Libary and was quite satisfied with these technologies. However, I got stuck when I tried to test Dialog element. It turns out there are some known limitations with jsdom. It was quite a frustrating experience I had.
Finding Alternatives
Another javascript-implemented DOM
happydom: It’s another javascript implementation of DOM. However, its community is way smaller than jsdom. The repository has 2.9k+ stars, so I can’t make sure that I would get a huge community support.
Using real DOM
real DOM: jsdom lets us see the result of component testing immediately in the local development environment whenever our codebase changes. That’s one of the important part of automated testing. Once we start using real DOM, it’s clear that the execution time of testing will be too slow.
Innovative Solution
When you develop in local development, you typically run yarn storybook and see the result. Since Storybook already renders stories(components) in real DOM, it can reuse the rendered components to run component testing. According to Storybook’s Benchmark, Storybook interaction testing is 30% slower than jest/react-testing-library and sometimes it is even faster. Internally, Storybook uses jest/playwright to run the tests.
In addition, it becomes easier to track down bugs since you can see the interaction flow visually in Storybook, rather than seeing the dumped HTML when the test fails. Debugging is made easier.
Storybook’s testing methods are similar to those of Jest/React-Testing-Library, so it was clear that I would get used to it easily.
How to set up
Test Runner
Install test runner.
Run the test-runner
Unit Testing
Interaction Testing
Add this to config of your ./storybook/main.ts
addons: [
‘@storybook/addon-interactions‘,
…,
],
}
Write an interaction test.
export const LoggedIn: Story = {
play: async ({ canvasElement }) => {
const canvas = within(canvasElement);
const loginButton = canvas.getByRole(“button“, { name: /Log in/i });
await expect(loginButton).toBeInTheDocument();
await userEvent.click(loginButton);
await expect(loginButton).not.toBeInTheDocument();
const logoutButton = canvas.getByRole(“button“, { name: /Log out/i });
await expect(logoutButton).toBeInTheDocument();
},
};
play: this function runs after the story finishes rendering.
click: Storybook lets you use user-events in the same way as Reac Testing Library.
expect: assertion function
Test Coverage
Test coverage shows any code lines that tests haven’t gone through.
Install the addon.
Include the addon in main.ts
addons: [
‘@storybook/addon-coverage‘,
…,
],
};
Run the test runner with –coverage option.
To Be Continued…
End-to-end Testing
API Mocking
Issues
Issues with Storybook Addon Coverage
Issues with Playwright
Limitations
References
How to know what to test
Setting test runner in Storybook
Unit testing in Storybook
Visual testing in Storybook
Interaction testing in Storybook
Test coverage in Storybook
End-to-end testing in Storybook
