Storybook Interactions - a replacement for Jest DOM testing?

[jnahumphreys]

Hey,

I understand the roadmap for 6.5 will include a test runner within StoryBook, as mentioned in this QA.

Does the StoryBook team see the Interactions (play functions) as:

1. An Arrange-Act, to allow a story to present a UI in a given state (that previously required manual interaction of the story).
2. Or is the intention for the interactions to allow for a full Arrange-Act-Assert, whereby we could then assert that the component is rendering in an expected way after the interaction has run, thus removing the need for these tests within a Jest DOM / @testing-library/react environment.

Thanks again in advance.

[shilman]

Play functions are generic and you can use them to simulate user interactions, or to run full-blown tests. We already have assertions in the play function, and will be stabilizing, documenting, and releasing that in 6.5.

[jnahumphreys]

@shilman - Thanks for clarifying, 6.5 sounds great!

My component tests typically fall into two categories:

• 1: render the component and assert the initial render is as expected (e.g Accordion is collapsed, only renders accordion title with expand button).
• 2: interact with the component and assert that expected changes are updated in the DOM (e.g, Accordion expand button is clicked, accordion expands and renders accordion content)

As an observation:

• When running tests for scenario No.1 (that do not need any interactions), placing these non-interactive tests under the domain of "interactions" doesn't feel right, albeit only due to the naming of the tab in the UI. Perhaps for 6.5, a user could customise the Interactions tab label, for example to read "Tests", which would then semantically match the first example I've mentioned.

Thanks again for the reply and the efforts on the 6.4 release, it's really great and has huge potential!

[shilman]

Great feedback. It's an evolving direction for Storybook so I'm sure we'll all learn a lot along the way. 🙏

[acherkashin]

Hi guys,

I read the discussion but still don't understand. What is the rule of thumb, when should I use jest-tests and when storybook interactive tests?

I have some assumptions, but they may be wrong, so correct me if so.

1. interactive tests are run in real browser, so they are going to be slower than jest-test. So, we should use them only in special cases to not slow down the CI process.
2. We had to build a storybook to run tests, so again it will slow down tests running on the CI.
3. As interactive tests are run in real browser, we can use them to make assertions against element sizes, layouts, their position to each other and so on. It is a real advantage, as jest-tests use js-dom that has some limitations.
4. Interactive tests should be useful to write tests for cases that may be hard to debug: drag and drop, keyboard navigation.

[shilman]

@acherkashin For now we are recommending:

• Use the test runner in most cases
• Use Jest/JSDOM (or the tool of your choice)
  • If you prefer another testing mechanism
  • If there are certain kinds of setup/teardown that you can't achieve with the test runner

This is a complicated subject, and evolving, but let me try to spell out our rationale:

1. Jest/JSDOM has known limitations, as you point out. For us, recommending something that "just works" is better from a support standpoint.
2. @yannbf and I did a bunch of benchmarking as we were building out the test runner and found that in general the playwright tests took maybe 30% longer than the jest tests. However, in some cases the browser-based tests were actually faster. We didn't feel that the speed difference was worth the complexity of bifurcating tests.
3. It's true that you need to build your storybook, but (1) we are making that faster, and (2) we expect most CI runs to do that at some point anyway. Another constraint is that you need to install Playwright for the test runner, and I don't have an answer to that one.
4. Centering on the test runner allows us to focus our efforts. We think that over time we can make them faster than JSDOM. Although playwright+browser has more moving parts than Jest, browsers are also being constantly optimized.
5. We have a bunch of good stuff coming in the test runner, so building tests there will allow you to benefit from that as that lands.

That said, the test runner is meant to be a stylized, 80/20 way of writing tests. We're aware that everybody has their own preferences and constraints, so we are making our stories portable (e.g. via @storybook/testing-react):

• as an escape hatch so that you can always use whatever testing tools you prefer
• as a foundation for our users to innovate and potentially come up with approaches that are better than the test runner

Hope that helps!

[acherkashin]

@shilman So storybook team considers interactive tests as tests that can be used instead of jest tests. It is a standalone tool, not an addition to jest.

I think now it is much clearer, thank you for such an exhaustive answer 👍.

I would add a couple more cases when we need to use jest tests:

• We still need to use jest tests for not-component functionality, like utility functions or react hooks
• If we need to mock some functionality. I understand that storybook contains some mocking approaches, described here. But I'm not sure whether it is possible to mock some module for a single specific story and use the original implementation in another story (or another mocked implementation).

[shilman]

Yes, this is only for component testing. Not a substitute for e2e and other forms of unit testing.

As for mocking, we have various ways of mocking network requests and that's starting to get more mature. For mocking code, the story is still evolving.

Another area that's on our radar for the test runner is test coverage. Teams that rely on it heavily might prefer to stick to JSDOM testing for now.

[darvid7]

Hi! new to storybook/react/jest (love it so far!), quick question that I think is relevant to this thread.

Is there advice / guidance on when to use an interaction test and when to use a unit test w/ jest?

For example, i have MyComponent.tsx and a story for it which is the expected flow of a user e.g.

// File: MyComponent.stories.tsx

export const NormalFlow = Template.bind({});
NormalFlow.args = {
  ...
};
NormalFlow.play = {
...
};

If I want to test edge cases it looks like my options are

1. make a new story e.g. export const EdgeCaseFlow = Template.bind({});... and write a new interaction tests.

But this has the side effect of a seemingly similar looking story showing up in the storybook console e.g. http://localhost:6006/?path=/story/mycomponent--normalflow and http://localhost:6006/?path=/story/mycomponent--edgecaseflow will look similar but have different interaction tests.

This is a bit of a code smell to me.

2. write a unit test with jest that expects things happen in the edge case flow in a new file e.g. MyComponent.test.tsx

which made me question why I would want to use an interaction test in the first place if I can test that component in a unit test.

I saw the rationale on the docs was interaction tests allow you to test in a real browser rather than JSDOM.

Given this and interaction tests take longer, I thought a reasonable approach would be:

• expected user flows should have an interaction tests
• test edge cases in another file w/ jest

But that seems to not align with the strategy of "keep stories and tests together in one file than having them spread across files."

Would really appreciate thoughts here 🧠!

Thanks in advance