Component stress test in every state

/goal Check [COMPONENT NAME OR PATH] and make sure it survives the content and states it will encounter in real use.

INSPECT ONLY THIS COMPONENT.

Do not modify it yet. Read its actual props, slots, states, data sources, and where it is used. Based on what it really accepts, select the stress cases that apply.

TEST THESE WHEN RELEVANT:

→ No data, one item, and many items
→ Loading, error, disabled, and permission-denied states
→ Normal text, very long text, and an unbreakable string
→ Missing images, very large numbers, and incomplete data
→ A 320px viewport and any other widths the component supports
→ Dark mode; skip it if the project does not support it

Do not add irrelevant cases just to make the list longer.

BUILD THE TEST PAGE:

Create a temporary page inside the app. Import the real component and use the project’s existing fonts, styles, tokens, and layout context. Render every scenario side by side in one pass.

Do not rebuild a lookalike component or connect to production data.

Open the page and record only problems you can actually reproduce. Do not predict failures from the code or report personal taste as a bug.

FIX ONLY CONFIRMED PROBLEMS:

Fix them one at a time. After each change, rerender the original failing state and verify:

→ Content no longer overflows or disappears
→ Primary actions still work
→ Keyboard and focus behavior did not regress
→ States that already passed were not broken

Do not use this as an excuse to redesign the component, change its public API, or touch functionality outside the test page.

RETURN:

→ Every state you tested
→ Before-and-after screenshots
→ What you fixed
→ Anything still unresolved
→ Relevant test and build results

DONE WHEN:

Every applicable state has been rendered, every confirmed problem has been fixed and retested, the existing tests pass, and the build succeeds.