
testing
React Testing Library 및 Vitest 기반 테스팅 모범 관례. 다음 상황에서 사용: (1) .test.tsx, .test.ts, .spec.tsx, .spec.ts 파일 작업 시, (2) 컴포넌트 테스트 작성 또는 리팩토링 시, (3) 'test', 'testing', 'vitest', 'RTL', 'getByRole', 'userEvent', 'waitFor', 'expect' 키워드 포함 작업 시, (4) 비동기 로직 또는 사용자 상호작용 테스트 작성 시
- Installs
- 384
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/dalestudy/skills --skill testing- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads testing automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Testing Library
React Testing Library 기반 테스트 작성 모범 관례 및 안티패턴 회피 가이드.
핵심 원칙
Testing Library의 철학: 사용자가 사용하는 방식대로 테스트하라
- 접근성 기반 쿼리 우선 - 실제 사용자가 요소를 찾는 방식 사용
- 구현 세부사항 테스트 금지 - 컴포넌트 내부 상태/메서드 직접 접근 지양
- 실제 사용자 행동 시뮬레이션 - userEvent 사용, fireEvent 지양
- 비동기 처리 명시적 대기 - waitFor, findBy 활용
쿼리 우선순위
Testing Library는 다양한 쿼리를 제공하지만, 접근성과 사용자 경험을 반영하는 순서로 사용해야 함.
권장 쿼리 순서 (높음 → 낮음)
getByRole(최우선) - 스크린 리더가 인식하는 방식getByLabelText- 폼 요소 (label과 연결된 input)getByPlaceholderText- placeholder가 명확한 경우getByText- 텍스트 콘텐츠로 검색getByDisplayValue- 현재 입력된 값으로 검색 (폼 요소)getByAltText- 이미지 alt 속성getByTitle- title 속성 (tooltip 등)getByTestId(최후 수단) - 다른 방법이 불가능할 때만 사용
상세 가이드: references/query-priority.md
사용자 상호작용 테스트
userEvent 사용 (권장)
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
test('사용자가 폼을 제출할 수 있다', async () => {
const user = userEvent.setup();
render(<LoginForm />);
await user.type(screen.getByRole('textbox', { name: /이메일/i }), 'user@example.com');
await user.type(screen.getByLabelText(/비밀번호/i), 'password123');
await user.click(screen.getByRole('button', { name: /로그인/i }));
expect(await screen.findByText(/환영합니다/i)).toBeInTheDocument();
});
핵심:
userEvent.setup()호출 후 사용- 모든 user 메서드는
await필수 - 실제 브라우저 이벤트 순서 재현 (focus, keydown, keyup 등)
fireEvent 지양
// ❌ 나쁜 예 - fireEvent 사용
fireEvent.click(button);
fireEvent.change(input, { target: { value: "text" } });
// ✅ 좋은 예 - userEvent 사용
await user.click(button);
await user.type(input, "text");
상세 가이드: references/user-events.md
비동기 처리
findBy 쿼리 (권장)
// ✅ 좋은 예 - findBy 사용
const successMessage = await screen.findByText(/저장되었습니다/i);
expect(successMessage).toBeInTheDocument();
findBy = getBy + waitFor 조합 (자동으로 요소 나타날 때까지 대기)
waitFor 사용
// 복잡한 비동기 검증
await waitFor(() => {
expect(screen.getByRole("alert")).toHaveTextContent("성공");
});
// 여러 조건 검증
await waitFor(() => {
expect(mockFn).toHaveBeenCalledTimes(1);
expect(screen.queryByText(/로딩 중/i)).not.toBeInTheDocument();
});
안티패턴
// ❌ 나쁜 예 - 임의의 timeout
await new Promise((resolve) => setTimeout(resolve, 1000));
// ❌ 나쁜 예 - act() 수동 사용 (보통 불필요)
await act(async () => {
// ...
});
// ✅ 좋은 예 - findBy 또는 waitFor
await screen.findByText(/완료/i);
상세 가이드: references/async-patterns.md
자주 하는 실수
1. 구현 세부사항 테스트
// ❌ 나쁜 예 - 내부 상태 접근
expect(component.state.isOpen).toBe(true);
wrapper.find(".internal-class").simulate("click");
// ✅ 좋은 예 - 사용자 관점 검증
expect(screen.getByRole("dialog")).toBeVisible();
await user.click(screen.getByRole("button", { name: /열기/i }));
2. container 쿼리 사용
// ❌ 나쁜 예 - container.querySelector
const { container } = render(<MyComponent />);
const button = container.querySelector('.my-button');
// ✅ 좋은 예 - screen 쿼리
const button = screen.getByRole('button', { name: /제출/i });
3. 불필요한 waitFor
// ❌ 나쁜 예 - 동기 요소에 waitFor
await waitFor(() => {
expect(screen.getByText("Hello")).toBeInTheDocument();
});
// ✅ 좋은 예 - 동기 요소는 즉시 검증
expect(screen.getByText("Hello")).toBeInTheDocument();
4. getBy* + toBeInTheDocument() 제거
getBy*는 요소를 못 찾으면 throw하므로 toBeInTheDocument()는 기술적으로 중복이다. 하지만 제거하지 마라 — 리팩토링 후 남은 쿼리가 아니라 의도적인 존재 검증임을 코드 독자에게 전달하는 역할을 한다.
// ❌ 나쁜 예 - assertion 없이 쿼리만 남김
screen.getByRole("button", { name: /제출/i });
// ✅ 좋은 예 - 명시적 assertion으로 의도 전달
expect(screen.getByRole("button", { name: /제출/i })).toBeInTheDocument();
단, 존재 검증이 아닌 다른 속성을 검증할 때는 toBeInTheDocument()를 추가할 필요 없다:
// ✅ 좋은 예 - 다른 matcher로 충분
expect(screen.getByRole("button", { name: /제출/i })).toBeDisabled();
// ❌ 나쁜 예 - 중복 assertion
expect(screen.getByRole("button", { name: /제출/i })).toBeInTheDocument();
expect(screen.getByRole("button", { name: /제출/i })).toBeDisabled();
전체 안티패턴 목록: references/common-mistakes.md
Vitest + MSW 설정
테스트 환경 설정이 필요한 경우 다음 템플릿 참조:
assets/vitest.config.ts- Vitest 설정 (React 플러그인, 커버리지 포함)assets/test-setup.ts- Vitest 글로벌 설정assets/msw-setup.ts- MSW 핸들러 및 서버 설정
FAQ
What does the testing skill do?
React Testing Library 및 Vitest 기반 테스팅 모범 관례. 다음 상황에서 사용: (1) .test.tsx, .test.ts, .spec.tsx, .spec.ts 파일 작업 시, (2) 컴포넌트 테스트 작성 또는 리팩토링 시, (3) 'test', 'testing', 'vitest', 'RTL', 'getByRole', 'userEvent', 'waitFor', 'expect' 키워드 포함 작업 시, (4) 비동기 로직 또는 사용자 상호작용 테스트 작성 시
How do I install testing?
Run npx skills add https://github.com/dalestudy/skills --skill testing in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/testing/ (personal) or .claude/skills/testing/ (project).
Which AI agents can use testing?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is testing safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains testing?
It is published by dalestudy in dalestudy/skills. It has 384 recorded installs.
More from dalestudy/skills
storybook
dalestudy/skills
Storybook 스토리 작성 및 CSF 3.0 베스트 프랙티스 스킬. 다음 상황에서 사용: (1) 새 스토리 파일(.stories.tsx, .stories.ts) 작성 시, (2) 기존 스토리 수정 시, (3) Args, Decorators, Parameters 설정 시, (4) Storybook 설정 파일(.storybook/) 작업 시, (5) 'story', 'stories', 'storybook', 'CSF' 키워드가 포함된 작업 시
github-actions
dalestudy/skills
GitHub Actions 워크플로우 생성, 보안 및 버전 관리 스킬. 다음 상황에서 사용: (1) 새 워크플로우 파일(.yml) 작성 시, (2) 기존 워크플로우 수정 시, (3) 액션 버전 검토 또는 업데이트 시, (4) CI/CD 보안 감사 시, (5) 'actions/', 'uses:', 'workflow', '.github/workflows' 키워드가 포함된 작업 시
bun
dalestudy/skills
Node.js 대신 Bun 런타임 사용을 위한 스킬. 다음 상황에서 사용: (1) 새 JavaScript/TypeScript 프로젝트 생성 시, (2) package.json 또는 의존성 관련 작업 시, (3) 스크립트 실행 또는 개발 서버 시작 시, (4) Node.js 프로젝트를 Bun으로 전환 시, (5) 'bun', 'bunx', 'bun.lockb' 키워드가 포함된 작업 시
skill-creator
dalestudy/skills
Open the skill to read its SKILL.md instructions.
typescript
dalestudy/skills
Open the skill to read its SKILL.md instructions.
git
dalestudy/skills
Git 버전 관리 모범 관례 및 워크플로우 가이드. 다음 상황에서 사용: (1) Git 커밋 메시지 작성 시 (Conventional Commits 규칙 적용), (2) 브랜치 생성 및 관리 시 (GitHub Flow 기반), (3) PR 생성 및 병합 전략 선택 시, (4) Git 히스토리 정리 작업 시 (rebase, squash, cherry-pick), (5) Merge conflict 해결 시, (6) 'git', '.git', 'commit', 'branch', 'merge', 'rebase' 키워드가 포함된 작업 시
Popular testing & qa skills
tdd
mattpocock/skills
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
grilling
mattpocock/skills
Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
migrate-to-shoehorn
mattpocock/skills
Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.
run-train
lllllllama/rigorpilot-skills
Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.
test-driven-development
obra/superpowers
Use when implementing any feature or bugfix, before writing implementation code
finishing-a-development-branch
obra/superpowers
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work