In a component library, what does treating workshop examples as test fixtures mean, and how should the mocked data behind them be built?

middlenice to knowfreq 35%

answer

define once, render everywhere
documented state equals tested state
freeze the clock
named scenarios from builders
never real client records

basics

~20 s

Each example is defined once and reused by the workshop, tests and design review, so a documented state is a tested state. Its mocked data should come from deterministic builders with named scenarios, a frozen current time and no real records.

solid answer

~40 s

An example bundles a component with its inputs, mocked data and any context it needs. Treating it as a test fixture means tests import and render that same example instead of rebuilding the setup, so the workshop, the tests and design review all look at one definition — a documented state is a tested state, and fixing an example fixes it everywhere. The mocked data has to support that: build it with builders that give realistic defaults and let each example override only what matters; give scenarios names (fully booked, holiday closure); keep it deterministic — in a vet booking app's availability calendar, freeze now and fix identifiers, or examples change every day; include edge data; mock at the boundary, not inside the component; and use synthetic data, never copied client or pet records.

An **example** bundles a component with its inputs, mocked data and any context it needs. Treating it as a **test fixture** means tests import and render that same example instead of rebuilding the setup, so the workshop, the tests and design review all look at one definition — a documented state is a tested state, and fixing an example fixes it everywhere. The mocked data has to support that: build it with **builders** that give realistic defaults and let each example override only what matters; give scenarios names (*fully booked*, *holiday closure*); keep it **deterministic** — in a vet booking app's availability calendar, freeze *now* and fix identifiers, or examples change every day; include edge data; mock at the boundary, not inside the component; and use synthetic data, never copied client or pet records.

code

pseudocode · 17 lines

pseudocode

FIXED_NOW = "2026-03-02T08:00 clinic local time"   -- a Monday morning

function buildWeek(now, overrides):
  week = defaultWeek(startingOn = startOfWeek(now), vets = 2)
  return merge(week, overrides)

example fullyBooked:
  data = buildWeek(FIXED_NOW, { allSlots: BOOKED })
  render AvailabilityCalendar(week = data, now = FIXED_NOW)

example holidayClosure:
  data = buildWeek(FIXED_NOW, { closedDay: WEDNESDAY, reason: "Public holiday" })
  render AvailabilityCalendar(week = data, now = FIXED_NOW)

test "fully booked week offers the waitlist":
  view = renderExample(fullyBooked)
  expect view has action named "Join waitlist"

go deeper

for a junior

Recall that an example bundles a component with inputs and data, and that tests can render the same example instead of rebuilding it.

for a middle

Explain how builders, named scenarios and a frozen clock make mocked data deterministic, and why mocking at the boundary keeps examples honest.

for a senior

Show how you would untangle drift between workshop examples and tests, and migrate to shared examples without losing test cases.

for a principal

Decide how far the library standardises examples as the single source for tests, docs and design review, and what that couples together.

What an example-as-fixture is

A workshop example is more than a picture. It is a definition: this component, with these inputs, this data and this context. A test fixture is the setup a test needs before it can check anything. Treating examples as fixtures means those are the same object: tests import an example and render it, rather than rebuilding the component's setup by hand.

The same definition can then feed several consumers:

the workshop, where people look at it;
tests, which render it and interact with it or scan it;
documentation pages, which embed it next to guidance;
design review, which compares it with the design library.

Which tests run over the examples, and how, is the library's test strategy. The point here is the single source.

Why a single source matters

No drift. When examples and tests are set up separately, they diverge: the workshop shows one fully booked day, the test checks another, and neither matches production.
A documented state is a tested state. Adding an example automatically gives the tests a new case to render.
One fix. When the component's inputs change, updating the example updates the workshop and every test that uses it.
Honest examples. An example that tests depend on cannot quietly rot, because a broken example fails a build.

Designing the mocked data

Builders with realistic defaults. A function produces a plausible appointment, clinic or vet; each example overrides only the fields its scenario needs.
Named scenarios. Fully booked, one slot left, holiday closure, vet on leave — the name states what the data is for.
Deterministic. Freeze the current time, fix identifiers and never use unseeded randomness. An availability calendar that reads today's date renders differently every day and fails at midnight.
Edge data on purpose. Long names, empty lists, the maximum realistic number of vets, time-zone boundaries.
Mock at the boundary. Replace the network or data layer the component already talks through, rather than adding special mock branches inside the component.
Synthetic only. Never paste real client, pet or payment records into examples; the workshop is often shared widely, and a fixture file is not a place for personal data.
Declare context in the example. Theme, locale, time zone and the signed-in user's role are part of the example's definition, so the workshop and the tests supply them identically instead of each guessing.

A worked example: the availability calendar

A veterinary clinic booking app shows a week of bookable slots per vet.

Scenario	Data it needs	Why it exists
Normal week	two vets, mixed free and booked slots	the default
Fully booked	every slot taken	the empty-choice message
Holiday closure	one day closed with a reason	the closed-day treatment
One slot left	a single free slot	urgency messaging
Load failed	the data layer returns an error	the retry state

Every scenario is built with now frozen at a fixed Monday morning, so today and past slots land in the same place on every run.

Pitfalls

Examples that read the real clock and change by themselves.
Workshop-only wrappers that supply context the tests do not, so an example passes in one place and fails in the other.
One giant shared fixture file that every example mutates, so changing it breaks unrelated examples.
Data that is too perfect — short names and full records — which hides the layouts real data breaks.
Examples that need network access to render, so they fail in a locked-down build or offline.
Scenario names that drift from their data, so fully booked quietly gains a free slot and nobody notices.

On native mobile

Native preview catalogs have the same shape: a preview is defined once with sample data and can be reused by UI tests. The same rules apply — deterministic sample data from builders, frozen time, no real records.

## What an example-as-fixture is A workshop **example** is more than a picture. It is a definition: *this component, with these inputs, this data and this context*. A **test fixture** is the setup a test needs before it can check anything. Treating examples as fixtures means those are the same object: tests import an example and render it, rather than rebuilding the component's setup by hand. The same definition can then feed several consumers: - the **workshop**, where people look at it; - **tests**, which render it and interact with it or scan it; - **documentation pages**, which embed it next to guidance; - **design review**, which compares it with the design library. Which tests run over the examples, and how, is the library's test strategy. The point here is the single source. ## Why a single source matters - **No drift.** When examples and tests are set up separately, they diverge: the workshop shows one *fully booked* day, the test checks another, and neither matches production. - **A documented state is a tested state.** Adding an example automatically gives the tests a new case to render. - **One fix.** When the component's inputs change, updating the example updates the workshop and every test that uses it. - **Honest examples.** An example that tests depend on cannot quietly rot, because a broken example fails a build. ## Designing the mocked data 1. **Builders with realistic defaults.** A function produces a plausible appointment, clinic or vet; each example overrides only the fields its scenario needs. 2. **Named scenarios.** *Fully booked*, *one slot left*, *holiday closure*, *vet on leave* — the name states what the data is for. 3. **Deterministic.** Freeze the current time, fix identifiers and never use unseeded randomness. An availability calendar that reads today's date renders differently every day and fails at midnight. 4. **Edge data on purpose.** Long names, empty lists, the maximum realistic number of vets, time-zone boundaries. 5. **Mock at the boundary.** Replace the network or data layer the component already talks through, rather than adding special mock branches inside the component. 6. **Synthetic only.** Never paste real client, pet or payment records into examples; the workshop is often shared widely, and a fixture file is not a place for personal data. 7. **Declare context in the example.** Theme, locale, time zone and the signed-in user's role are part of the example's definition, so the workshop and the tests supply them identically instead of each guessing. ## A worked example: the availability calendar A veterinary clinic booking app shows a week of bookable slots per vet. | Scenario | Data it needs | Why it exists | |---|---|---| | Normal week | two vets, mixed free and booked slots | the default | | Fully booked | every slot taken | the empty-choice message | | Holiday closure | one day closed with a reason | the closed-day treatment | | One slot left | a single free slot | urgency messaging | | Load failed | the data layer returns an error | the retry state | Every scenario is built with *now* frozen at a fixed Monday morning, so *today* and *past slots* land in the same place on every run. ## Pitfalls - **Examples that read the real clock** and change by themselves. - **Workshop-only wrappers** that supply context the tests do not, so an example passes in one place and fails in the other. - **One giant shared fixture file** that every example mutates, so changing it breaks unrelated examples. - **Data that is too perfect** — short names and full records — which hides the layouts real data breaks. - **Examples that need network access** to render, so they fail in a locked-down build or offline. - **Scenario names that drift** from their data, so *fully booked* quietly gains a free slot and nobody notices. ## On native mobile Native preview catalogs have the same shape: a preview is defined once with sample data and can be reused by UI tests. The same rules apply — deterministic sample data from builders, frozen time, no real records.

An example passes in the workshop but its test fails. Where do you look first?
At context the two environments supply differently: a wrapper the workshop adds globally but the test does not, a theme or locale set only in one, or a real clock or network call leaking through. The fix is to make the example declare everything it needs, so both environments render it the same way.
Why mock at the data boundary instead of adding a demo mode to the component?
A demo branch inside the component is code that only runs in the workshop, so examples stop showing what production runs. Replacing the data layer the component already uses keeps the component unchanged and lets the same example exercise its real loading, empty and error handling.

saying these in an interview costs you the question

Workshop examples and test setups should be written separately.
Using today's date in examples keeps them realistic.
Copying a few real client records makes the data believable.
Adding a demo mode inside the component is the easiest way to mock.
One shared fixture that every example edits keeps things simple.

In a component library, what does treating workshop examples as test fixtures mean, and how should the mocked data behind them be built?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

What an example-as-fixture is

Why a single source matters

Designing the mocked data

A worked example: the availability calendar

Pitfalls

On native mobile

▾common follow-ups2 questions

▾red flags5 flags

What an example-as-fixture is

Why a single source matters

Designing the mocked data

A worked example: the availability calendar

Pitfalls

On native mobile

answer

go deeper