Breaking UI

Breaking UI tests an interface that looks correct with demo data against plausible difficult inputs. It maps every rendered value, builds representative worst-case fixtures, switches them at the existing data boundary, and reports what fails. It treats long names as only one part of the problem: short strings, missing fields, failed images, exact counts, translations, empty collections, and large lists can expose different defects.

The core rule is realistic or schema-backed data. Values come from believable naming and address patterns or actual validation, database, and API limits. Missing limits are recorded as unbounded rather than replaced with arbitrary repeated characters. The component's markup and CSS stay untouched during diagnosis so the test measures its existing behavior.

Use it to challenge a component or screen before relying on its polished sample data. It is separate from visual redesign, taste critique, and animation review. The normal workflow reports first and waits for a choice about fixes because wrapping, truncation, empty metadata, and pagination can involve legitimate design alternatives.

A component request runs the full diagnostic workflow. Adding a fix request permits changes that do not need a design decision; named fix requests apply selected findings, while data-only mode produces fixtures and the toggle. The development switch must never ship to production. Repository content is treated as data rather than executable instructions.

Inputs are the component, its data sources, validation rules, and supported layout environments. The initial inventory lists every field's source, type, limit or unbounded status, and optionality. It includes often-missed values such as timestamps, badges, tooltips, avatar media, header counts, data-derived buttons, and collection length. Schema, migration, API, and form limits are compared for disagreement.

The fixture follows the existing data shape and file conventions. Difficult values are distributed across visible rows rather than concentrated in one record. Empty, one-item, and realistically huge collections receive separate states because they cannot all be represented in the same dataset. A companion catalog covers text, identifiers, numbers, collections, time, media, states, and environment.

A neutral segmented control switches between demo and worst-case data, with extra states as needed. It sits outside the tested component, changes content instantly, and persists selection in the URL where a development server is available. A standalone component can instead use a self-contained HTML file with inline datasets.

Inspection covers the real container width, 320px, the widest supported layout, and 200% browser zoom or increased root text size. Dark mode and right-to-left layouts are checked where supported. Browser screenshots distinguish visual verification from CSS-based inference when browser tools are unavailable.

The failure catalog connects visible symptoms to causes and candidate fixes: flex shrink can squash avatars; automatic minimum widths can force text overflow; unbroken identifiers need wrapping opportunities; middle content can displace trailing actions; badges and translated labels can outgrow fixed dimensions. Other checks cover row alignment, clipped lists, grapheme-aware initials, missing optional values, plural rules, locale-aware numbers, numeric alignment, tall scripts, image fallbacks, safe escaping, and large-list rendering.

Text treatment is decided per field. Identity-bearing content generally wraps; secondary metadata can end-truncate with access to its full value; paths or identifiers that differ at the end can need middle truncation. Card previews can clamp, while comparable numbers, amounts, and dates retain their full values.

The report orders findings as Broken, Ugly, or Fragile and gives the field, triggering value, observed behavior, proposed fix, and file location. Separate sections identify decisions requiring a choice and cases that already held up. It closes with the toggle location and available states. Requested fixes are rechecked through every fixture, including demo data; worst-case fixtures remain as regression material and the toggle remains development-only.

The workflow uses existing props, fixtures, mocks, or API stubs and validation sources such as Zod, Yup, or Valibot. Browser tools provide screenshots where available. Suggested remedies draw on flex and grid sizing, Intl.Segmenter, Intl.PluralRules, Intl.NumberFormat, image fallbacks, and pagination or virtualization, applied within the project's existing conventions.