Component Test
컴포넌트 테스트
컴포넌트 테스트는 실제 렌더링 공간에 하나의 인터페이스 부분을 배치합니다. 그런 다음 해당 부분에 제어된 입력과 데이터를 제공하고, 동작을 확인합니다.
다른 예시
디자인 시스템 엔지니어는 오류 상태와 함께 200개의 선택지가 있는 콤보 상자를 엽니다. 키보드 선택은 값과 접근 가능 상태를 변경해야 합니다. 정적인 콘텐츠 스크린샷으로는 이 동작을 테스트할 수 없습니다.
주요 부분
- 01스토리 픽스처
- 02마운트된 컴포넌트
- 03브라우저 검증
사용할 때
UI 동작이 브라우저 렌더링을 필요로 하지만 전체 제품 경로는 필요하지 않을 때 이 용어를 사용하십시오.
다음 경우에는 사용하지 마세요
해당 컴포넌트 외부의 연결에 대한 통합 테스트 또는 E2E 테스트 대신 컴포넌트 테스트를 사용하지 마세요.
코드에서 사용된 이름
story fixture → mount → user action → assertion 출시하기 전에
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：Complete the task with 컴포넌트 테스트 (Component Test)。 User context：디자인 시스템 엔지니어는 오류 상태와 함께 200개의 선택지가 있는 콤보 상자를 엽니다. 키보드 선택은 값과 접근 가능 상태를 변경해야 합니다. 정적인 콘텐츠 스크린샷으로는 이 동작을 테스트할 수 없습니다. Validation approach：컴포넌트 테스트 (Component Test)。 Why it fits：UI 동작이 브라우저 렌더링을 필요로 하지만 전체 제품 경로는 필요하지 않을 때 이 용어를 사용하십시오. Do not use it when：해당 컴포넌트 외부의 연결에 대한 통합 테스트 또는 E2E 테스트 대신 컴포넌트 테스트를 사용하지 마세요. 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)：해당 출처에 대해 공식적인 것입니다. 다른 플랫폼이나 팀은 그 용어를 다른 방식으로 사용할 수 있습니다. Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.
이 요청을 확인하세요
Review how 컴포넌트 테스트 (Component Test) is used now. Definition: 컴포넌트 테스트는 실제 렌더링 공간에 하나의 인터페이스 부분을 배치합니다. 그런 다음 해당 부분에 제어된 입력과 데이터를 제공하고, 동작을 확인합니다. 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, list the evidence, gaps, severity, and the smallest safe fix.