Storybook and Visual Testing: Why Testing Isolated Components Is Not Enough
Key Takeaways
- Storybook has become the standard tool for documenting, developing, and testing UI components in isolation — and that's well deserved
- Visual testing tools integrated with Storybook (Chromatic, Loki, Percy) capture screenshots of isolated components, not assembled pages
- The most dangerous visual regressions occur in component assembly — the interaction between layout, content, and real-world context
- A complete visual testing strategy combines Storybook for components and a framework-agnostic tool for full pages
Visual testing, as defined by the ISTQB (International Software Testing Qualifications Board), refers to "the verification that the user interface of a software application is displayed in accordance with expected visual specifications, by comparing reference screenshots with the current state of the application" (ISTQB Glossary, Visual Testing).
Storybook has won. If you develop UI components in 2026, chances are you use Storybook — or have at least considered it. With over 84,000 stars on GitHub and official support for React, Vue, Angular, Svelte, Web Components, and more, Storybook has established itself as the de facto standard for isolated component development.
And naturally, when teams look for a visual testing solution, they turn to the Storybook ecosystem. Chromatic, created by the Storybook maintainers themselves, is the most obvious choice. Loki offers an open-source alternative. Percy (BrowserStack Visual Reviews) provides a Storybook integration.
These tools work. They capture screenshots of your stories and detect visual changes between builds. But they all share a fundamental limitation that nobody wants to hear: they test components in isolation, not the pages your users actually see.
This article will defend a position some may find iconoclastic: Storybook is an excellent development tool, but visual testing based solely on Storybook gives a false sense of security. For real coverage, you need to test assembled pages — and that's exactly what Storybook doesn't do.
Storybook: the tool everyone uses (and rightly so)
Before criticizing the limits of visual testing via Storybook, let's give it the credit it deserves. Storybook solves a real problem, and it solves it well.
Isolated development
Developing a UI component within the context of your application means navigating an ocean of dependencies. Does your Button component work correctly in all its variants (primary, secondary, danger, disabled)? To verify in your application, you must navigate to the page that uses it, find an application state that displays the variant you want to test, and hope the development data matches the case you want to verify.
Storybook cuts through this Gordian knot. Each component has its stories — predefined instances with specific props — that you can view instantly, with no dependency on the rest of the application. You see your Button in primary, secondary, danger, disabled modes, with short text, long text, with an icon, without an icon — all in a dedicated interface.
Living documentation
Storybook is not just a development tool. It's also a documentation tool. Your stories become the living documentation of your design system. Designers can verify that components match the mockups. Product managers can explore available variants. New developers can understand existing components without reading source code.
This documentation value is real and precious. No static README replaces an interactive instance of each component with its configurable props.
Addons and the ecosystem
Storybook's ecosystem is rich. The a11y addon checks your component accessibility. The viewport addon tests components at different screen sizes. The interactions addon simulates user interactions. And the visual testing addons — Chromatic, Loki, Percy — capture screenshots to detect regressions.
This ecosystem reinforces Storybook's dominant position. The more integrated tools there are, the more reasons to adopt it, and the harder alternatives become to justify.
Storybook visual testing tools: the landscape
Let's review the main options for visual testing via Storybook, with their strengths and limitations.
Chromatic: the official choice
Chromatic is a cloud service created by the Storybook maintainers. Its operation is straightforward: at each build, Chromatic captures screenshots of all your stories in a cloud browser and compares them to previous captures. Differences are presented in a review interface where you can approve or reject each change.
Chromatic's strengths are undeniable. Integration with Storybook is native — no complex configuration. Infrastructure is managed: no browsers to install, no capture servers to maintain. The review interface is excellent, with side-by-side comparison, a slider, and highlighted differences. Composition support allows testing components from multiple Storybooks in a single review.
Chromatic's pricing model is based on snapshots per month. The free plan offers 5,000 snapshots, which is enough for a small project. But for a medium-sized design system with 200 components, 3 viewports, and 5 states per component, you reach 3,000 snapshots per build — exhausting your quota in fewer than two builds. Paid plans start at $149 per month and scale quickly with volume.
Chromatic's fundamental limitation is that it tests what you put in Storybook, not what your users see in your application. If your stories don't reflect real data, real layouts, and real contexts, Chromatic's captures validate a fictional state of your components.
Loki: the open-source alternative
Loki is an open-source visual testing tool for Storybook. It captures screenshots of your stories using headless Chrome or Docker and compares images locally. No cloud service, no subscription.
Loki has the advantage of cost: it's free. But that free status comes with a maintenance cost. You manage the capture infrastructure yourself: installing headless Chrome, managing system fonts, configuring Docker for reproducibility. Rendering differences between your local machine and your CI can generate persistent false positives. The review interface is basic compared to Chromatic's — no built-in team collaboration, no comments on changes, no approval history.
And crucially, Loki shares the same limitation as Chromatic: it tests components in Storybook, not in your application.
Percy (BrowserStack Visual Reviews)
Percy, now integrated into BrowserStack as Visual Reviews, offers a Storybook integration via a dedicated package. It captures stories in the BrowserStack cloud and provides a review interface with team collaboration.
Percy brings the power of BrowserStack's infrastructure: multi-browser testing (Chrome, Firefox, Safari), multiple resolutions, and capture environment stability. CI/CD integration is mature.
Percy's pricing is similar to Chromatic's: based on snapshot count, with a starter plan that works for small projects and becomes expensive at scale. The Team plan starts at $399 per month for 25,000 snapshots.
Like Chromatic and Loki, Percy via Storybook tests components in isolation. Percy also has a "page" mode that can capture full pages, but this feature is separate from the Storybook integration and requires additional configuration scripts.
The fundamental problem: the gap between component and page
Here's where things get interesting. The three tools we just described share an implicit assumption: if each component renders correctly in isolation, the assembled page will render correctly too.
This assumption is false. And that's the heart of the problem.
Components don't live in isolation
A component in Storybook exists in a controlled environment. It has a white background (or your Storybook configuration's background color). It has fixed margins. It receives props you define manually. It has no neighbors pushing it, resizing it, or overlapping it.
In your real application, that same component lives in a complex visual ecosystem. It's in a flex or grid container that imposes size constraints. It's next to other components that influence its positioning. It inherits global styles (CSS reset, variables, fonts) that may differ from Storybook. It receives real data that may be longer, shorter, or in an unexpected format compared to your story props.
Composition regressions
The most insidious visual regressions don't occur in individual components. They occur in the assembly.
A Card component that displays perfectly in Storybook with a 30-character title can break the layout when it receives a 120-character title in the real page. Storybook will never show you this case unless you explicitly created a story with a very long title — and in the majority of design systems, these "edge case" stories don't exist.
A Header component with a fixed height in Storybook can cause overlap with the main content when used in a layout with a notification banner above. Storybook doesn't know about that banner, because the Header is tested in isolation.
A Modal component that displays perfectly centered in Storybook can be partially hidden on mobile when the virtual keyboard is open and the viewport is reduced. Storybook doesn't simulate the virtual keyboard.
A Sidebar with the right width in Storybook can crush the main content when both are in a flex layout and the main content contains fixed-width elements. The conflict doesn't exist in Storybook, because the Sidebar and main content are never tested together.
Rendering context
Beyond spatial composition, the rendering context plays a determining role in component appearance. Inherited styles, theme CSS variables, global media queries, loaded fonts, user system preferences (light/dark mode, text size, reduced motion) — all of this affects your components' rendering.
Storybook tries to reproduce this context via decorators and global parameters. But the reproduction is rarely 100% faithful. System fonts on your development machine aren't the same as those in your user's browser. Storybook CSS variables aren't necessarily synchronized with your application's. Media queries in Storybook emulate viewport size but not device characteristics (pixel density, orientation, color capabilities).
The result: a component can pass all its visual tests in Storybook and present a different visual rendering — sometimes subtly, sometimes dramatically — in your actual application.
The right strategy: components AND pages
The position defended in this article is not that Storybook is useless for visual testing. It's that Storybook alone is insufficient. The right strategy combines two levels of visual testing.
First level: components in Storybook
Use Storybook and a tool like Chromatic to verify your design system components in isolation. This is valuable for the following reasons.
You validate each variant of each component under controlled conditions. You detect regressions in foundational components — buttons, inputs, cards, modals — before they propagate to pages. You maintain up-to-date visual documentation of your design system.
This first level covers "microscopic" regressions: a color change in a button, a modified padding in an input, an icon that changed size.
Second level: assembled pages in the browser
Use a framework-agnostic visual testing tool like Delta-QA to capture your real pages in a real browser. This second level covers "macroscopic" regressions: a broken layout, a component overlapping another, content overflowing, a page scrolling horizontally, a header disappearing on scroll.
This second level is irreplaceable. No Storybook-based tool can provide it, because it requires testing the page in its real context, with real data, real layout, and assembled components.
Complementarity in practice
Concretely, your CI/CD pipeline triggers both levels in parallel. Chromatic (or your Storybook tool of choice) captures your stories and reports component changes. Delta-QA captures your real pages and reports layout changes.
If a CSS change affects a button, Chromatic detects it in the button story, and Delta-QA detects it on all pages that use that button. You see the problem at the component level AND the page level.
If a layout change affects page composition without modifying any individual component, Chromatic sees nothing — all components are identical in isolation — but Delta-QA detects the change in the assembled page.
This complementarity is what constitutes a complete visual testing strategy.
Delta-QA: visual testing of the pages your users actually see
Delta-QA is a no-code visual testing tool that captures your pages in a real browser and compares screenshots between versions. It doesn't replace Storybook or Chromatic. It complements what those tools can't do.
No stories to synchronize
Storybook's biggest hidden cost is story maintenance. Every new component requires new stories. Every prop change requires story updates. Every new use case requires an additional story. And if stories aren't up to date, visual tests validate an obsolete state of your components.
Delta-QA doesn't have this problem. It captures your real pages — the ones that already exist, with their current content and layout. No stories to write, no mock data to maintain, no synchronization between your application and a separate test environment.
Reality vs. idealization
Your Storybook stories show your components under ideal conditions: titles of reasonable length, images at the right ratio, well-formatted data. Your real application receives 200-character titles created by a hurried user, images uploaded at 4000x3000 pixels, data with special characters and mixed languages.
Delta-QA captures this reality. If a title that's too long breaks your layout in production, the visual test detects it — even if the Title component passes all its Chromatic tests with perfectly calibrated story titles.
Coverage without effort
For a 50-page site with 3 viewports, Delta-QA produces 150 visual captures per deployment. Achieving the same coverage with Storybook would require creating stories for each page — which amounts to recreating your application in Storybook, an effort nobody actually undertakes.
Most Storybooks cover design system components (buttons, forms, cards, navigation), not application pages (home, dashboard, profile, checkout). That's logical — Storybook is designed for components. But it's insufficient for visual testing.
Chromatic vs Loki vs Percy vs Delta-QA: where each excels
Rather than declaring a universal winner, here's an honest analysis of what each tool does best.
Chromatic excels for design systems
If you maintain a design system shared across multiple applications, Chromatic is probably the best choice for component visual testing. Its native Storybook integration, composition management, and collaborative review interface make it the most polished tool for this use case.
The trade-off: cost scales quickly with volume, and coverage stops at components in Storybook. For assembled pages, you need a complement.
Loki excels for limited budgets
If you want component visual testing at no service cost, Loki is the answer. The tool is free and runs locally or in your CI. You sacrifice review interface comfort and infrastructure stability, but you have no monthly subscription.
The trade-off: infrastructure maintenance (fonts, browsers, Docker) can consume more time than the cost of a cloud service. And like Chromatic and Percy, Loki covers only components in Storybook.
Percy excels for multi-browser
If you need to verify component rendering across Chrome, Firefox, and Safari, Percy (BrowserStack Visual Reviews) is the strongest choice. BrowserStack infrastructure provides access to real browsers on different OSes, exceeding Chromatic's simulation.
The trade-off: pricing is high for medium-sized teams, and Storybook mode remains limited to isolated components.
Delta-QA excels for real pages
If you want to verify what your users actually see — assembled pages, with real data, in the real context of your application — Delta-QA is the missing tool in your visual testing stack. It requires no Storybook, no scripts, no framework-specific configuration.
The ideal complementarity: use Chromatic (or Loki, or Percy) for your components, and Delta-QA for your pages. Both levels together form complete visual testing coverage.
When Storybook alone really isn't enough
Certain scenarios make full-page visual testing non-negotiable, beyond a simple "nice to have."
Multi-tenant applications
If your application adapts its appearance per tenant (white label, custom theme, client logo), your Storybook stories can't cover all variants. Delta-QA can capture the same page with different tenant contexts to verify each customization displays correctly.
Applications with a CMS
If your content is managed by a CMS and non-technical teams create and edit content, Storybook data never reflects real content. An article with a portrait image instead of the expected landscape format, a title in a language with wider characters, a content block with a nested table — these real cases can break your layout and Storybook never shows them.
E-commerce applications
Product pages are a critical visual testing ground. The number of images, description length, presence or absence of promotions, product variants, customer reviews — each combination can affect layout. Storybook can simulate some of these combinations, but not all. And the problematic combinations are often the ones you didn't think to include in your stories.
Framework or design system migrations
When you migrate your application from one design system to another, or from one major framework version to another, visual regressions are numerous and often subtle. Full-page visual testing gives you a before/after comparison covering your entire application surface — not just the components you remembered to update in Storybook.
FAQ
Should I drop Storybook if I use Delta-QA?
No. Storybook and Delta-QA are complementary, not competitors. Storybook remains an excellent tool for developing, documenting, and testing your components in isolation. Delta-QA adds the coverage Storybook lacks: visual testing of assembled pages in your real application. The recommended approach is to use both in parallel in your CI/CD pipeline, covering both individual components and full pages.
Chromatic is made by the Storybook team — isn't that the best possible integration?
Chromatic's integration with Storybook is indeed excellent. It's the best tool for testing your components in Storybook. But "the best Storybook integration" doesn't mean "the best visual testing coverage." Chromatic tests what Storybook shows, not what your application displays. For regressions that occur in component assembly, page context, or real data, you need a tool that tests the real page.
Does full-page visual testing generate a lot of false positives?
With the right settings, no. Delta-QA lets you configure exclusion zones for dynamic content (dates, counters, real-time data), disable CSS animations, and wait for full font loading before capture. On a site with mostly static or predictable content, false positives are rare. On an application with a lot of dynamic content, the effort of configuring exclusion zones is an initial investment that reduces noise long-term.
How much does a complete visual testing strategy (Storybook + pages) cost?
Cost depends on your tool choices. For the component level, Loki is free (but requires maintenance). Chromatic starts at $149 per month. Percy starts at $399 per month. For the page level, Delta-QA offers a free plan sufficient for small projects. The combination of Loki (free) and Delta-QA (free or paid depending on volume) provides complete coverage at a controlled cost. The real question isn't the strategy's cost, but the cost of an undetected visual regression in production.
Can my Storybook stories serve as documentation for page-level visual testing?
Your stories document the behavior and appearance of your individual components, which remains useful regardless of page-level visual testing. When Delta-QA detects a visual regression on a page, your Storybook stories help identify which component is responsible. That's complementarity in action: Delta-QA tells you "this page changed here," and Storybook helps you understand why by showing you the relevant component in its different variants.
How do I convince my team to add page-level visual testing on top of Storybook?
The most convincing argument is concrete: show a real visual regression that Storybook wouldn't have detected. A broken layout in production, a component overlapping another on mobile, a page whose content overflows its container. These regressions exist in every project — showing just one justifies adding page-level visual testing. Delta-QA sets up in under thirty minutes and doesn't require modifying your Storybook or code — it's a pure addition, friction-free.
Conclusion: complete visual coverage requires two levels
Storybook has transformed how teams develop and document UI components. It's an indispensable tool in every frontend developer's toolkit. And visual testing tools integrated with Storybook — Chromatic, Loki, Percy — deliver real value by detecting regressions in individual components.
But components don't live in isolation. They live in pages, surrounded by other components, with real data, in constrained layouts, under the influence of global styles and rendering contexts that Storybook doesn't reproduce. The most dangerous visual regressions — those affecting user experience — occur at this assembly level.
For complete visual testing coverage, you need two levels. The first level tests components in Storybook. The second level tests pages in the browser. Both are necessary. Neither suffices alone.
Delta-QA is designed for that second level. It captures your real pages, in a real browser, with the actual rendering of your application. Without scripts, without stories, without framework-specific dependency. It's the natural complement to your Storybook — the missing piece to transform your component visual testing into complete visual testing.