Testing + QA

This UI system treats testing as part of the workflow, not something added at the end.

The goal is to catch issues early:

• before components ship
• before UI drift becomes tech debt
• before “small changes” turn into regressions

What Storybook is responsible for

Storybook is the source of truth for component behavior and visual states.

Every component should have stories that cover:

• default usage
• variants (if supported)
• sizes (if supported)
• disabled state
• loading state (if relevant)
• edge cases (long text, icons, narrow containers)

Storybook is where components should be easiest to review.

If a component is hard to understand in Storybook, it’s usually a sign the API needs refinement.

What Chromatic catches

Chromatic runs visual regression tests against Storybook stories.

It’s especially good at catching:

• spacing shifts
• typography changes
• border/radius drift
• hover/focus style regressions
• unexpected theme changes (light/dark)

Chromatic is not “unit tests”, it’s a UI safety net.

It makes small changes safer because diffs show up immediately in review.

What still needs manual verification

Some things are hard to validate through screenshots alone.

Manual checks still matter for:

• keyboard navigation
• focus management (especially in menus/dialogs)
• screen reader behavior
• responsive layout behavior
• reduced motion behavior
• real content density (long names, long labels, messy input)

Practical workflow

A simple loop that works well:

1. Build the component in isolation (Storybook)
2. Add stories for key states + edge cases
3. Verify accessibility basics (keyboard + focus)
4. Run Chromatic and review diffs
5. Integrate the component into a real page
6. Re-check layout and content behavior

Notes

Testing doesn’t need to be heavy to be effective.

A consistent Storybook + Chromatic workflow catches the most common UI regressions and keeps the system stable as it grows.