mirror of
https://github.com/storybookjs/storybook.git
synced 2025-04-04 18:41:06 +08:00
feedback addressed
This commit is contained in:
jonniebigodes
parent
c5c64b4984
commit
a7ada3b979
@ -3,18 +3,14 @@
|
||||
|
||||
const { injectAxe, checkA11y } = require('axe-playwright');
|
||||
|
||||
/*
|
||||
* See https://storybook.js.org/docs/react/writing-tests/test-runner#test-hook-api-experimental
|
||||
* to learn more about the test-runner hooks API.
|
||||
*/
|
||||
module.exports = {
|
||||
/* Hook to execute before a story is rendered.
|
||||
* The page argument is the Playwright's page object for the story.
|
||||
* The context argument is a Storybook object containing the story's id, title, and name.
|
||||
*/
|
||||
async preRender(page, context) {
|
||||
await injectAxe(page);
|
||||
},
|
||||
/* Hook to execute after a story is rendered.
|
||||
* The page argument is the Playwright's page object for the story
|
||||
* The context argument is a Storybook object containing the story's id, title, and name.
|
||||
*/
|
||||
async postRender(page, context) {
|
||||
await checkA11y(page, context.title.includes('Page') ? undefined : '#root');
|
||||
},
|
||||
|
||||
@ -5,18 +5,14 @@ import { injectAxe, checkA11y } from 'axe-playwright';
|
||||
|
||||
import type { TestRunnerConfig } from '@storybook/test-runner';
|
||||
|
||||
/*
|
||||
* See https://storybook.js.org/docs/react/writing-tests/test-runner#test-hook-api-experimental
|
||||
* to learn more about the test-runner hooks API.
|
||||
*/
|
||||
const a11yConfig: TestRunnerConfig = {
|
||||
/* Hook to execute before a story is rendered.
|
||||
* The page argument is the Playwright's page object for the story.
|
||||
* The context argument is a Storybook object containing the story's id, title, and name.
|
||||
*/
|
||||
async preRender(page, context) {
|
||||
await injectAxe(page);
|
||||
},
|
||||
/* Hook to execute after a story is rendered.
|
||||
* The page argument is the Playwright's page object for the story
|
||||
* The context argument is a Storybook object containing the story's id, title, and name.
|
||||
*/
|
||||
async postRender(page, context) {
|
||||
await checkA11y(page, context.title.includes('Page') ? undefined : '#root');
|
||||
},
|
||||
|
||||
@ -37,7 +37,7 @@ export const Template = (args, { argTypes }) => ({
|
||||
delay: 100,
|
||||
});
|
||||
|
||||
// See https://storybook.js.org/docs/angular/essentials/actions#automatically-matching-args to learn how to setup logging in the Actions panel
|
||||
// See https://storybook.js.org/docs/vue/essentials/actions#automatically-matching-args to learn how to setup logging in the Actions panel
|
||||
await userEvent.click(canvas.getByRole('button'));
|
||||
|
||||
// 👇 Assert DOM structure
|
||||
|
||||
@ -44,7 +44,7 @@ export const Template = (args) => ({
|
||||
delay: 100,
|
||||
});
|
||||
|
||||
// See https://storybook.js.org/docs/angular/essentials/actions#automatically-matching-args to learn how to setup logging in the Actions panel
|
||||
// See https://storybook.js.org/docs/vue/essentials/actions#automatically-matching-args to learn how to setup logging in the Actions panel
|
||||
await userEvent.click(canvas.getByRole('button'));
|
||||
|
||||
// 👇 Assert DOM structure
|
||||
|
||||
@ -8,13 +8,13 @@ Accessibility tests audit the rendered DOM against a set of heuristics based on
|
||||
|
||||
|
||||
|
||||
## Accessibility testing with a11y addon
|
||||
## Accessibility checks with a11y addon
|
||||
|
||||
Storybook provides an official [a11y addon](https://storybook.js.org/addons/@storybook/addon-a11y). Powered by Deque's [axe-core](https://github.com/dequelabs/axe-core), which automatically catches up to [57% of WCAG issues](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/).
|
||||
|
||||
### Set up the a11y addon
|
||||
|
||||
If you want to run accessibility tests using the [addon](https://storybook.js.org/addons/@storybook/addon-a11y/), you'll need additional steps to set it up. Documented below is our recommendation.
|
||||
If you want to check accessibility for your stories using the [addon](https://storybook.js.org/addons/@storybook/addon-a11y/), you'll need to install it and add it to your Storybook.
|
||||
|
||||
Run the following command to install the addon.
|
||||
|
||||
@ -158,7 +158,9 @@ Disable accessibility testing for stories or components by adding the following
|
||||
|
||||
## Automate accessibility tests with test runner
|
||||
|
||||
Accessibility testing with Storybook shortens the feedback loop, which means you fix issues faster. You can then integrate these accessibility tests into your test automation pipeline using the Storybook [test runner](./test-runner.md#test-hook-api-experimental) and [axe-playwright](https://github.com/abhinaba-ghosh/axe-playwright).
|
||||
The most accurate way to check accessibility is manually on real devices. However, you can use automated tools to catch common accessibility issues. For example, [Axe](https://www.deque.com/axe/), on average, catches upwards to [57% of WCAG issues](https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/) automatically.
|
||||
|
||||
These tools work by auditing the rendered DOM against heuristics based on [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/) rules and other industry-accepted best practices. You can then integrate these tools into your test automation pipeline using the Storybook [test runner](./test-runner.md#test-hook-api-experimental) and [axe-playwright](https://github.com/abhinaba-ghosh/axe-playwright).
|
||||
|
||||
### Setup
|
||||
|
||||
@ -196,9 +198,9 @@ Add a new [configuration file](./test-runner.md#test-hook-api-experimental) insi
|
||||
|
||||
</div>
|
||||
|
||||
By default, Axe assumes that you're testing a page and checks whether you've specified an `<h1>` and `<main>`. However, most of your stories are for components and not pages. That's why we use the `context.title.includes('Page')` check to [enable/disable](https://github.com/abhinaba-ghosh/axe-playwright#context-optional) Axe's page-level rules.
|
||||
By default, Axe assumes that you're testing a page and checks whether you've specified an `<h1>` and `<main>`. However, not allof your stories are for page-level components. That's why we use the `context.title.includes('Page')` check to [enable/disable](https://github.com/abhinaba-ghosh/axe-playwright#context-optional) Axe's page-level rules.
|
||||
|
||||
When you execute the test runner (i.e., `yarn test-storybook`), it will run the accessibility audit and any [interaction tests](./interaction-testing.md) you might have configured for each component story.
|
||||
When you execute the test runner (for example, with `yarn test-storybook`), it will run the accessibility audit and any [interaction tests](./interaction-testing.md) you might have configured for each component story.
|
||||
|
||||
|
||||
|
||||
@ -215,4 +217,4 @@ Browser-based accessibility tests, like found in Storybook, evaluate the rendere
|
||||
- Accessibility tests for accessibility
|
||||
- [Interaction tests](./interaction-testing.md) for user behavior simulation
|
||||
- [Snapshot tests](./snapshot-testing.md) for rendering errors and warnings
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
@ -69,7 +69,7 @@ Update your test script to include the configuration file:
|
||||
|
||||
## Example with Testing Library
|
||||
|
||||
[Testing Library](https://testing-library.com/) is a suite of helper libraries for browser-based interaction tests. With [Component Story Format](../api/csf.md), your stories are reusable with Testing Library. Each named export (i.e., a story) is renderable within your testing setup.
|
||||
[Testing Library](https://testing-library.com/) is a suite of helper libraries for browser-based interaction tests. With [Component Story Format](../api/csf.md), your stories are reusable with Testing Library. Each named export (in other words, a story) is renderable within your testing setup.
|
||||
|
||||
<div class="aside">
|
||||
|
||||
@ -97,7 +97,7 @@ Once the test runs, it loads the story and renders it. [Testing Library](https:/
|
||||
|
||||
## Example with Cypress
|
||||
|
||||
[Cypress](https://www.cypress.io/) is an end-to-end testing framework. It enables you to test a complete instance of your application by simulating user behavior. With Component Story Format, your stories are reusable with Cypress. Each named export (i.e., a story) is renderable within your testing setup.
|
||||
[Cypress](https://www.cypress.io/) is an end-to-end testing framework. It enables you to test a complete instance of your application by simulating user behavior. With Component Story Format, your stories are reusable with Cypress. Each named export (in other words, a story) is renderable within your testing setup.
|
||||
|
||||
An example of an end-to-end test with Cypress and Storybook is testing a login component for the correct inputs. For example, if you had the following story:
|
||||
|
||||
@ -139,7 +139,7 @@ When Cypress runs your test, it loads Storybook's isolated iframe and checks if
|
||||
|
||||
## Example with Playwright
|
||||
|
||||
[Playwright](https://playwright.dev/) is a browser automation tool and end-to-end testing framework from Microsoft. It offers cross-browser automation, mobile testing with device emulation, and headless testing. With Component Story Format, your stories are reusable with Playwright. Each named export (i.e., a story) is renderable within your testing setup.
|
||||
[Playwright](https://playwright.dev/) is a browser automation tool and end-to-end testing framework from Microsoft. It offers cross-browser automation, mobile testing with device emulation, and headless testing. With Component Story Format, your stories are reusable with Playwright. Each named export (in other words, a story) is renderable within your testing setup.
|
||||
|
||||
A real-life scenario of user flow testing with Playwright would be how to test a login form for validity. For example, if you had the following story already created:
|
||||
|
||||
@ -185,4 +185,4 @@ Once you execute Playwright, it opens a new browser window, loads Storybook's is
|
||||
- [Accessibility tests](./accessibility-testing.md) for accessibility
|
||||
- [Interaction tests](./interaction-testing.md) for user behavior simulation
|
||||
- [Snapshot tests](./snapshot-testing.md) for rendering errors and warnings
|
||||
- Import stories in other tests for other tools
|
||||
- Import stories in other tests for other tools
|
||||
@ -6,7 +6,7 @@ As you build more complex UIs like pages, components become responsible for more
|
||||
|
||||
In a nutshell, you start by supplying the appropriate props for the initial state of a component. Then simulate user behavior such as clicks and form entries. Finally, check whether the UI and component state update correctly.
|
||||
|
||||
In Storybook, this familiar workflow happens in your browser. That makes it easier to debug failures because you're running tests in the same environment as you develop components—the browser.
|
||||
In Storybook, this familiar workflow happens in your browser. That makes it easier to debug failures because you're running tests in the same environment as you develop components: the browser.
|
||||
|
||||
|
||||
|
||||
@ -16,8 +16,8 @@ You start by writing a [**story**](../writing-stories/introduction.md) to set up
|
||||
|
||||
- The [`play`](../writing-stories/play-function.md) function is a small snippet of code that runs after a story finishes rendering. You can use this to test user workflows.
|
||||
- The test is written using Storybook-instrumented versions of [Jest](https://jestjs.io/) and [Testing Library](https://testing-library.com/).
|
||||
- [`@storybook/addon-interactions`](https://storybook.js.org/addons/@storybook/addon-interactions/) visualizes the test in Storybook and playback interface for convenient browser-based debugging.
|
||||
- [`@storybook/test-runner`](https://github.com/storybookjs/test-runner) is a standalone utility—powered by [Playwright](https://playwright.dev/)—that executes all your interactions tests and catches broken stories.
|
||||
- [`@storybook/addon-interactions`](https://storybook.js.org/addons/@storybook/addon-interactions/) visualizes the test in Storybook and provides a playback interface for convenient browser-based debugging.
|
||||
- [`@storybook/test-runner`](https://github.com/storybookjs/test-runner) is a standalone utility—powered by [Playwright](https://playwright.dev/)—that executes all of your interactions tests and catches broken stories.
|
||||
|
||||
## Set up the interactions addon
|
||||
|
||||
@ -84,7 +84,7 @@ Once the story loads in the UI, it simulates the user's behavior and verifies th
|
||||
|
||||
## API for user-events
|
||||
|
||||
Under the hood, Storybook’s interaction addon mirrors Testing Library’s `user-events` API. If you’re familiar with [Testing Library](https://testing-library.com/), you should be at home in Storybook.
|
||||
Under the hood, Storybook’s interaction addon mirrors Testing Library’s [`user-events`](https://testing-library.com/docs/user-event/intro/) API. If you’re familiar with [Testing Library](https://testing-library.com/), you should be at home in Storybook.
|
||||
|
||||
Below is an abridged API for user-event. For more, check out the [official user-event docs](https://testing-library.com/docs/ecosystem-user-event/).
|
||||
|
||||
@ -161,4 +161,4 @@ Interaction tests can be expensive to maintain when applied wholesale to every c
|
||||
- [Accessibility tests](accessibility-testing.md) for accessibility
|
||||
- Interaction tests for user behavior simulation
|
||||
- [Snapshot tests](./snapshot-testing.md) for rendering errors and warnings
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
@ -10,7 +10,7 @@ That means stories are a pragmatic starting point for your UI testing strategy.
|
||||
|
||||
The simplest testing method is manual “spot checking”. You run Storybook locally, then eyeball every story to verify its appearance and behavior. [Publish](../sharing/publish-storybook.md) your Storybook online to share reproductions and get teammates involved.
|
||||
|
||||
To test a component in isolation, you often have to mock data, dependencies or even network requests. Check out our guide on [mocking in Storybook](../writing-stories/build-pages-with-storybook.md#mocking-connected-components) for more info.
|
||||
To test a component in isolation, you often have to mock data, dependencies, or even network requests. Check out our guide on [mocking in Storybook](../writing-stories/build-pages-with-storybook.md#mocking-connected-components) for more info.
|
||||
|
||||
Storybook also comes with tools, [test runners](./test-runner.md), and [handy integrations](./importing-stories-in-tests.md) with the larger JavaScript ecosystem to expand your UI test coverage. These docs detail how you can use Storybook for UI testing.
|
||||
|
||||
@ -19,4 +19,4 @@ Storybook also comes with tools, [test runners](./test-runner.md), and [handy in
|
||||
- [**Accessibility tests**](./accessibility-testing.md) catch usability issues related to visual, hearing, mobility, cognitive, speech, or neurological disabilities
|
||||
- [**Interaction tests**](./interaction-testing.md) verify component functionality by simulating user behaviour, firing events, and ensuring that state is updated as expected
|
||||
- [**Snapshot tests**](./snapshot-testing.md) detect changes in the rendered markup to surface rendering errors or warnings
|
||||
- [**Import stories in other tests**](./importing-stories-in-tests.md) to QA even more UI characteristics
|
||||
- [**Import stories in other tests**](./importing-stories-in-tests.md) to QA even more UI characteristics
|
||||
@ -64,7 +64,7 @@ npm i -D @storybook/addon-storyshots-puppeteer puppeteer
|
||||
yarn add @storybook/addon-storyshots-puppeteer puppeteer
|
||||
```
|
||||
|
||||
Next, update your test file (e.g., `storybook.test.js`) to the following:
|
||||
Next, update your test file (for example, `storybook.test.js`) to the following:
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
@ -115,4 +115,4 @@ Visual tests capture images of stories and compare them against image baselines.
|
||||
- [Accessibility tests](./accessibility-testing.md) for accessibility
|
||||
- [Interaction tests](./interaction-testing.md) for user behavior simulation
|
||||
- Snapshot tests for rendering errors and warnings
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
@ -5,15 +5,15 @@ title: 'Test runner'
|
||||
Storybook test runner turns all of your stories into executable tests. It is powered by [Jest](https://jestjs.io/) and [Playwright](https://playwright.dev/).
|
||||
|
||||
- For those [without a play function](../writing-stories/introduction.md): it verifies whether the story renders without any errors.
|
||||
- For those [with a play function](../writing-stories/play-function.md): it also checks for errors in the play function and all assertions passed.
|
||||
- For those [with a play function](../writing-stories/play-function.md): it also checks for errors in the play function and that all assertions passed.
|
||||
|
||||
These tests run in a live browser and can be executed via the [command line](#cli-options) or your [CI server](#set-up-ci-to-run-tests).
|
||||
|
||||
## Setup
|
||||
|
||||
The test runner is a standalone, framework-agnostic addon that runs parallel to your Storybook. You will need to take some additional steps to set it up properly. Detailed below is our recommendation to configure and execute it.
|
||||
The test-runner is a standalone, framework-agnostic utility that runs parallel to your Storybook. You will need to take some additional steps to set it up properly. Detailed below is our recommendation to configure and execute it.
|
||||
|
||||
Run the following command to install the addon and the required dependencies.
|
||||
Run the following command to install it and the required dependencies.
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
@ -51,10 +51,10 @@ Start your Storybook with:
|
||||
<!-- prettier-ignore-end -->
|
||||
|
||||
<div class="aside">
|
||||
💡 Storybook's test runner requires a running Storybook instance to run all the existing tests.
|
||||
💡 Storybook's test runner requires either a locally running Storybook instance or a published Storybook to run all the existing tests.
|
||||
</div>
|
||||
|
||||
Finally, open a new terminal window and run the test runner with:
|
||||
Finally, open a new terminal window and run the test-runner with:
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
@ -73,8 +73,8 @@ Test runner offers zero-config support for Storybook. However, you can run `test
|
||||
|
||||
### CLI Options
|
||||
|
||||
The test runner is powered by [Jest](https://jestjs.io/) and accepts all its [CLI options](https://jestjs.io/docs/cli) (e.g., `--watch`, `--maxWorkers`).
|
||||
If you're already using any of those flags in your project, you should be able to migrate them into Storybook's test runner without any issues. Listed below are all the available flags and examples of using them.
|
||||
The test-runner is powered by [Jest](https://jestjs.io/) and accepts a subset of its [CLI options](https://jestjs.io/docs/cli) (for example, `--watch`, `--maxWorkers`).
|
||||
If you're already using any of those flags in your project, you should be able to migrate them into Storybook's test-runner without any issues. Listed below are all the available flags and examples of using them.
|
||||
|
||||
| Options | Description |
|
||||
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
|
||||
@ -105,7 +105,7 @@ If you're already using any of those flags in your project, you should be able t
|
||||
|
||||
### Run tests against a deployed Storybook
|
||||
|
||||
By default, the test runner assumes that you're running it against a locally served Storybook on port `6006`. If you want to define a target URL to run against deployed Storybooks, you can use the `--url` flag or set the `TARGET_URL` environment variable. For example:
|
||||
By default, the test-runner assumes that you're running it against a locally served Storybook on port `6006`. If you want to define a target URL to run against deployed Storybooks, you can use the `--url` flag or set the `TARGET_URL` environment variable. For example:
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
@ -121,21 +121,7 @@ By default, the test runner assumes that you're running it against a locally ser
|
||||
|
||||
## Set up CI to run tests
|
||||
|
||||
You can also configure the test runner to run tests on a CI environment. Documented below are some recipes to help you get started.
|
||||
|
||||
### Run against deployed Storybooks
|
||||
|
||||
If you're already using a CI provider (e.g., [GitHub Actions](https://github.com/features/actions), [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines/), [CircleCI](https://circleci.com/)) to build and publish your Storybook, you can configure your environment and run the test runner against the deployed version. Here's a recipe that uses third-party libraries (i.e., [concurrently](https://www.npmjs.com/package/concurrently), [http-server](https://www.npmjs.com/package/http-server), and [wait-on](https://www.npmjs.com/package/wait-on)).
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<CodeSnippets
|
||||
paths={[
|
||||
'common/storybook-test-runner-local-build-workflow.yml.mdx',
|
||||
]}
|
||||
/>
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
You can also configure the test-runner to run tests on a CI environment. Documented below are some recipes to help you get started.
|
||||
|
||||
### Run against deployed Storybooks via Github Actions deployment
|
||||
|
||||
@ -153,13 +139,27 @@ If you're publishing your Storybook with services such as [Vercel](https://verce
|
||||
|
||||
<div class="aside">
|
||||
|
||||
💡 The published Storybook must be publicly available for this example to work. We recommend running the test server using the recipe [above](#run-against-locally-built-storybooks) if it requires authentication.
|
||||
💡 The published Storybook must be publicly available for this example to work. We recommend running the test server using the recipe [below](#run-against-non-deployed-storybooks) if it requires authentication.
|
||||
|
||||
</div>
|
||||
|
||||
### Run against non-deployed Storybooks
|
||||
|
||||
You can use your CI provider (for example, [GitHub Actions](https://github.com/features/actions), [GitLab Pipelines](https://docs.gitlab.com/ee/ci/pipelines/), [CircleCI](https://circleci.com/)) to build and run the test runner against your built Storybook. Here's a recipe that relies on third-party libraries, that is to say, [concurrently](https://www.npmjs.com/package/concurrently), [http-server](https://www.npmjs.com/package/http-server), and [wait-on](https://www.npmjs.com/package/wait-on) to build Storybook and run tests with the test-runner.
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
<CodeSnippets
|
||||
paths={[
|
||||
'common/storybook-test-runner-local-build-workflow.yml.mdx',
|
||||
]}
|
||||
/>
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
|
||||
### What's the difference between Chromatic and Test runner?
|
||||
|
||||
Test Runner is a generic testing tool that can run locally or on CI and be configured or extended to run all kinds of tests.
|
||||
The test-runner is a generic testing tool that can run locally or on CI and be configured or extended to run all kinds of tests.
|
||||
|
||||
[Chromatic](https://www.chromatic.com/) is a cloud-based service that runs [visual](./visual-testing.md) and [interaction tests](./interaction-testing.md) (and soon accessibility tests) without setting up the test runner. It also syncs with your git provider and manages access control for private projects.
|
||||
|
||||
@ -172,9 +172,9 @@ However, you might want to pair the test runner and Chromatic in some cases.
|
||||
|
||||
### Test hook API (experimental)
|
||||
|
||||
The test runner renders a story and executes its [play function](writing-stories/play-function.md) if one exists. However, certain behaviors are impossible to achieve via the play function, which executes in the browser. For example, if you want the test runner to take visual snapshots for you, this is possible via Playwright/Jest but must be executed in Node.
|
||||
The test-runner renders a story and executes its [play function](writing-stories/play-function.md) if one exists. However, certain behaviors are impossible to achieve via the play function, which executes in the browser. For example, if you want the test-runner to take visual snapshots for you, this is possible via Playwright/Jest but must be executed in Node.
|
||||
|
||||
The test runner exports test hooks that can be overridden globally to enable use cases like visual or DOM snapshots. These hooks give you access to the test lifecycle before and after the story is rendered.
|
||||
The test-runner exports test hooks that can be overridden globally to enable use cases like visual or DOM snapshots. These hooks give you access to the test lifecycle before and after the story is rendered.
|
||||
Listed below are the available hooks and an overview of how to use them.
|
||||
|
||||
| Hook | Description |
|
||||
@ -208,7 +208,7 @@ To enable the hooks API, you'll need to add a new configuration file inside your
|
||||
|
||||
</div>
|
||||
|
||||
When the test runner executes, your existing tests will go through the following lifecycle:
|
||||
When the test-runner executes, your existing tests will go through the following lifecycle:
|
||||
|
||||
- The `setup` function is executed before all the tests run.
|
||||
- The context object is generated containing the required information.
|
||||
@ -219,7 +219,11 @@ When the test runner executes, your existing tests will go through the following
|
||||
|
||||
### Stories.json mode
|
||||
|
||||
When testing a local Storybook, the test runner transforms your story files into tests. For a remote Storybook, it uses the Storybook's [stories.json](../configure/overview.md#feature-flags) file (a static index of all the stories) to run the tests. Suppose you run into a situation where the local and remote Storybooks appear out of sync, or you might not even have access to the code. In that case, the `stories.json` file is guaranteed to be the most accurate representation of the deployed Storybook you are testing. To test a local Storybook using this feature, use the `--stories-json` flag as follows:
|
||||
The test-runner transforms your story files into tests when testing a local Storybook. For a remote Storybook, it uses the Storybook's [stories.json](../configure/overview.md#feature-flags) file (a static index of all the stories) to run the tests.
|
||||
|
||||
#### Why?
|
||||
|
||||
Suppose you run into a situation where the local and remote Storybooks appear out of sync, or you might not even have access to the code. In that case, the `stories.json` file is guaranteed to be the most accurate representation of the deployed Storybook you are testing. To test a local Storybook using this feature, use the `--stories-json` flag as follows:
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
@ -238,7 +242,7 @@ When testing a local Storybook, the test runner transforms your story files into
|
||||
|
||||
</div>
|
||||
|
||||
To disable it, use the `--no-stories-json` flag:
|
||||
If you need to disable it, use the `--no-stories-json` flag:
|
||||
|
||||
<!-- prettier-ignore-start -->
|
||||
|
||||
@ -251,6 +255,10 @@ To disable it, use the `--no-stories-json` flag:
|
||||
|
||||
<!-- prettier-ignore-end -->
|
||||
|
||||
#### How do I check if Storybook has a `stories.json` file?
|
||||
|
||||
Stories.json mode requires a `stories.json` file. Open a browser window and navigate to your deployed Storybook instance (for example, `https://your-storybook-url-here.com/stories.json`). You'll see a JSON file that starts with a `"v": 3` key, immediately followed by another key called "stories", which contains a map of story IDs to JSON objects.
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
@ -274,7 +282,7 @@ It might be that Playwright couldn't handle testing the number of stories you ha
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"test-storybook:ci": "concurrently -k -s first -n \"SB,TEST\" -c \"magenta,blue\" \"yarn build-storybook --quiet && npx http-server storybook-static --port 6006 --silent\" \"wait-on tcp:6006 && yarn test-storybook --maxWorkers=2\""
|
||||
"test-storybook:ci": "yarn test-storybook --maxWorkers=2"
|
||||
}
|
||||
}
|
||||
```
|
||||
@ -290,4 +298,4 @@ As the test runner is based on Playwright, you might need to use specific docker
|
||||
- [Accessibility tests](./accessibility-testing.md) for accessibility
|
||||
- [Interaction tests](./interaction-testing.md) for user behavior simulation
|
||||
- [Snapshot tests](./snapshot-testing.md) for rendering errors and warnings
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
@ -50,7 +50,7 @@ View it online at https://www.chromatic.com/build?appId=...&number=1.
|
||||
💡 Before running Chromatic's CLI ensure you have at least two commits added to the repository to prevent build failures, as Chromatic relies on a full Git history graph to establish the baselines. Read more about baselines in Chromatic's <a href="https://www.chromatic.com/docs/branching-and-baselines"> documentation</a>
|
||||
</div>
|
||||
|
||||
When Chromatic finishes, it should have successfully deployed your Storybook and established the baselines (i.e., starting point) for all your component's stories. Additionally, providing you with a link to the published Storybook that you can share with your team to gather feedback.
|
||||
When Chromatic finishes, it should have successfully deployed your Storybook and established the baselines, that is to say, the starting point for all your component's stories. Additionally, providing you with a link to the published Storybook that you can share with your team to gather feedback.
|
||||
|
||||
|
||||
|
||||
@ -79,4 +79,4 @@ Snapshot tests compare the rendered markup of every story against known baseline
|
||||
- [Accessibility tests](./accessibility-testing.md) for accessibility
|
||||
- [Interaction tests](./interaction-testing.md) for user behavior simulation
|
||||
- [Snapshot tests](./snapshot-testing.md) for rendering errors and warnings
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
- [Import stories in other tests](./importing-stories-in-tests.md) for other tools
|
||||
Loading…
x
Reference in New Issue
Block a user