Storybook · Writing and testing · all subjects

stories

88 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Angular enforce required props using preview.type

If you wish to have required props enforced in Angular stories, you can explicitly provide the component's props type to preview.type as shown in the following example: const meta = preview.type<{ args: MyComponentProps }>().meta({ component: 'MyComponent' });

Web Components TypeScript support limitations in CSF 3

CSF 3 offers basic TypeScript support for web components, but it does not infer component types and provides no type generics for Meta and StoryObj.

CSF Next requires custom elements declared in HTMLElementTagNameMap

CSF Next is able to infer types for web components, but only if the custom element is declared in the global HTMLElementTagNameMap interface. You can do this by adding a declaration like: declare global { interface HTMLElementTagNameMap { 'my-element': MyElement; } }

Vitest addon installation command

To install and configure the Vitest addon and Vitest, run a command that will handle the installation and configuration. Refer to the Vitest addon documentation for full installation instructions including project requirements.

Snapshot tests for rendered markup comparison

Snapshot tests compare the rendered markup of a story against a known baseline. They are helpful in scenarios like identifying markup changes that trigger rendering errors, though other testing types typically provide more coverage with less effort.

CI setup for Storybook Test with Vitest

To run Storybook Test in CI, add a script to package.json: `"test-storybook": "vitest --project=storybook"`. This assumes you have a Vitest project called storybook, which is the default configuration when installing Storybook Test. If renamed, adjust the script accordingly.

GitHub Actions workflow for Storybook Tests

Example GitHub Actions workflow for running Storybook tests: ```yaml name: Storybook Tests on: [push] jobs: test: runs-on: ubuntu-latest container: image: mcr.microsoft.com/playwright:v1.58.2-noble steps: - uses: actions/checkout@v4 - name: Setup Node uses: actions/setup-node@v4 with: node-version: 22.12.0 - name: Install dependencies run: npm ci - name: Run tests run: npm run test-storybook ``` Storybook Test uses Playwright to render stories by default. Use a machine image with Playwright already installed for the fastest experience.

Code coverage in Storybook Test

In Storybook Test, coverage is displayed as a summary in the testing widget. Clicking the coverage summary opens a full, interactive report. Coverage analysis is turned off by default because it can slow down test runs. Activate coverage by checking the coverage checkbox in the testing widget.

Coverage report interpretation goals

The goal of coverage is not to achieve 100% coverage and fill every gap, but rather to have a barometer to judge code and test changes. Coverage gaps should inform you of key states or interactions that are untested. For example, in a prototype you might skip testing altogether, whereas in a critical app you might want comprehensive coverage.

Coverage in CI should include all project tests

When running coverage in CI, run all tests in your project (not just Storybook tests) to ensure the coverage report is most accurate. Use `yarn test --coverage` instead of `yarn test-storybook --coverage` to account for all tests in your project, not just stories written.

Stories reusable in other testing tools

Stories are made to be reusable so you can use them as test cases in popular testing tools. Stories can be imported within Playwright or Cypress end-to-end tests, and reused in traditional testing environments like Vitest or Jest.

Testing widget features

Once Storybook Test is set up, a testing widget appears at the bottom of the sidebar. After running tests, test status indicators appear on sidebar items. The testing widget includes watch mode button (eye icon) and checkboxes for accessibility and coverage. Many tests can be debugged with an addon panel.

Test-runner as alternative testing method

If you cannot use the Vitest addon in your project, you can still run tests using the test-runner.

Stories as test cases for UI components

Storybook stories serve as test cases for UI components in their various states and configurations. With Storybook, you can develop and test components simultaneously in multiple ways with instant feedback.

Storybook Test uses Vitest addon to run component tests

Storybook Test enables real-time testing of stories through the Vitest addon. The addon uses a Vitest plugin to automatically transform stories into real Vitest tests, which are then run with Vitest's browser mode.

Watch mode for instant test feedback

Watch mode watches your code (either component source or tests) for changes and automatically re-runs only the relevant tests. Activate watch mode by pressing the watch mode button (the eye icon) in the testing widget. It is perfect for test-driven development.

Component test definition

A component test renders a component in the browser for high fidelity, simulates a user interacting with actual UI like an end-to-end test, only tests a unit (like a single component) of UI, and can reach into the implementation to mock things or manipulate data like a unit test.

Render tests are smoke tests for stories

A basic story is a smoke test called a render test. The test passes when the story renders successfully and fails when it errors. Render tests capture key UI states depending on component complexity.

Visual tests with snapshot comparison

Visual tests allow you to take snapshots of every story and compare those snapshots to baselines (last known good snapshots). This checks both appearance and a large subset of component functionality without writing or maintaining test code. Storybook supports cross-browser visual testing natively using Chromatic, a cloud service made by the Storybook team.

No story syntax changes between test-runner and Vitest addon

You do not have to change how you write your stories when migrating from the test-runner to the Vitest addon.

Node.js and TypeScript version requirements for Storybook 9

Storybook 9 requires Node.js 20 or higher and TypeScript 4.9 or higher.

Story naming and structure guidelines

Use clear story names that describe the scenario, such as 'Error state after failed submit'. Group related variants logically and avoid duplicating stories. Use semantic roles and labels for accessibility testing.

Story writing best practices: coverage and interactivity

Write stories that cover every distinct piece of business logic and state a component can reach, including happy paths, error/edge states, loading states, permissions/roles, empty states, and prop/context variations. For interactive components, add interaction tests using play functions with testing utilities (fn, userEvent, expect) to simulate key user flows like clicking buttons, typing, keyboard navigation, form submission, and async responses.

Test utility imports from storybook/test

Test utilities like fn should be imported from 'storybook/test', not from '@storybook/test'. The import statement should be: import { fn } from 'storybook/test';

Meta and StoryObj imports from framework package

In Storybook 9, Meta and StoryObj should be imported from the framework package, not from the renderer package. The import statement should be: import { Meta, StoryObj } from '{{FRAMEWORK}}';

React Native uses .rnstorybook directory

React Native projects use the .rnstorybook directory instead of the .storybook directory for Storybook configuration.

Story variants to cover for PlanCard

When writing stories for PlanCard, cover at least three variants: default, popular (highlighted), and many-features variants.

Story updates vs component changes

When aligning stories with component props, prefer fixing the stories rather than changing the component itself, only modify the component if necessary for correctness.

Give your agent this brain