When should we use Storyshots?

[matthew-dean]

Even though the Storyshots add-on exists, which allows you to import stories into Jest, it isn't what's documented on various blog posts around Storybook testing / integration with Jest, like: https://medium.com/storybookjs/testing-lib-storybook-react-8c36716fab86 and https://storybook.js.org/blog/interaction-testing-with-storybook/

We just implemented Storyshots after finding that add-on via Google searching, but now that we've discovered these other blog posts with completely separate approaches, we're wondering if we should switch.

Could someone explain when to use one vs. the other, and the trade-offs of each? And could this be documented?

[shilman]

Great question. We've recently introduced new testing mechanisms in Storybook and things are still in flux, but let me do my best to break things down. cc @yannbf

Storyshots was the original testing tool for Storybook. It was dead simple to set up and you got DOM snapshots for free for all your stories. Unfortunately, there were a bunch of things wrong with its architecture/implementation. Nevertheless it's been the only game in town for awhile so it's widely used.

Test runner is intended to be the primary "new way" to test stories. We just released the first version, so three is still some work to do to create a direct upgrade path from Storyshots. In the meantime, you can get smoke tests for all your stories, and also write interaction tests on top of stories when you need them.

testing-react is a secondary "new way" to test stories. It's really just a way to make stories more portable to re-use in tests, and it means that you can write whatever arbitrary setup & teardown code you want in whatever testing tool you choose. In some sense it's a more flexible escape hatch for the test runner.

I would recommend using the test runner. You should be able to get 80% of the value of Storyshots today. With any luck we'll release some enhancements to give you the other 20% (should you need it) in the next couple months. We'll also be documenting all this better as the picture takes shape. In the meantime @winkerVSbecks has recently updated the Testing handbook with the current best practices.

[winkerVSbecks]

The handbook update is still in progress (just the interaction testing chapter) but, this blog post covers the latest test runner approach https://storybook.js.org/blog/test-component-interactions-with-storybook/

[ChenReuven]

@shilman just to understand, how can I run the new test-runner for visual testing locally? is there any docs or article about that? sample code?

Thanks a lot

[winkerVSbecks]

There's a recipe here: https://github.com/storybookjs/test-runner#image-snapshot-recipe

[ChenReuven]

@winkerVSbecks @shilman @yannbf can i use playwright mechanism (toHaveScreenshot function or other) like you show in the image snapshot recipe?

I try to use it but without luck.

if yes, can you show me an example, please :)

Thanks a lot

[matthew-dean]

Ok, thanks for answering. One thing: with the way that the Test Runner is set up, it looks like Jest is run using test-storybook? How do you:

1. Write other unit tests and run both of them using Jest
2. Set up test coverage tests. For example, right now I have a jest.config.js file that has:

  testMatch: [
    '**/__tests__/*.+(ts|js)',
    '**/*.test.(ts|tsx|js)',
    '<rootDir>/storyshots/index.ts'
  ],

And then I just run Jest tests normally. But it's unclear how the Test Runner integrates with Jest config. How do you run Jest regular tests vs test coverage tests using test-storybook?

[matthew-dean]

Also, I set this up with the dependencies mentioned, like:

yarn add -D @storybook/testing-library @storybook/jest @storybook/addon-interactions jest @storybook/test-runner

...and then I made the pre-requisite changes to the Storybook config.

However, running test-storybook results in:

Error: Cannot find module '@storybook/core-common'

[shilman]

Although test-runner uses jest under the hood, we recommend that you run it separately from your other jest tests.

The rationale is that it that the test runner has its own custom configuration which we prefer to abstract away since (1) we want to be able to change it in the future, and (2) it can interact in complex ways with your project's jest config.

However, if you want to run all the tests at once it's certainly possible. You can run test-runner --eject and it will create a jest config that you can then merge into your own project config. More info

As for coverage, it's not implemented yet. It's on our roadmap though.

Finally, re: the error you've encountered, I haven't seen that before. Please file a separate issue, ideally with a reproduction, and we'd be happy to help you get it sorted.