Test user behavior, not internals

Assert what users can see and do instead of testing component state names or private helpers.

Code example

Copy, adapt, and ship.

Read the numbered lines, copy the complete snippet, then adjust the values for your project.

01// Test user behavior, not internals02// Apply this pattern in the smallest file that owns the behavior.03const beforeShipping = [04  "Name the intent clearly",05  "Handle the empty or error state",06  "Keep the change easy to test",07];

Production-ready starting point7 lines · copy with one click

Why this matters

The production reason.

01
Assert what users can see and do instead of testing component state names or private helpers. This matters because small implementation habits compound across every page, component, and handoff in a production codebase.
02
Use the pattern where the behavior is owned, keep the API small, and make the result easy for another developer to verify later.
03
The goal is not clever code. The goal is predictable code that survives new content, new teammates, and real user traffic.

Platform notes03

How it holds up outside a demo.

FrameworksKeep the pattern close to the route, component, or module that owns the behavior.
CMS or buildersMake the rule reusable so editors do not need to remember implementation details.
ProductionAdd a small check, test, or review note so the pattern does not regress quietly.