Open almost any Storybook codebase and look at the stories for layout components — Article, Card, Modal, Drawer. You will find the same pattern repeated everywhere: title: "Hello World", body: "Lorem ipsum dolor sit amet", author: "Jane Doe". The story renders, the component is ticked off as tested, and everyone moves on.
This is worse than it looks. A single-sentence body string does not wrap. It does not produce a second paragraph. It does not scroll. An article component filled with "Lorem ipsum dolor sit amet" cannot tell you anything about what the component does when a real editor pastes in twelve paragraphs, four headings, a table, and an image with a long caption. The story builds false confidence — the component passes visual inspection because it has never been asked to do anything real.
What toy data misses
There are three classes of bug that toy data consistently hides and that realistic content consistently reveals:
Line-length and reflow issues
A one-sentence string never wraps. That means you will never see the line-height on a second or third line, you will never see how the component handles a paragraph that runs to four lines in a narrow container, and you will never see whether overflow-wrap: break-word is set correctly for URLs or long technical terms. These issues surface in production the first time a content editor writes a genuinely long paragraph.
Scroll and height behaviour
Modal and Drawer components almost always have a max-height with internal scrolling. Testing them with two lines of content means you never verify that the scroll works, that the close button stays pinned to the top while the body scrolls, or that the footer CTA does not disappear behind the bottom of the viewport. You need content long enough to trigger the scroll to test any of this.
Typography and spacing relationships
Spacing between typographic elements — the gap between a heading and a following paragraph, the margin above a list, the line spacing inside a blockquote — is only meaningful in context. A single heading with one paragraph below it tells you almost nothing about how the component handles real editorial structure.
The fixture file pattern
The solution is straightforward: generate a realistic block of HTML once, save it as a fixture file in your project, and import it into every story that needs realistic content.
// src/test/fixtures/article-body.html (raw HTML string)
// Import in your stories:
import articleBody from '@/test/fixtures/article-body.html?raw'
const meta: Meta<typeof ArticleBody> = {
component: ArticleBody,
}
export const Realistic: Story = {
args: {
content: articleBody,
},
}The ?raw import suffix (supported in Vite, which powers most modern Storybook setups) gives you the file contents as a string without parsing it. You get a stable, version-controlled fixture that every story using it renders consistently.
What goes in the fixture
A useful article fixture should cover the full range of elements your content schema allows. At minimum:
- Three to four paragraphs of varying length — at least one should run to four or five lines in a typical content column
- H2 and H3 headings, including an H3 following an H2 directly with no paragraph between them
- An unordered list and an ordered list, each with four to six items
- A paragraph with bold text, italic text, and a hyperlink
- A figure with an image and a caption
- A blockquote
- A table with a header row and three or four body rows
This covers the output of every standard content block type. It is not exhaustive — you will find edge cases — but it catches the structural problems that toy data misses entirely.
One fixture, many stories
The other advantage of the fixture pattern is reuse. Once the file exists, you can import it into any story that needs realistic body content. Card components, Article components, Preview components, Search result components — anything that renders editorial content should be tested against the same fixture. This also makes it easy to update: when your content schema gains a new block type, update the fixture once and every story picks up the change automatically.
Storybook is a powerful tool for building components in isolation. The limitation is that isolation only reveals bugs if the isolated state is realistic. Toy data is not realistic. A fixture file built from structured placeholder content is.