메뉴
Use when writing, reviewing, or refactoring React component tests that must validate public behavior instead of implementation details, especially tests in packages/frameworks/react.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | behavior-focused-react-testing |
| description | Use when writing, reviewing, or refactoring React component tests that must validate public behavior instead of implementation details, especially tests in packages/frameworks/react. |
| allowed-tools | Read Edit Write Glob Grep Bash Agent |
Use this skill to keep React component tests tied to user-observable behavior and public contracts. The goal is refactor-resistant tests: internal markup, child components, styling, or state-machine plumbing can change without breaking tests for unchanged behavior.
For @qualcomm-ui/react, load only the references needed for the task:
references/environment-and-commands.md: imports, Vitest browser mode, render helpers, runner commands.references/querying.md: accessible queries, query priority, acceptable getByTestId use.references/asserting.md: public outcome assertions and callback/form assertions.references/multi-api-patterns.md: composite/simple API parity with MultiComponentTestCase.references/interaction-patterns.md: click, type/fill, keyboard, portal, focus, outside interaction behavior.references/state-and-callbacks.md: controlled state, context/render-prop readouts, callback payloads.references/anti-patterns.md: implementation-detail smells and rewrite guidance.references/coverage-checklist.md: behavior coverage checklist for new or revised suites.For other React projects, use the workflow here and adapt imports, render helpers, and runner commands to the local test stack.
Before adding an assertion, ask:
Would this still pass if the component were rewritten with different internal markup but the same public behavior?
If the answer is no, rewrite the test around a user-visible result or a documented public contract.
When reviewing tests, lead with actionable findings:
Findings
- [P1] <test asserts an implementation detail>. <file:line>
<why it is brittle and what public behavior to assert instead>
Missing Behavior
- `<observable behavior not covered>`
Residual Risk
- `<tests not run, local limits, or behavior that lacks a stable public surface>`
When writing tests, include the test files changed and the command used to run them.
Rebase the current branch into clean conventional commits with proper author attribution. Use when the user wants to clean up a branch's commit history into well-organized conventional commits.
Use when writing, reviewing, or refactoring Angular component or directive tests, especially tests for inputs, outputs, host behavior, template probes, forms, accessibility, or signal-backed behavior.
Use when writing, reviewing, or refactoring Angular tests for application behavior, services, routes, state, forms, pipes, or integration flows, especially when tests may assert implementation details instead of public outcomes.
Use when writing, reviewing, or refactoring React component tests, especially tests for props, callbacks, controlled state, children, accessibility, form behavior, or multiple public component API variants.
Use when writing, reviewing, or refactoring React tests for application behavior, hooks, routes, state, or integration flows, especially when tests may assert implementation details instead of public outcomes.
Use when writing, reviewing, or refactoring tests that run in Vitest Browser Mode, especially tests using page, userEvent, expect.element, browser locators, polling assertions, or real DOM interactions.