Component Test
A component test places one interface part in a real rendering space. It gives the part controlled input and data, then checks its behavior.
Another example
A design-system engineer opens a combo box with 200 choices and an error state. Keyboard selection must change the value and its accessible status. A screenshot of still content cannot test this behavior.
Main parts
- 01story fixture
- 02mounted component
- 03browser assertion
Use it when
Use this term when a UI behavior needs browser rendering but does not need the whole product journey.
Do not use it when
Do not use component tests in place of integration or E2E tests for connections outside that component.
Name used in code
story fixture → mount → user action → assertion Before you ship
Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule.
Outcome: Use Component Test to gather repeatable evidence about this behavior or quality risk. User context: A design-system engineer opens a combo box with 200 choices and an error state. Keyboard selection must change the value and its accessible status. A screenshot of still content cannot test this behavior. Validation approach: Component Test. Why it fits: Use this term when a UI behavior needs browser rendering but does not need the whole product journey. Do not use it when: Do not use component tests in place of integration or E2E tests for connections outside that component. Test requirements: Name the system and test environment. Define prepared test data, other inputs, and the result you can observe. Include failure and edge cases, allowed error, isolation, and cleanup. Test operations: Make failures easy to diagnose. Control random or changing inputs. Name an owner. Keep the test fast and simple enough for its release gate. Acceptance criteria: The test fails for the known bug and passes after the fix. It repeats in the target environment, gives useful evidence, and does not expose or change unrelated data. Evidence and limits (evidence boundary): It is official for that source. Other platforms or teams may use the term in another way. Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.
Check this request
Review the current use of Component Test. Definition: A component test places one interface part in a real rendering space. It gives the part controlled input and data, then checks its behavior. Release checks: Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.