@storybook/addon-storyshots

StoryShots

Note This addon is now deprecated, will not receive any further updates, and will be discontinued in a future release. If you're using this addon, we recommend migrating to one of the available options outlined in the Storyshots migration guide.

StoryShots adds automatic Jest Snapshot Testing for Storybook.

Framework Support

To use StoryShots, you must use your existing Storybook stories as the input for Jest Snapshot Testing.

Getting Started

Add the following module into your app.

yarn add @storybook/addon-storyshots --dev

Configure Storyshots for HTML snapshots

Create a new test file with the name Storyshots.test.js. (Or whatever the name you prefer, as long as it matches Jest's config testMatch). Then add following content to it:

import initStoryshots from '@storybook/addon-storyshots';

initStoryshots();

That's all.

Now run your Jest test command. (Usually, npm test.) Then you can see all of your stories are converted as Jest snapshot tests.

Testing stories that rely on addon-added decorators

If you have stories in your Storybook that can only render inside a decorator (for instance the apollo-storybook-decorator), you'll need to ensure those decorators are applied in Storyshots.

If you export those decorators from your .storybook/preview.js then Storyshots will apply those decorators for you in the same way that Storybook does. However if the addon automatically adds the decorator for you (which is a new feature in Storybook 6.0), you will find the decorator does not get added in Storyshots. This is a limitation in Storyshots currently.

To ensure such decorators get added, export them from .storybook/preview.js:

import addonDecorator from 'some-addon';

export const decorators = [addonDecorator];

Configure your app for Jest

In many cases, for example Create React App, it's already configured for Jest. You need to create a filename with the extension .test.js.

If you still need to configure jest you can use the resources mentioned below:

• Getting Started - Jest Official Documentation
• Javascript Testing with Jest - Egghead. paid content

Note: If you use React 16, you'll need to follow these additional instructions.

Note: Make sure you have added the json extension to moduleFileExtensions in jest.config.json. If this is missing it leads to the following error: Cannot find module 'spdx-license-ids' from 'scan.js'.

Note: Please make sure you are using jsdom as the testEnvironment on your jest config file.

Configure Jest to work with Webpack's require.context()

NOTE: if you are using Storybook 5.3's main.js to list story files, this is no longer needed.

Sometimes it's useful to configure Storybook with Webpack's require.context feature. You could be loading stories one of two ways.

1. If you're using the storiesOf API, you can integrate it this way:

import { configure } from '@storybook/react';

const req = require.context('../stories', true, /\.stories\.js$/); // <- import all the stories at once

function loadStories() {
  req.keys().forEach((filename) => req(filename));
}

configure(loadStories, module);

1. If you're using Component Story Format (CSF), you'll integrate it like so:

import { configure } from '@storybook/react';

const req = require.context('../stories', true, /\.stories\.js$/); // <- import all the stories at once

configure(req, module);

The problem here is that it will work only during the build with webpack, other tools may lack this feature. Since Storyshot is running under Jest, we need to polyfill this functionality to work with Jest. The easiest way is to integrate it to babel.

You can do this with a Babel plugin or macro. If you're using create-react-app (v2 or above), use the macro.

Option 1: Plugin

First, install it:

yarn add babel-plugin-require-context-hook --dev

Next, it needs to be registered and loaded before each test. To register it, create a file with the following register function .jest/register-context.js:

import registerRequireContextHook from 'babel-plugin-require-context-hook/register';
registerRequireContextHook();

That file needs to be added as a setup file for Jest. To do that, add (or create) a property in Jest's config called setupFiles. Add the file name and path to this array.

setupFiles: ['<rootDir>/.jest/register-context.js']

Finally, add the plugin to .babelrc:

{
  "presets": ["..."],
  "plugins": ["..."],
  "env": {
    "test": {
      "plugins": ["require-context-hook"]
    }
  }
}

The plugin is only added to the test environment otherwise it could replace webpack's version of it.

Option 2: Macro

First, install it:

yarn add require-context.macro --dev

Now, inside of your Storybook config file, import the macro and run it in place of require.context, like so:

import requireContext from 'require-context.macro';

// const req = require.context('../stories', true, /\.stories\.js$/); <-- replaced
const req = requireContext('../stories', true, /\.stories\.js$/);

Configure Jest for React

StoryShots addon for React is dependent on react-test-renderer, but doesn't install it, so you need to install it separately.

yarn add react-test-renderer --dev

Configure Jest for Angular

StoryShots addon for Angular is dependent on jest-preset-angular, but doesn't install it, so you need to install it separately.

yarn add jest-preset-angular

If you already use Jest for testing your angular app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

module.exports = {
  globals: {
    __TRANSFORM_HTML__: true,
  },
  transform: {
    '^.+\\.jsx?
Configure Jest for Vue
StoryShots addon for Vue is dependent on jest-vue-preprocessor, but
doesn't install it, so you need to install it separately.
yarn add jest-vue-preprocessor
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
module.exports = {
  transform: {
    '^.+\\.jsx?
Configure Jest for Vue 3
StoryShots addon for Vue is dependent on vue-jest v5, but
doesn't install it, so you need to install it separately.
yarn add vue-jest@5.0.0-alpha.8
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
module.exports = {
  transform: {
    '^.+\\.jsx?
Configure Jest for Preact
StoryShots addon for Preact is dependent on preact-render-to-string, but
doesn't install it, so you need to install it separately.
yarn add preact-render-to-string --dev
Configure Jest for Web Components
StoryShots addon for Web Components requires jsdom 16 or later to fully support the
web component shadow dom. To use jsdom 16 or later you can set the Jest testEnvironment configuration key to
jest-environment-jsdom-sixteen. This should work back to Jest 24 and is the default in Jest 26 and later.
Configure Jest for MDX Docs Add-On Stories
If using the Docs add-on with
MDX stories you will need
to configure Jest to transform MDX stories into something Storyshots can understand:
Add the following to your Jest configuration:
{
  "transform": {
    "^.+\\.[tj]sx?$": "babel-jest",
    "^.+\\.mdx?$": "@storybook/addon-docs/jest-transform-mdx"
  }
}
Why don't we install dependencies of each framework ?
Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.
dependencies - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).
optionalDependencies - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.
peerDependencies - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.
optionalPeerDependencies - unfortunately there is nothing like this =(
For more information read npm docs
Using createNodeMock to mock refs
react-test-renderer doesn't provide refs for rendered components. By
default, it returns null when the refs are referenced. In order to mock
out elements that rely on refs, you will have to use the
createNodeMock option added to React starting with version 15.4.0.
Here is an example of how to specify the createNodeMock option in Storyshots:
import initStoryshots, { snapshotWithOptions } from '@storybook/addon-storyshots';
import TextareaThatUsesRefs from '../component/TextareaThatUsesRefs';

initStoryshots({
  test: snapshotWithOptions({
    createNodeMock: (element) => {
      if (element.type === TextareaThatUsesRefs) {
        return document.createElement('textarea');
      }
    },
  }),
});
Provide a function to have story-specific options:
initStoryshots({
  test: snapshotWithOptions((story) => ({
    createNodeMock: (element) => {
      if (story.name == 'foobar') {
        return null;
      }
      return element;
    },
  })),
});
Using a custom renderer
By design, react-test-renderer doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as mount from Enzyme or render from React Testing Library.
Example with React Testing Library
import initStoryshots from '@storybook/addon-storyshots';
import { render } from '@testing-library/react';

const reactTestingLibrarySerializer = {
  print: (val, serialize, indent) => serialize(val.container.firstChild),
  test: (val) => val && val.hasOwnProperty('container'),
};

initStoryshots({
  renderer: render,
  snapshotSerializers: [reactTestingLibrarySerializer],
});
Example with Enzyme
import initStoryshots from '@storybook/addon-storyshots';
import { mount } from 'enzyme';

initStoryshots({
  renderer: mount,
});
If you are using enzyme, you need to make sure jest knows how to serialize rendered components.
For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the snapshotSerializer option (see below).
StoryShots for async rendered components
You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to initStoryshots(...) when the asyncJest option is given as true.
Example
The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of getSnapshotFileName.
Add stories of UserForm in the file: UserForm.story.jsx
/* global module */
import React from 'react';
import { QueryRenderer } from 'react-relay';
import { storiesOf } from '@storybook/react';

// Use the same queries used in YOUR app routes
import { newUserFormQuery, editUserFormQuery } from 'app/routes';
import UserFormContainer from 'app/users/UserForm';

// YOUR function to generate a Relay Environment mock.
// See https://github.com/1stdibs/relay-mock-network-layer for more info
import getEnvironment from 'test/support/relay-environment-mock';

// User test data YOU generated for your tests
import { user } from 'test/support/data/index';

// Use this function to return a new Environment for each story
const Environment = () =>
  getEnvironment({
    mocks: {
      Node: () => ({ __typename: 'User' }),
      User: () => user,
    },
  });

/**

  NOTICE that the QueryRenderer render its children via its render props.

  If we don't take the StoryShot async then we will only see the QueryRenderer in the StoryShot.

  The following QueryRenderer returns null in the first render (it can be a loading indicator instead in real file) and then when it gets the data to respond to query, it renders again with props containing the data for the Component
 */
const renderStory = (query, environment, variables = {}) => (
  <QueryRenderer
    environment={environment}
    query={query}
    variables={variables}
    render={({ props, error }) => {
      if (error) {
        console.error(error);
      } else if (props) {
        return <UserFormContainer {...props} />;
      }
      return null;
    }}
  />
);

storiesOf('users/UserForm', module)
  .add('New User', () => {
    const environment = new Environment();
    return renderStory(newUserFormQuery, environment);
  })
  .add('Editing User', () => {
    const environment = new Environment();
    return renderStory(editUserFormQuery, environment, { id: user.id });
  });
Then, init Storyshots for async component in the file: StoryShots.test.js
import initStoryshots, { Stories2SnapsConverter } from '@storybook/addon-storyshots';
import { mount } from 'enzyme';
import toJson from 'enzyme-to-json';

// Runner
initStoryshots({
  asyncJest: true, // this is the option that activates the async behaviour
  test: ({
    story,
    context,
    done, // --> callback passed to test method when asyncJest option is true
  }) => {
    const converter = new Stories2SnapsConverter();
    const snapshotFilename = converter.getSnapshotFileName(context);
    const storyElement = story.render();

    // mount the story
    const tree = mount(storyElement);

    // wait until the mount is updated, in our app mostly by Relay
    // but maybe something else updating the state of the component
    // somewhere
    const waitTime = 1;
    setTimeout(() => {
      if (snapshotFilename) {
        expect(toJson(tree.update())).toMatchSpecificSnapshot(snapshotFilename);
      }

      done();
    }, waitTime);
  },
  // other options here
});
NOTICE that When using the asyncJest: true option, you also must specify a test method that calls the done() callback.
This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.
Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.
Using a custom directory
Depending on your project's needs, you can configure the @storybook/addon-storyshots to use a custom directory for the snapshots. You can read more about it in the official docs.
Options
config
The config parameter must be a function that helps to configure storybook like the preview.js does.
If it's not specified, storyshots will try to use configPath parameter.
import initStoryshots from '@storybook/addon-storyshots';

initStoryshots({
  config: ({ configure }) =>
    configure(() => {
      require('../stories/Button.story.js');
    }, module),
});
configPath
By default, Storyshots assumes the config directory path for your project as below:

Storybook for React: .storybook
Storybook for React Native: storybook

If you are using a different config directory path, you could change it like this:
import initStoryshots from '@storybook/addon-storyshots';

initStoryshots({
  configPath: '.my-storybook-config-dir',
});
Or, as a more complex example, if we have a package in our lerna project called app with the path ./packages/app/src/__tests__/storyshots.js and the storybook config directory ./packages/app/.storybook:
import path from 'path';
import initStoryshots from '@storybook/addon-storyshots';

initStoryshots({ configPath: path.resolve(__dirname, '../../.storybook') });
configPath can also specify path to the preview.js itself. In this case, config directory will be
a base directory of the configPath. It may be useful when the preview.js for test should differ from the
original one. It also may be useful for separating tests to different test configs:
initStoryshots({
  configPath: '.my-storybook-config-dir/testConfig1.js',
});

initStoryshots({
  configPath: '.my-storybook-config-dir/testConfig2.js',
});
suite
By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:
import initStoryshots from '@storybook/addon-storyshots';

initStoryshots({
  suite: 'MyStoryshots',
});
storyKindRegex
If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:
import initStoryshots from '@storybook/addon-storyshots';

initStoryshots({
  storyKindRegex: /^MyComponent$/,
});
This can be useful if you want to separate the snapshots in directories next to each component. See an example here.
If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as DontTest
import initStoryshots from '@storybook/addon-storyshots';

initStoryshots({
  storyKindRegex: /^((?!.*?DontTest).)*$/,
});
This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing
while using react-test-renderer see here
storyNameRegex
If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:
import initStoryshots from '@storybook/addon-storyshots';

initStoryshots({
  storyNameRegex: /buttons/,
});
framework
If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass "react" or "react-native" to short-circuit this.
For example:
// storybook.test.js

import path from 'path';
import initStoryshots from '@storybook/addon-storyshots';

initStoryshots({
  framework: 'react', // Manually specify the project's framework
  configPath: path.join(__dirname, '.storybook'),
  integrityOptions: { cwd: path.join(__dirname, 'src', 'stories') },
  // Other configurations
});
Use this table as a reference for manually specifying the framework.



angular
html
preact



react
react-native
vue3


svelte
vue
web-components


test
Run a custom test function for each story, rather than the default (a vanilla snapshot test).
Setting test will take precedence over the renderer option.
You can still overwrite what renderer is used for the test function:
import initStoryshots, { renderWithOptions } from '@storybook/addon-storyshots';
import { mount } from 'enzyme';

initStoryshots({
  test: renderWithOptions({
    renderer: mount,
  }),
});
renderer
Pass a custom renderer (such as enzymes mount) to record snapshots.
This may be necessary if you want to use React features that are not supported by the default test renderer,
such as ref or Portals.
Note that setting test overrides renderer.
snapshotSerializers
Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).
import initStoryshots from '@storybook/addon-storyshots';
import { createSerializer } from 'enzyme-to-json';

initStoryshots({
  renderer: mount,
  snapshotSerializers: [createSerializer()],
});
This option needs to be set if either:

the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
serializers not specified in your jest config should be used when snapshotting stories.

serializer (deprecated)
Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.
import initStoryshots from '@storybook/addon-storyshots';
import toJSON from 'enzyme-to-json';

initStoryshots({
  renderer: mount,
  serializer: toJSON,
});
This option only needs to be set if the default snapshotSerializers is not set in your jest config.
stories2snapsConverter
This parameter should be an instance of the Stories2SnapsConverter (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.
By default, the instance of this class is created with these default options:
{
  snapshotsDirName: '__snapshots__',
  snapshotExtension: '.storyshot',
  storiesExtensions: ['.js', '.jsx', '.ts', '.tsx'],
}
This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:
import initStoryshots, { Stories2SnapsConverter } from '@storybook/addon-storyshots';

initStoryshots({
  stories2snapsConverter: new Stories2SnapsConverter({
    snapshotExtension: '.storypuke',
    storiesExtensions: ['.foo'],
  }),
});
Exports
Apart from the default export (initStoryshots), Storyshots also exports some named test functions (see the test option above):
snapshot
The default, render the story as normal and take a Jest snapshot.
renderOnly
Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your
components to ensure they do not error.
snapshotWithOptions(options)
Like the default, but allows you to specify a set of options for the test renderer. See for example here.
renderWithOptions(options)
Like the default, but allows you to specify a set of options for the renderer, just like snapshotWithOptions.
multiSnapshotWithOptions(options)
Like snapshotWithOptions, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object.
If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:
// jest.config.js
export default {
  transform: {
    '^.+\\.stories\\.jsx?
integrityOptions
This option is useful when running test with multiSnapshotWithOptions(options) in order to track snapshots are matching the stories. (disabled by default).
The value is a settings to a glob object, that searches for the snapshot files.
initStoryshots({
  integrityOptions: { cwd: __dirname }, // it will start searching from the current directory
  test: multiSnapshotWithOptions(),
});
shallowSnapshot
Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a renderer option.
Stories2SnapsConverter
This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.
Example:
Let's say we wanted to create a test function for shallow && multi-file snapshots:
import initStoryshots, { Stories2SnapsConverter } from '@storybook/addon-storyshots';
import { shallow } from 'enzyme';
import toJson from 'enzyme-to-json';

const converter = new Stories2SnapsConverter();

initStoryshots({
  test: ({ story, context }) => {
    const snapshotFileName = converter.getSnapshotFileName(context);
    const storyElement = story.render();
    const shallowTree = shallow(storyElement);

    if (snapshotFileName) {
      expect(toJson(shallowTree)).toMatchSpecificSnapshot(snapshotFileName);
    }
  },
});
asyncJest
Enables Jest done() callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.
Story Parameters
disable
Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of storyshots: {disable: true}. There is also a shorthand for this, storyshots: false.
export const Exception = () => {
  throw new Error('storyFn threw an error! WHOOPS');
};
Exception.storyName = 'story throws exception';
Exception.parameters = {
  storyshots: { disable: true },
};
: 'babel-jest',
    '^.+\\.(ts|html)
Configure Jest for Vue
StoryShots addon for Vue is dependent on jest-vue-preprocessor, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_14__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_15__
Configure Jest for Vue 3
StoryShots addon for Vue is dependent on vue-jest v5, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_16__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_17__
Configure Jest for Preact
StoryShots addon for Preact is dependent on preact-render-to-string, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_18__
Configure Jest for Web Components
StoryShots addon for Web Components requires jsdom 16 or later to fully support the
web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to
__INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.
Configure Jest for MDX Docs Add-On Stories
If using the Docs add-on with
MDX stories you will need
to configure Jest to transform MDX stories into something Storyshots can understand:
Add the following to your Jest configuration:
__CODE_BLOCK_19__
Why don't we install dependencies of each framework ?
Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.
__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).
__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.
__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.
__INLINE_CODE_24__ - unfortunately there is nothing like this =(
For more information read npm docs
Using __INLINE_CODE_25__ to mock refs
__INLINE_CODE_26__ doesn't provide refs for rendered components. By
default, it returns null when the refs are referenced. In order to mock
out elements that rely on refs, you will have to use the
__INLINE_CODE_27__ option added to React starting with version 15.4.0.
Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:
__CODE_BLOCK_20__
Provide a function to have story-specific options:
__CODE_BLOCK_21__
Using a custom renderer
By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.
Example with React Testing Library
__CODE_BLOCK_22__
Example with Enzyme
__CODE_BLOCK_23__
If you are using enzyme, you need to make sure jest knows how to serialize rendered components.
For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).
StoryShots for async rendered components
You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.
Example
The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.
Add stories of UserForm in the file: UserForm.story.jsx
__CODE_BLOCK_24__
Then, init Storyshots for async component in the file: StoryShots.test.js
__CODE_BLOCK_25__
NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.
This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.
Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.
Using a custom directory
Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.
Options
__INLINE_CODE_40__
The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does.
If it's not specified, storyshots will try to use configPath parameter.
__CODE_BLOCK_26__
__INLINE_CODE_43__
By default, Storyshots assumes the config directory path for your project as below:

Storybook for React: __INLINE_CODE_44__
Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:
__CODE_BLOCK_27__
Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:
__CODE_BLOCK_28__
__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be
a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the
original one. It also may be useful for separating tests to different test configs:
__CODE_BLOCK_29__
__INLINE_CODE_54__
By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:
__CODE_BLOCK_30__
__INLINE_CODE_55__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:
__CODE_BLOCK_31__
This can be useful if you want to separate the snapshots in directories next to each component. See an example here.
If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__
__CODE_BLOCK_32__
This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing
while using react-test-renderer see here
__INLINE_CODE_57__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:
__CODE_BLOCK_33__
__INLINE_CODE_58__
If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.
For example:
__CODE_BLOCK_34__
Use this table as a reference for manually specifying the framework.



angular
html
preact



react
react-native
vue3


svelte
vue
web-components


__INLINE_CODE_61__
Run a custom test function for each story, rather than the default (a vanilla snapshot test).
Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option.
You can still overwrite what renderer is used for the test function:
__CODE_BLOCK_35__
__INLINE_CODE_64__
Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots.
This may be necessary if you want to use React features that are not supported by the default test renderer,
such as ref or Portals.
Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.
__INLINE_CODE_68__
Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).
__CODE_BLOCK_36__
This option needs to be set if either:

the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)
Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.
__CODE_BLOCK_37__
This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.
__INLINE_CODE_71__
This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.
By default, the instance of this class is created with these default options:
__CODE_BLOCK_38__
This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:
__CODE_BLOCK_39__
Exports
Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):
__INLINE_CODE_75__
The default, render the story as normal and take a Jest snapshot.
__INLINE_CODE_76__
Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your
components to ensure they do not error.
__INLINE_CODE_77__
Like the default, but allows you to specify a set of options for the test renderer. See for example here.
__INLINE_CODE_78__
Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.
__INLINE_CODE_80__
Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object.
If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:
__CODE_BLOCK_40__
integrityOptions
This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default).
The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.
__CODE_BLOCK_41__
__INLINE_CODE_84__
Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.
__INLINE_CODE_86__
This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.
Example:
Let's say we wanted to create a test function for shallow && multi-file snapshots:
__CODE_BLOCK_42__
__INLINE_CODE_87__
Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.
Story Parameters
__INLINE_CODE_89__
Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.
__CODE_BLOCK_43__
: '<rootDir>/node_modules/jest-preset-angular/preprocessor.js',
  },
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'],
};
Configure Jest for Vue
StoryShots addon for Vue is dependent on jest-vue-preprocessor, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_14__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_15__
Configure Jest for Vue 3
StoryShots addon for Vue is dependent on vue-jest v5, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_16__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_17__
Configure Jest for Preact
StoryShots addon for Preact is dependent on preact-render-to-string, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_18__
Configure Jest for Web Components
StoryShots addon for Web Components requires jsdom 16 or later to fully support the
web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to
__INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.
Configure Jest for MDX Docs Add-On Stories
If using the Docs add-on with
MDX stories you will need
to configure Jest to transform MDX stories into something Storyshots can understand:
Add the following to your Jest configuration:
__CODE_BLOCK_19__
Why don't we install dependencies of each framework ?
Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.
__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).
__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.
__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.
__INLINE_CODE_24__ - unfortunately there is nothing like this =(
For more information read npm docs
Using __INLINE_CODE_25__ to mock refs
__INLINE_CODE_26__ doesn't provide refs for rendered components. By
default, it returns null when the refs are referenced. In order to mock
out elements that rely on refs, you will have to use the
__INLINE_CODE_27__ option added to React starting with version 15.4.0.
Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:
__CODE_BLOCK_20__
Provide a function to have story-specific options:
__CODE_BLOCK_21__
Using a custom renderer
By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.
Example with React Testing Library
__CODE_BLOCK_22__
Example with Enzyme
__CODE_BLOCK_23__
If you are using enzyme, you need to make sure jest knows how to serialize rendered components.
For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).
StoryShots for async rendered components
You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.
Example
The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.
Add stories of UserForm in the file: UserForm.story.jsx
__CODE_BLOCK_24__
Then, init Storyshots for async component in the file: StoryShots.test.js
__CODE_BLOCK_25__
NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.
This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.
Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.
Using a custom directory
Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.
Options
__INLINE_CODE_40__
The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does.
If it's not specified, storyshots will try to use configPath parameter.
__CODE_BLOCK_26__
__INLINE_CODE_43__
By default, Storyshots assumes the config directory path for your project as below:

Storybook for React: __INLINE_CODE_44__
Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:
__CODE_BLOCK_27__
Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:
__CODE_BLOCK_28__
__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be
a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the
original one. It also may be useful for separating tests to different test configs:
__CODE_BLOCK_29__
__INLINE_CODE_54__
By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:
__CODE_BLOCK_30__
__INLINE_CODE_55__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:
__CODE_BLOCK_31__
This can be useful if you want to separate the snapshots in directories next to each component. See an example here.
If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__
__CODE_BLOCK_32__
This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing
while using react-test-renderer see here
__INLINE_CODE_57__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:
__CODE_BLOCK_33__
__INLINE_CODE_58__
If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.
For example:
__CODE_BLOCK_34__
Use this table as a reference for manually specifying the framework.



angular
html
preact



react
react-native
vue3


svelte
vue
web-components


__INLINE_CODE_61__
Run a custom test function for each story, rather than the default (a vanilla snapshot test).
Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option.
You can still overwrite what renderer is used for the test function:
__CODE_BLOCK_35__
__INLINE_CODE_64__
Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots.
This may be necessary if you want to use React features that are not supported by the default test renderer,
such as ref or Portals.
Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.
__INLINE_CODE_68__
Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).
__CODE_BLOCK_36__
This option needs to be set if either:

the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)
Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.
__CODE_BLOCK_37__
This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.
__INLINE_CODE_71__
This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.
By default, the instance of this class is created with these default options:
__CODE_BLOCK_38__
This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:
__CODE_BLOCK_39__
Exports
Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):
__INLINE_CODE_75__
The default, render the story as normal and take a Jest snapshot.
__INLINE_CODE_76__
Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your
components to ensure they do not error.
__INLINE_CODE_77__
Like the default, but allows you to specify a set of options for the test renderer. See for example here.
__INLINE_CODE_78__
Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.
__INLINE_CODE_80__
Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object.
If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:
__CODE_BLOCK_40__
integrityOptions
This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default).
The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.
__CODE_BLOCK_41__
__INLINE_CODE_84__
Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.
__INLINE_CODE_86__
This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.
Example:
Let's say we wanted to create a test function for shallow && multi-file snapshots:
__CODE_BLOCK_42__
__INLINE_CODE_87__
Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.
Story Parameters
__INLINE_CODE_89__
Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.
__CODE_BLOCK_43__
: 'babel-jest',
    '.*\\.(vue)
Configure Jest for Vue 3
StoryShots addon for Vue is dependent on vue-jest v5, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_16__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_17__
Configure Jest for Preact
StoryShots addon for Preact is dependent on preact-render-to-string, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_18__
Configure Jest for Web Components
StoryShots addon for Web Components requires jsdom 16 or later to fully support the
web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to
__INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.
Configure Jest for MDX Docs Add-On Stories
If using the Docs add-on with
MDX stories you will need
to configure Jest to transform MDX stories into something Storyshots can understand:
Add the following to your Jest configuration:
__CODE_BLOCK_19__
Why don't we install dependencies of each framework ?
Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.
__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).
__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.
__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.
__INLINE_CODE_24__ - unfortunately there is nothing like this =(
For more information read npm docs
Using __INLINE_CODE_25__ to mock refs
__INLINE_CODE_26__ doesn't provide refs for rendered components. By
default, it returns null when the refs are referenced. In order to mock
out elements that rely on refs, you will have to use the
__INLINE_CODE_27__ option added to React starting with version 15.4.0.
Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:
__CODE_BLOCK_20__
Provide a function to have story-specific options:
__CODE_BLOCK_21__
Using a custom renderer
By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.
Example with React Testing Library
__CODE_BLOCK_22__
Example with Enzyme
__CODE_BLOCK_23__
If you are using enzyme, you need to make sure jest knows how to serialize rendered components.
For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).
StoryShots for async rendered components
You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.
Example
The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.
Add stories of UserForm in the file: UserForm.story.jsx
__CODE_BLOCK_24__
Then, init Storyshots for async component in the file: StoryShots.test.js
__CODE_BLOCK_25__
NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.
This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.
Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.
Using a custom directory
Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.
Options
__INLINE_CODE_40__
The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does.
If it's not specified, storyshots will try to use configPath parameter.
__CODE_BLOCK_26__
__INLINE_CODE_43__
By default, Storyshots assumes the config directory path for your project as below:

Storybook for React: __INLINE_CODE_44__
Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:
__CODE_BLOCK_27__
Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:
__CODE_BLOCK_28__
__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be
a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the
original one. It also may be useful for separating tests to different test configs:
__CODE_BLOCK_29__
__INLINE_CODE_54__
By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:
__CODE_BLOCK_30__
__INLINE_CODE_55__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:
__CODE_BLOCK_31__
This can be useful if you want to separate the snapshots in directories next to each component. See an example here.
If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__
__CODE_BLOCK_32__
This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing
while using react-test-renderer see here
__INLINE_CODE_57__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:
__CODE_BLOCK_33__
__INLINE_CODE_58__
If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.
For example:
__CODE_BLOCK_34__
Use this table as a reference for manually specifying the framework.



angular
html
preact



react
react-native
vue3


svelte
vue
web-components


__INLINE_CODE_61__
Run a custom test function for each story, rather than the default (a vanilla snapshot test).
Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option.
You can still overwrite what renderer is used for the test function:
__CODE_BLOCK_35__
__INLINE_CODE_64__
Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots.
This may be necessary if you want to use React features that are not supported by the default test renderer,
such as ref or Portals.
Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.
__INLINE_CODE_68__
Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).
__CODE_BLOCK_36__
This option needs to be set if either:

the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)
Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.
__CODE_BLOCK_37__
This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.
__INLINE_CODE_71__
This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.
By default, the instance of this class is created with these default options:
__CODE_BLOCK_38__
This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:
__CODE_BLOCK_39__
Exports
Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):
__INLINE_CODE_75__
The default, render the story as normal and take a Jest snapshot.
__INLINE_CODE_76__
Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your
components to ensure they do not error.
__INLINE_CODE_77__
Like the default, but allows you to specify a set of options for the test renderer. See for example here.
__INLINE_CODE_78__
Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.
__INLINE_CODE_80__
Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object.
If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:
__CODE_BLOCK_40__
integrityOptions
This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default).
The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.
__CODE_BLOCK_41__
__INLINE_CODE_84__
Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.
__INLINE_CODE_86__
This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.
Example:
Let's say we wanted to create a test function for shallow && multi-file snapshots:
__CODE_BLOCK_42__
__INLINE_CODE_87__
Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.
Story Parameters
__INLINE_CODE_89__
Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.
__CODE_BLOCK_43__
: 'babel-jest',
    '^.+\\.(ts|html)
Configure Jest for Vue
StoryShots addon for Vue is dependent on jest-vue-preprocessor, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_14__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_15__
Configure Jest for Vue 3
StoryShots addon for Vue is dependent on vue-jest v5, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_16__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_17__
Configure Jest for Preact
StoryShots addon for Preact is dependent on preact-render-to-string, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_18__
Configure Jest for Web Components
StoryShots addon for Web Components requires jsdom 16 or later to fully support the
web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to
__INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.
Configure Jest for MDX Docs Add-On Stories
If using the Docs add-on with
MDX stories you will need
to configure Jest to transform MDX stories into something Storyshots can understand:
Add the following to your Jest configuration:
__CODE_BLOCK_19__
Why don't we install dependencies of each framework ?
Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.
__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).
__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.
__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.
__INLINE_CODE_24__ - unfortunately there is nothing like this =(
For more information read npm docs
Using __INLINE_CODE_25__ to mock refs
__INLINE_CODE_26__ doesn't provide refs for rendered components. By
default, it returns null when the refs are referenced. In order to mock
out elements that rely on refs, you will have to use the
__INLINE_CODE_27__ option added to React starting with version 15.4.0.
Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:
__CODE_BLOCK_20__
Provide a function to have story-specific options:
__CODE_BLOCK_21__
Using a custom renderer
By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.
Example with React Testing Library
__CODE_BLOCK_22__
Example with Enzyme
__CODE_BLOCK_23__
If you are using enzyme, you need to make sure jest knows how to serialize rendered components.
For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).
StoryShots for async rendered components
You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.
Example
The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.
Add stories of UserForm in the file: UserForm.story.jsx
__CODE_BLOCK_24__
Then, init Storyshots for async component in the file: StoryShots.test.js
__CODE_BLOCK_25__
NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.
This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.
Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.
Using a custom directory
Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.
Options
__INLINE_CODE_40__
The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does.
If it's not specified, storyshots will try to use configPath parameter.
__CODE_BLOCK_26__
__INLINE_CODE_43__
By default, Storyshots assumes the config directory path for your project as below:

Storybook for React: __INLINE_CODE_44__
Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:
__CODE_BLOCK_27__
Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:
__CODE_BLOCK_28__
__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be
a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the
original one. It also may be useful for separating tests to different test configs:
__CODE_BLOCK_29__
__INLINE_CODE_54__
By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:
__CODE_BLOCK_30__
__INLINE_CODE_55__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:
__CODE_BLOCK_31__
This can be useful if you want to separate the snapshots in directories next to each component. See an example here.
If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__
__CODE_BLOCK_32__
This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing
while using react-test-renderer see here
__INLINE_CODE_57__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:
__CODE_BLOCK_33__
__INLINE_CODE_58__
If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.
For example:
__CODE_BLOCK_34__
Use this table as a reference for manually specifying the framework.



angular
html
preact



react
react-native
vue3


svelte
vue
web-components


__INLINE_CODE_61__
Run a custom test function for each story, rather than the default (a vanilla snapshot test).
Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option.
You can still overwrite what renderer is used for the test function:
__CODE_BLOCK_35__
__INLINE_CODE_64__
Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots.
This may be necessary if you want to use React features that are not supported by the default test renderer,
such as ref or Portals.
Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.
__INLINE_CODE_68__
Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).
__CODE_BLOCK_36__
This option needs to be set if either:

the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)
Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.
__CODE_BLOCK_37__
This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.
__INLINE_CODE_71__
This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.
By default, the instance of this class is created with these default options:
__CODE_BLOCK_38__
This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:
__CODE_BLOCK_39__
Exports
Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):
__INLINE_CODE_75__
The default, render the story as normal and take a Jest snapshot.
__INLINE_CODE_76__
Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your
components to ensure they do not error.
__INLINE_CODE_77__
Like the default, but allows you to specify a set of options for the test renderer. See for example here.
__INLINE_CODE_78__
Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.
__INLINE_CODE_80__
Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object.
If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:
__CODE_BLOCK_40__
integrityOptions
This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default).
The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.
__CODE_BLOCK_41__
__INLINE_CODE_84__
Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.
__INLINE_CODE_86__
This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.
Example:
Let's say we wanted to create a test function for shallow && multi-file snapshots:
__CODE_BLOCK_42__
__INLINE_CODE_87__
Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.
Story Parameters
__INLINE_CODE_89__
Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.
__CODE_BLOCK_43__
: '<rootDir>/node_modules/jest-preset-angular/preprocessor.js',
  },
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'],
};
Configure Jest for Vue
StoryShots addon for Vue is dependent on jest-vue-preprocessor, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_14__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_15__
Configure Jest for Vue 3
StoryShots addon for Vue is dependent on vue-jest v5, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_16__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_17__
Configure Jest for Preact
StoryShots addon for Preact is dependent on preact-render-to-string, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_18__
Configure Jest for Web Components
StoryShots addon for Web Components requires jsdom 16 or later to fully support the
web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to
__INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.
Configure Jest for MDX Docs Add-On Stories
If using the Docs add-on with
MDX stories you will need
to configure Jest to transform MDX stories into something Storyshots can understand:
Add the following to your Jest configuration:
__CODE_BLOCK_19__
Why don't we install dependencies of each framework ?
Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.
__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).
__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.
__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.
__INLINE_CODE_24__ - unfortunately there is nothing like this =(
For more information read npm docs
Using __INLINE_CODE_25__ to mock refs
__INLINE_CODE_26__ doesn't provide refs for rendered components. By
default, it returns null when the refs are referenced. In order to mock
out elements that rely on refs, you will have to use the
__INLINE_CODE_27__ option added to React starting with version 15.4.0.
Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:
__CODE_BLOCK_20__
Provide a function to have story-specific options:
__CODE_BLOCK_21__
Using a custom renderer
By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.
Example with React Testing Library
__CODE_BLOCK_22__
Example with Enzyme
__CODE_BLOCK_23__
If you are using enzyme, you need to make sure jest knows how to serialize rendered components.
For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).
StoryShots for async rendered components
You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.
Example
The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.
Add stories of UserForm in the file: UserForm.story.jsx
__CODE_BLOCK_24__
Then, init Storyshots for async component in the file: StoryShots.test.js
__CODE_BLOCK_25__
NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.
This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.
Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.
Using a custom directory
Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.
Options
__INLINE_CODE_40__
The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does.
If it's not specified, storyshots will try to use configPath parameter.
__CODE_BLOCK_26__
__INLINE_CODE_43__
By default, Storyshots assumes the config directory path for your project as below:

Storybook for React: __INLINE_CODE_44__
Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:
__CODE_BLOCK_27__
Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:
__CODE_BLOCK_28__
__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be
a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the
original one. It also may be useful for separating tests to different test configs:
__CODE_BLOCK_29__
__INLINE_CODE_54__
By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:
__CODE_BLOCK_30__
__INLINE_CODE_55__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:
__CODE_BLOCK_31__
This can be useful if you want to separate the snapshots in directories next to each component. See an example here.
If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__
__CODE_BLOCK_32__
This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing
while using react-test-renderer see here
__INLINE_CODE_57__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:
__CODE_BLOCK_33__
__INLINE_CODE_58__
If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.
For example:
__CODE_BLOCK_34__
Use this table as a reference for manually specifying the framework.



angular
html
preact



react
react-native
vue3


svelte
vue
web-components


__INLINE_CODE_61__
Run a custom test function for each story, rather than the default (a vanilla snapshot test).
Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option.
You can still overwrite what renderer is used for the test function:
__CODE_BLOCK_35__
__INLINE_CODE_64__
Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots.
This may be necessary if you want to use React features that are not supported by the default test renderer,
such as ref or Portals.
Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.
__INLINE_CODE_68__
Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).
__CODE_BLOCK_36__
This option needs to be set if either:

the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)
Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.
__CODE_BLOCK_37__
This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.
__INLINE_CODE_71__
This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.
By default, the instance of this class is created with these default options:
__CODE_BLOCK_38__
This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:
__CODE_BLOCK_39__
Exports
Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):
__INLINE_CODE_75__
The default, render the story as normal and take a Jest snapshot.
__INLINE_CODE_76__
Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your
components to ensure they do not error.
__INLINE_CODE_77__
Like the default, but allows you to specify a set of options for the test renderer. See for example here.
__INLINE_CODE_78__
Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.
__INLINE_CODE_80__
Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object.
If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:
__CODE_BLOCK_40__
integrityOptions
This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default).
The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.
__CODE_BLOCK_41__
__INLINE_CODE_84__
Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.
__INLINE_CODE_86__
This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.
Example:
Let's say we wanted to create a test function for shallow && multi-file snapshots:
__CODE_BLOCK_42__
__INLINE_CODE_87__
Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.
Story Parameters
__INLINE_CODE_89__
Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.
__CODE_BLOCK_43__
: '<rootDir>/node_modules/jest-vue-preprocessor',
  },
  transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'],
  moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'],
};
Configure Jest for Vue 3
StoryShots addon for Vue is dependent on vue-jest v5, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_16__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_17__
Configure Jest for Preact
StoryShots addon for Preact is dependent on preact-render-to-string, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_18__
Configure Jest for Web Components
StoryShots addon for Web Components requires jsdom 16 or later to fully support the
web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to
__INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.
Configure Jest for MDX Docs Add-On Stories
If using the Docs add-on with
MDX stories you will need
to configure Jest to transform MDX stories into something Storyshots can understand:
Add the following to your Jest configuration:
__CODE_BLOCK_19__
Why don't we install dependencies of each framework ?
Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.
__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).
__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.
__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.
__INLINE_CODE_24__ - unfortunately there is nothing like this =(
For more information read npm docs
Using __INLINE_CODE_25__ to mock refs
__INLINE_CODE_26__ doesn't provide refs for rendered components. By
default, it returns null when the refs are referenced. In order to mock
out elements that rely on refs, you will have to use the
__INLINE_CODE_27__ option added to React starting with version 15.4.0.
Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:
__CODE_BLOCK_20__
Provide a function to have story-specific options:
__CODE_BLOCK_21__
Using a custom renderer
By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.
Example with React Testing Library
__CODE_BLOCK_22__
Example with Enzyme
__CODE_BLOCK_23__
If you are using enzyme, you need to make sure jest knows how to serialize rendered components.
For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).
StoryShots for async rendered components
You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.
Example
The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.
Add stories of UserForm in the file: UserForm.story.jsx
__CODE_BLOCK_24__
Then, init Storyshots for async component in the file: StoryShots.test.js
__CODE_BLOCK_25__
NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.
This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.
Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.
Using a custom directory
Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.
Options
__INLINE_CODE_40__
The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does.
If it's not specified, storyshots will try to use configPath parameter.
__CODE_BLOCK_26__
__INLINE_CODE_43__
By default, Storyshots assumes the config directory path for your project as below:

Storybook for React: __INLINE_CODE_44__
Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:
__CODE_BLOCK_27__
Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:
__CODE_BLOCK_28__
__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be
a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the
original one. It also may be useful for separating tests to different test configs:
__CODE_BLOCK_29__
__INLINE_CODE_54__
By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:
__CODE_BLOCK_30__
__INLINE_CODE_55__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:
__CODE_BLOCK_31__
This can be useful if you want to separate the snapshots in directories next to each component. See an example here.
If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__
__CODE_BLOCK_32__
This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing
while using react-test-renderer see here
__INLINE_CODE_57__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:
__CODE_BLOCK_33__
__INLINE_CODE_58__
If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.
For example:
__CODE_BLOCK_34__
Use this table as a reference for manually specifying the framework.



angular
html
preact



react
react-native
vue3


svelte
vue
web-components


__INLINE_CODE_61__
Run a custom test function for each story, rather than the default (a vanilla snapshot test).
Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option.
You can still overwrite what renderer is used for the test function:
__CODE_BLOCK_35__
__INLINE_CODE_64__
Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots.
This may be necessary if you want to use React features that are not supported by the default test renderer,
such as ref or Portals.
Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.
__INLINE_CODE_68__
Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).
__CODE_BLOCK_36__
This option needs to be set if either:

the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)
Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.
__CODE_BLOCK_37__
This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.
__INLINE_CODE_71__
This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.
By default, the instance of this class is created with these default options:
__CODE_BLOCK_38__
This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:
__CODE_BLOCK_39__
Exports
Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):
__INLINE_CODE_75__
The default, render the story as normal and take a Jest snapshot.
__INLINE_CODE_76__
Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your
components to ensure they do not error.
__INLINE_CODE_77__
Like the default, but allows you to specify a set of options for the test renderer. See for example here.
__INLINE_CODE_78__
Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.
__INLINE_CODE_80__
Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object.
If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:
__CODE_BLOCK_40__
integrityOptions
This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default).
The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.
__CODE_BLOCK_41__
__INLINE_CODE_84__
Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.
__INLINE_CODE_86__
This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.
Example:
Let's say we wanted to create a test function for shallow && multi-file snapshots:
__CODE_BLOCK_42__
__INLINE_CODE_87__
Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.
Story Parameters
__INLINE_CODE_89__
Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.
__CODE_BLOCK_43__
: 'babel-jest',
    '^.+\\.(ts|html)
Configure Jest for Vue
StoryShots addon for Vue is dependent on jest-vue-preprocessor, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_14__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_15__
Configure Jest for Vue 3
StoryShots addon for Vue is dependent on vue-jest v5, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_16__
If you already use Jest for testing your vue app - probably you already have the needed jest configuration.
Anyway you can add these lines to your jest config:
__CODE_BLOCK_17__
Configure Jest for Preact
StoryShots addon for Preact is dependent on preact-render-to-string, but
doesn't install it, so you need to install it separately.
__CODE_BLOCK_18__
Configure Jest for Web Components
StoryShots addon for Web Components requires jsdom 16 or later to fully support the
web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to
__INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.
Configure Jest for MDX Docs Add-On Stories
If using the Docs add-on with
MDX stories you will need
to configure Jest to transform MDX stories into something Storyshots can understand:
Add the following to your Jest configuration:
__CODE_BLOCK_19__
Why don't we install dependencies of each framework ?
Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.
__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).
__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.
__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.
__INLINE_CODE_24__ - unfortunately there is nothing like this =(
For more information read npm docs
Using __INLINE_CODE_25__ to mock refs
__INLINE_CODE_26__ doesn't provide refs for rendered components. By
default, it returns null when the refs are referenced. In order to mock
out elements that rely on refs, you will have to use the
__INLINE_CODE_27__ option added to React starting with version 15.4.0.
Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:
__CODE_BLOCK_20__
Provide a function to have story-specific options:
__CODE_BLOCK_21__
Using a custom renderer
By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.
Example with React Testing Library
__CODE_BLOCK_22__
Example with Enzyme
__CODE_BLOCK_23__
If you are using enzyme, you need to make sure jest knows how to serialize rendered components.
For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).
StoryShots for async rendered components
You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.
Example
The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.
Add stories of UserForm in the file: UserForm.story.jsx
__CODE_BLOCK_24__
Then, init Storyshots for async component in the file: StoryShots.test.js
__CODE_BLOCK_25__
NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.
This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.
Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.
Using a custom directory
Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.
Options
__INLINE_CODE_40__
The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does.
If it's not specified, storyshots will try to use configPath parameter.
__CODE_BLOCK_26__
__INLINE_CODE_43__
By default, Storyshots assumes the config directory path for your project as below:

Storybook for React: __INLINE_CODE_44__
Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:
__CODE_BLOCK_27__
Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:
__CODE_BLOCK_28__
__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be
a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the
original one. It also may be useful for separating tests to different test configs:
__CODE_BLOCK_29__
__INLINE_CODE_54__
By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:
__CODE_BLOCK_30__
__INLINE_CODE_55__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:
__CODE_BLOCK_31__
This can be useful if you want to separate the snapshots in directories next to each component. See an example here.
If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__
__CODE_BLOCK_32__
This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing
while using react-test-renderer see here
__INLINE_CODE_57__
If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:
__CODE_BLOCK_33__
__INLINE_CODE_58__
If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.
For example:
__CODE_BLOCK_34__
Use this table as a reference for manually specifying the framework.



angular
html
preact



react
react-native
vue3


svelte
vue
web-components


__INLINE_CODE_61__
Run a custom test function for each story, rather than the default (a vanilla snapshot test).
Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option.
You can still overwrite what renderer is used for the test function:
__CODE_BLOCK_35__
__INLINE_CODE_64__
Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots.
This may be necessary if you want to use React features that are not supported by the default test renderer,
such as ref or Portals.
Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.
__INLINE_CODE_68__
Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).
__CODE_BLOCK_36__
This option needs to be set if either:

the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)
Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.
__CODE_BLOCK_37__
This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.
__INLINE_CODE_71__
This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.
By default, the instance of this class is created with these default options:
__CODE_BLOCK_38__
This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:
__CODE_BLOCK_39__
Exports
Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):
__INLINE_CODE_75__
The default, render the story as normal and take a Jest snapshot.
__INLINE_CODE_76__
Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your
components to ensure they do not error.
__INLINE_CODE_77__
Like the default, but allows you to specify a set of options for the test renderer. See for example here.
__INLINE_CODE_78__
Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.
__INLINE_CODE_80__
Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object.
If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:
__CODE_BLOCK_40__
integrityOptions
This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default).
The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.
__CODE_BLOCK_41__
__INLINE_CODE_84__
Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.
__INLINE_CODE_86__
This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.
Example:
Let's say we wanted to create a test function for shallow && multi-file snapshots:
__CODE_BLOCK_42__
__INLINE_CODE_87__
Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.
Story Parameters
__INLINE_CODE_89__
Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.
__CODE_BLOCK_43__
: '<rootDir>/node_modules/jest-preset-angular/preprocessor.js',
  },
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'],
};

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-vue-preprocessor', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/vue-jest', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-vue-preprocessor', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '@storybook/addon-storyshots/injectFileName', '^.+\\.jsx?

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-vue-preprocessor', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-vue-preprocessor', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/vue-jest', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-vue-preprocessor', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', }, };

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-vue-preprocessor', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-vue-preprocessor', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/vue-jest', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '.*\\.(vue)

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-vue-preprocessor', }, transformIgnorePatterns: ['/node_modules/(?!(@storybook/.*\\.vue$))'], moduleFileExtensions: ['vue', 'js', 'jsx', 'json', 'node'], };

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : 'babel-jest', '^.+\\.(ts|html)

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__ : '<rootDir>/node_modules/jest-preset-angular/preprocessor.js', }, moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node', '.html'], };

Configure Jest for Vue

StoryShots addon for Vue is dependent on jest-vue-preprocessor, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_14__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_15__

Configure Jest for Vue 3

StoryShots addon for Vue is dependent on vue-jest v5, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_16__

If you already use Jest for testing your vue app - probably you already have the needed jest configuration. Anyway you can add these lines to your jest config:

__CODE_BLOCK_17__

Configure Jest for Preact

StoryShots addon for Preact is dependent on preact-render-to-string, but doesn't install it, so you need to install it separately.

__CODE_BLOCK_18__

Configure Jest for Web Components

StoryShots addon for Web Components requires jsdom 16 or later to fully support the web component shadow dom. To use jsdom 16 or later you can set the Jest __INLINE_CODE_19__ configuration key to __INLINE_CODE_20__. This should work back to Jest 24 and is the default in Jest 26 and later.

Configure Jest for MDX Docs Add-On Stories

If using the Docs add-on with MDX stories you will need to configure Jest to transform MDX stories into something Storyshots can understand:

Add the following to your Jest configuration:

__CODE_BLOCK_19__

Why don't we install dependencies of each framework ?

Storyshots addon is currently supporting React, Angular and Vue. Each framework needs its own packages to be integrated with Jest. We don't want people that use only React will need to bring other dependencies that do not make sense for them.

__INLINE_CODE_21__ - will installed an exact version of the particular dep - Storyshots can work with different versions of the same framework (let's say React v16 and React v15), that have to be compatible with a version of its plugin (react-test-renderer).

__INLINE_CODE_22__ - behaves like a regular dependency, but do not fail the installation in case there is a problem to bring the dep.

__INLINE_CODE_23__ - listing all the deps in peer will trigger warnings during the installation - we don't want users to install unneeded deps by hand.

__INLINE_CODE_24__ - unfortunately there is nothing like this =(

For more information read npm docs

Using __INLINE_CODE_25__ to mock refs

__INLINE_CODE_26__ doesn't provide refs for rendered components. By default, it returns null when the refs are referenced. In order to mock out elements that rely on refs, you will have to use the __INLINE_CODE_27__ option added to React starting with version 15.4.0.

Here is an example of how to specify the __INLINE_CODE_28__ option in Storyshots:

__CODE_BLOCK_20__

Provide a function to have story-specific options:

__CODE_BLOCK_21__

Using a custom renderer

By design, __INLINE_CODE_29__ doesn't use a browser environment or JSDOM. Because of this difference, some stories might render in your browser, but not in Storyshots. If you encounter this problem, you may want to switch for an higher level renderer such as __INLINE_CODE_30__ from Enzyme or __INLINE_CODE_31__ from React Testing Library.

Example with React Testing Library

__CODE_BLOCK_22__

Example with Enzyme

__CODE_BLOCK_23__

If you are using enzyme, you need to make sure jest knows how to serialize rendered components. For that, you can pass an enzyme-compatible snapshotSerializer (like enzyme-to-json, jest-serializer-enzyme etc.) with the __INLINE_CODE_32__ option (see below).

StoryShots for async rendered components

You can make use of Jest done callback to test components that render asynchronously. This callback is passed as param to test method passed to __INLINE_CODE_33__ when the __INLINE_CODE_34__ option is given as true.

Example

The following example shows how we can use the done callback to take StoryShots of a Relay component. Each kind of story is written into its own snapshot file with the use of __INLINE_CODE_35__.

Add stories of UserForm in the file: UserForm.story.jsx

__CODE_BLOCK_24__

Then, init Storyshots for async component in the file: StoryShots.test.js

__CODE_BLOCK_25__

NOTICE that When using the __INLINE_CODE_36__ option, you also must specify a __INLINE_CODE_37__ method that calls the __INLINE_CODE_38__ callback.

This is a really powerful technique to write stories of Relay components because it integrates data fetching with component rendering. So instead of passing data props manually, we can let Relay do the job for us as it does in our application.

Whenever you change your data requirements by adding (and rendering) or (accidentally) deleting fields in your graphql query fragments, you'll get a different snapshot and thus an error in the StoryShot test.

Using a custom directory

Depending on your project's needs, you can configure the __INLINE_CODE_39__ to use a custom directory for the snapshots. You can read more about it in the official docs.

Options

__INLINE_CODE_40__

The __INLINE_CODE_41__ parameter must be a function that helps to configure storybook like the __INLINE_CODE_42__ does. If it's not specified, storyshots will try to use configPath parameter.

__CODE_BLOCK_26__

__INLINE_CODE_43__

By default, Storyshots assumes the config directory path for your project as below:

• Storybook for React: __INLINE_CODE_44__
• Storybook for React Native: __INLINE_CODE_45__

If you are using a different config directory path, you could change it like this:

__CODE_BLOCK_27__

Or, as a more complex example, if we have a package in our __INLINE_CODE_46__ project called __INLINE_CODE_47__ with the path __INLINE_CODE_48__ and the storybook config directory __INLINE_CODE_49__:

__CODE_BLOCK_28__

__INLINE_CODE_50__ can also specify path to the __INLINE_CODE_51__ itself. In this case, config directory will be a base directory of the __INLINE_CODE_52__. It may be useful when the __INLINE_CODE_53__ for test should differ from the original one. It also may be useful for separating tests to different test configs:

__CODE_BLOCK_29__

__INLINE_CODE_54__

By default, Storyshots groups stories inside a Jest test suite called "Storyshots". You could change it like this:

__CODE_BLOCK_30__

__INLINE_CODE_55__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's kind:

__CODE_BLOCK_31__

This can be useful if you want to separate the snapshots in directories next to each component. See an example here.

If you want to run all stories except stories of a specific kind, you can write an inverse regex which is true for all kinds except those with a specific word such as __INLINE_CODE_56__

__CODE_BLOCK_32__

This can be useful while testing react components which make use of the findDomNode API since they always fail with snapshot testing while using react-test-renderer see here

__INLINE_CODE_57__

If you'd like to only run a subset of the stories for your snapshot tests based on the story's name:

__CODE_BLOCK_33__

__INLINE_CODE_58__

If you are running tests from outside of your app's directory, storyshots' detection of which framework you are using may fail. Pass __INLINE_CODE_59__ or __INLINE_CODE_60__ to short-circuit this.

For example:

__CODE_BLOCK_34__

Use this table as a reference for manually specifying the framework.

angular	html	preact
react	react-native	vue3
svelte	vue	web-components

__INLINE_CODE_61__

Run a custom test function for each story, rather than the default (a vanilla snapshot test). Setting __INLINE_CODE_62__ will take precedence over the __INLINE_CODE_63__ option. You can still overwrite what renderer is used for the test function:

__CODE_BLOCK_35__

__INLINE_CODE_64__

Pass a custom renderer (such as enzymes __INLINE_CODE_65__) to record snapshots. This may be necessary if you want to use React features that are not supported by the default test renderer, such as ref or Portals. Note that setting __INLINE_CODE_66__ overrides __INLINE_CODE_67__.

__INLINE_CODE_68__

Pass an array of snapshotSerializers to the jest runtime that serializes your story (such as enzyme-to-json).

__CODE_BLOCK_36__

This option needs to be set if either:

• the multiSnapshot function is used to create multiple snapshot files (i.e. one per story), since it ignores any serializers specified in your jest config.
• serializers not specified in your jest config should be used when snapshotting stories.

__INLINE_CODE_69__ (deprecated)

Pass a custom serializer (such as enzyme-to-json) to serialize components to snapshot-comparable data. The functionality of this option is completely covered by snapshotSerializers which should be used instead.

__CODE_BLOCK_37__

This option only needs to be set if the default __INLINE_CODE_70__ is not set in your jest config.

__INLINE_CODE_71__

This parameter should be an instance of the __INLINE_CODE_72__ (or a derived from it) Class that is used to convert story-file name to snapshot-file name and vice versa.

By default, the instance of this class is created with these default options:

__CODE_BLOCK_38__

This class might be overridden to extend the existing conversion functionality or instantiated to provide different options:

__CODE_BLOCK_39__

Exports

Apart from the default export (__INLINE_CODE_73__), Storyshots also exports some named test functions (see the __INLINE_CODE_74__ option above):

__INLINE_CODE_75__

The default, render the story as normal and take a Jest snapshot.

__INLINE_CODE_76__

Just render the story, don't check the output at all. This is useful as a low-effort way of smoke testing your components to ensure they do not error.

__INLINE_CODE_77__

Like the default, but allows you to specify a set of options for the test renderer. See for example here.

__INLINE_CODE_78__

Like the default, but allows you to specify a set of options for the renderer, just like __INLINE_CODE_79__.

__INLINE_CODE_80__

Like __INLINE_CODE_81__, but generate a separate snapshot file for each stories file rather than a single monolithic file (as is the convention in Jest). This makes it dramatically easier to review changes. If you'd like the benefit of separate snapshot files, but don't have custom options to pass, you can pass an empty object. If you use Component Story Format, you may also need to add an additional Jest transform to automate detecting story file names:

__CODE_BLOCK_40__

integrityOptions

This option is useful when running test with __INLINE_CODE_82__ in order to track snapshots are matching the stories. (disabled by default). The value is a settings to a __INLINE_CODE_83__ object, that searches for the snapshot files.

__CODE_BLOCK_41__

__INLINE_CODE_84__

Take a snapshot of a shallow-rendered version of the component. Note that this option will be overridden if you pass a __INLINE_CODE_85__ option.

__INLINE_CODE_86__

This is a class that generates snapshot's name based on the story (kind, story & filename) and vice versa.

Example:

Let's say we wanted to create a test function for shallow && multi-file snapshots:

__CODE_BLOCK_42__

__INLINE_CODE_87__

Enables Jest __INLINE_CODE_88__ callback in the StoryShots tests for async testing. See StoryShots for async rendered components for more info.

Story Parameters

__INLINE_CODE_89__

Some stories are difficult or impossible to snapshot, such as those covering components that use external DOM-modifying libraries, and those that deliberately throw errors. It is possible to skip stories like these by giving them a parameter of __INLINE_CODE_90__. There is also a shorthand for this, __INLINE_CODE_91__.

__CODE_BLOCK_43__