A design system promises consistency across products. The hard part is keeping that promise as the system evolves. A token tweak in --color-surface-default ripples into every card, modal, table, and toast in every product that consumes the package. Without a visual safety net, the only way you find out is when a designer notices in production.
This post lays out a three-layer testing strategy - tokens, components, and downstream products - that turns your design system from a tribal contract into a verifiable one.
Layer 1: Token-level coverage
Tokens are the atoms of the system. Test them by rendering swatches: a grid for color, a stack for typography, a row for spacing. Diff each swatch against its baseline. When someone changes --space-md from 12 to 14 px, the spacing row tells you immediately, before any component test even runs.
Layer 2: Component matrix
Once tokens are stable, test the components that consume them. The right structure is a matrix: each component crossed with every variant, every state, and every theme. For a button with 5 variants × 4 states × 2 themes, that is 40 baselines - a number no human will ever maintain by hand. Lastest's AI agent scaffolds the matrix from your component library and you approve once.
Layer 3: Cross-product drift
A design system is not finished when the package ships. The most common bug pattern is silent drift: @yourorg/[email protected] updates a token, three downstream products bump the dependency, and one of them now renders a 2-px-thicker border on every form field. Functional tests do not catch this. Visual tests do.
Run the suite of every consumer app against the new design system release before publishing. Lastest's compose mode pins package versions per build, so you can run "what would product X look like with the next DS release" as a single CI job.
Versioning baselines per release
Tag baselines with the design system version. When you ship 3.3.0, the new baselines become canonical for that line; 3.2.x baselines stay locked. Hotfixes never accidentally regress against the wrong reference. SHA256 hashing on the artifact means you can prove a baseline has not been tampered with after approval.
What this gets you
- Tokens are testable, not just documented. A spacing change cannot land without a visible diff.
- The full variant matrix is covered automatically. Lastest scaffolds it; humans approve.
- Downstream regressions surface before release. Cross-product runs catch cascade bugs at PR time.
- Baselines are versioned and signed. No "but it worked on main" forensics.
A design system without visual tests is a memo. With them, it is a contract.