A component can look finished in Storybook, Figma, or a local page and still break the first week it reaches real users.
That does not mean the component was built badly. It usually means it was only tested in the clean state.
Every component needs a small stress test before you call it done.
Content is the first thing that breaks most components.
Test the title at one word, two lines, and too long. Remove optional fields. Add a long description. Use a label that is twice as long as the design. Use a number with more digits than expected.
For a card component, that means checking:
If the component only works with perfect content, it is not really reusable yet.
Components are state machines, even when they look simple.
A button can be default, hover, active, focused, disabled, pending, successful, or failed. A table can be loading, empty, filtered-empty, partially loaded, errored, selected, or sorted.
Write down the states before you build or review. If a state can happen in the product, the component needs an answer for it.
The answer does not always need to be fancy. Sometimes the answer is a short message, a disabled action, or keeping the current content visible. But it should be deliberate.
A component that works at one width is not done. Resize it.
Watch where it starts to feel wrong. Does the label wrap in a bad place? Does the icon crowd the text? Does the action menu fall to a new line? Does the chart become unreadable?
The goal is not to support every possible width equally. The goal is to know the component's limits and define what it should do at those limits.
Many components are tested only with a mouse. That misses a lot.
Use the keyboard. Tab into the component. Press Enter and Space. Escape out of popovers. Move through options with arrow keys if the pattern expects it.
Then use touch if the component appears on mobile. A tiny icon button that works with a mouse may be painful with a thumb.
Interaction testing is part of design testing. The component should feel usable, not just look correct.
If the component depends on data, test slow and failed data.
A profile card should have a loading state. A table should know what to do if the request fails. A save button should explain that work is pending.
Do not let the component collapse into a blank area while it waits. Do not let it silently return to normal after failure.
Network states are user-visible states. They deserve design decisions.
A component can look great alone and wrong in context.
A card may have good padding by itself but feel too heavy in a grid of twelve cards. A button may look balanced alone but too loud inside a modal footer. A badge may feel clear in isolation but compete with the title in a dense table.
Components do not ship into empty space. Test at least one real placement.
You do not need to turn every component into a giant project. You just need to stop judging it only by its nicest state.
A finished component is not the one that looks good with perfect props. It is the one that still behaves well when the product gets messy.