
storybook-testing
Storybook 10 testing patterns with Vitest integration, ESM-only distribution, CSF3 typesafe factories, play() interaction tests, Chromatic TurboSnap visual regression, module automocking, accessibility addon testing, and autodocs generation. Use when writing component stories, setting up visual regression testing, configuring Storybook CI pipelines, or migrating from Storybook 9.
- Installs
- 213
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/yonatangross/orchestkit --skill storybook-testing- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads storybook-testing automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Storybook Testing — Storybook 10
Overview
Storybook 10 unifies component testing into a single workflow: interaction tests via play() functions, visual regression via Chromatic TurboSnap, and accessibility audits via the a11y addon — all running through Vitest. Stories are executable test specifications, not just documentation.
What's new in Storybook 10 (vs 9):
- ESM-only enforced — the single breaking change; Node 20.16+ / 22.19+ / 24+ required; 29% smaller install
- Module automocking (
sb.mock) — build-time module mocking, scoped per-project in preview.ts - CSF factories (React, preview) —
defineMain→definePreview→preview.meta()→meta.story()chain - Essential addons in core — viewport, controls, interactions, actions no longer separate deps
- Import path changes —
@storybook/test→storybook/test(old paths still work as aliases) - React Server Component story support — test RSC in isolation
- Vitest 4 support —
experimental-addon-testrenamed toaddon-vitest
When to use this skill:
- Writing component stories in CSF3 format with TypeScript
- Setting up interaction tests with
play()functions - Configuring Chromatic visual regression with TurboSnap
- Using module automocking at the story level
- Running accessibility tests in CI via the a11y addon
- Generating living documentation with autodocs
- Migrating from Storybook 9 to 10
Quick Reference
| Rule | Impact | Description |
|---|---|---|
storybook-csf3-factories | HIGH | Typesafe CSF3 story factories with satisfies Meta |
storybook-play-functions | CRITICAL | Interaction testing with play() and @storybook/test |
storybook-vitest-integration | HIGH | Run stories as Vitest tests via @storybook/addon-vitest |
storybook-chromatic-turbosnap | HIGH | TurboSnap reduces snapshot cost 60-90% |
storybook-sb-mock | HIGH | Story-level module mocking with sb.mock |
storybook-a11y-testing | CRITICAL | Automated axe-core accessibility scans in CI |
storybook-autodocs | MEDIUM | Auto-generated docs from stories |
Storybook Testing Pyramid
┌──────────────┐
│ Visual │ Chromatic TurboSnap
│ Regression │ (snapshot diffs)
├──────────────┤
│ Accessibility│ @storybook/addon-a11y
│ (a11y) │ (axe-core scans)
├──────────────┤
│ Interaction │ play() functions
│ Tests │ (@storybook/test)
├──────────────┤
│ Unit Tests │ Vitest + storybookTest
│ (stories) │ plugin
└──────────────┘
Each layer catches different defects: unit tests validate logic, interaction tests verify user flows, a11y tests catch accessibility violations, and visual tests catch unintended UI regressions.
Quick Start
CSF3 Story with Play Function
// Button.stories.tsx
import type { Meta, StoryObj } from '@storybook/react'
import { expect, fn, userEvent, within } from 'storybook/test'
import { Button } from './Button'
const meta = {
component: Button,
args: {
onClick: fn(),
},
} satisfies Meta<typeof Button>
export default meta
type Story = StoryObj<typeof meta>
export const Primary: Story = {
args: {
label: 'Click me',
variant: 'primary',
},
play: async ({ canvasElement, args }) => {
const canvas = within(canvasElement)
const button = canvas.getByRole('button', { name: /click me/i })
await userEvent.click(button)
await expect(args.onClick).toHaveBeenCalledOnce()
await expect(button).toHaveStyle({ backgroundColor: 'rgb(37, 99, 235)' })
},
}
Vitest Configuration
// vitest.config.ts
import { storybookTest } from '@storybook/addon-vitest/vitest-plugin'
import { defineConfig } from 'vitest/config'
export default defineConfig({
plugins: [storybookTest()],
test: {
setupFiles: ['./vitest.setup.ts'],
},
})
Key Principles
- Stories are tests. Every story with a
play()function is an executable interaction test that runs in Vitest. - CSF3 +
satisfiesfor type safety. Usesatisfies Meta<typeof Component>for full type inference on args and play functions. - Module automocking (SB 10). Register
sb.mock(import(...))in.storybook/preview.ts, configure per-story withmocked()inbeforeEach. Never usevi.mockin story files. No factory functions —sb.mockis build-time, not runtime. - TurboSnap for CI speed. Only snapshot stories affected by code changes — reduces Chromatic usage by 60-90%.
- Accessibility is not optional. The a11y addon runs axe-core scans on every story and gates CI on violations.
- Living documentation. Autodocs generates prop tables and usage examples directly from stories — no separate docs site needed.
Anti-Patterns (FORBIDDEN)
| Anti-Pattern | Why It Fails | Use Instead |
|---|---|---|
CSF2 Template.bind({}) | Deprecated, no type inference, will be removed in SB 11 | CSF3 object stories with satisfies |
@storybook/test-runner package | Deprecated since Storybook 9 | @storybook/addon-vitest |
vi.mock() in story files | Leaks between stories, breaks isolation | Register sb.mock(import(...)) in preview.ts, configure with mocked() in beforeEach |
| Full Chromatic snapshots on every PR | Expensive and slow | TurboSnap with onlyChanged: true |
| Manual accessibility checking | Misses violations, not repeatable | @storybook/addon-a11y in CI pipeline |
| Separate documentation site | Drifts from actual component behavior | Autodocs with tags: ['autodocs'] |
| Testing implementation details | Brittle, breaks on refactors | Test user-visible behavior via play() |
| CJS imports in stories | ESM-only since SB 9/10 | Use ESM imports, set "module": "ESNext" in tsconfig |
Storybook MCP Integration (addon-mcp)
When @storybook/addon-mcp is installed, agents can run tests and preview stories via MCP instead of CLI. This enables the generate → test → self-heal loop.
MCP Tools for Testing
| Tool | Purpose |
|---|---|
run-story-tests | Run component + a11y tests via MCP, returns pass/fail + violation details |
preview-stories | Returns preview URLs for visual verification in chat |
get-storybook-story-instructions | Guidance on writing effective stories + interaction tests |
Agent Testing Loop
# 1. Generate component + CSF3 story
# 2. Run tests via MCP
results = run-story-tests(
stories=[{ "storyId": "button--primary" }],
a11y=True
)
# 3. If failures: read violations, fix, retry (max 3)
# 4. Preview in chat for visual confirmation
preview-stories(stories=[{ "storyId": "button--primary" }])
Setup
npx storybook add @storybook/addon-mcp # current: 0.6.0, Apr 2026
# Enable docs toolset in .storybook/main.ts:
# componentsManifest: true # was experimentalComponentsManifest (SB 10.3 rename, default-on)
npx mcp-add --type http --url "http://localhost:6006/mcp" --scope project
See storybook-mcp-integration skill for full tool reference and patterns.
References
references/storybook-migration-guide.md— Migration path from Storybook 9 to 10references/storybook-ci-strategy.md— CI pipeline configuration for visual, interaction, and a11y testingreferences/storybook-addon-ecosystem.md— Essential addons for Storybook 10 in 2026
Related Skills
storybook-mcp-integration— Storybook MCP tools: component discovery, testing, previewsreact-server-components-framework— React 19 + Next.js 16 patterns (component architecture)accessibility— Broader accessibility patterns beyond Storybookdevops-deployment— CI/CD pipeline patterns for automated testing
FAQ
What does the storybook-testing skill do?
Storybook 10 testing patterns with Vitest integration, ESM-only distribution, CSF3 typesafe factories, play() interaction tests, Chromatic TurboSnap visual regression, module automocking, accessibility addon testing, and autodocs generation. Use when writing component stories, setting up visual regression testing, configuring Storybook CI pipelines, or migrating from Storybook 9.
How do I install storybook-testing?
Run npx skills add https://github.com/yonatangross/orchestkit --skill storybook-testing in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/storybook-testing/ (personal) or .claude/skills/storybook-testing/ (project).
Which AI agents can use storybook-testing?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is storybook-testing safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains storybook-testing?
It is published by yonatangross in yonatangross/orchestkit. It has 213 recorded installs.
More from yonatangross/orchestkit
devops-deployment
yonatangross/orchestkit
Use when setting up CI/CD pipelines, containerizing applications, deploying to Kubernetes, or writing infrastructure as code. DevOps & Deployment covers GitHub Actions, Docker, Helm, and Terraform patterns.
responsive-patterns
yonatangross/orchestkit
Responsive design with Container Queries, fluid typography, cqi/cqb units, subgrid, intrinsic layouts, foldable devices, and mobile-first patterns for React applications. Use when building responsive layouts or container queries.
architecture-decision-record
yonatangross/orchestkit
ADR templates in the Nygard format with context, decision, consequences, and alternatives. Use when writing ADRs, recording an architectural decision, or evaluating options.
ui-components
yonatangross/orchestkit
UI component library patterns for shadcn/ui and Radix Primitives. Use when building accessible component libraries, customizing shadcn components, using Radix unstyled primitives, or creating design system foundations.
rag-retrieval
yonatangross/orchestkit
Retrieval-Augmented Generation patterns for grounded LLM responses. Use when building RAG pipelines, embedding documents, implementing hybrid search, contextual retrieval, HyDE, agentic RAG, multimodal RAG, query decomposition, reranking, or pgvector search.
zustand-patterns
yonatangross/orchestkit
Reference for Zustand 5.x state management including slices, middleware, Immer, useShallow, persistence, selectors, and devtools integration. Documents 7 core patterns with TypeScript examples and anti-patterns. Use when building React state management with Zustand instead of Redux.
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work