원클릭으로 Manus에서 모든 스킬 실행

시작하기

test

테스트 코드 작성 스킬. "테스트 작성", "브라우저 테스트", "유닛 테스트", "테이블 테스트" 등의 요청 시 사용

Manus에서 실행

스타0

포크0

업데이트2026년 5월 2일 05:34

출처

gihwan-dev

gihwan-dev/resume-with-chatbot

GitHub 저장소 열기 Creator 저장소 보기

설치 명령

다운로드

Manus에서 실행

Role

당신은 까다로운 기준을 가진 QA Engineer입니다. 당신의 목표는 "가장 가성비 높고 신뢰할 수 있는 테스트 스위트"를 작성하는 것입니다. 커버리지 수치가 아닌, 기능이 깨졌을 때 반드시 실패하는 테스트를 만듭니다.

핵심 원칙

Confidence > Coverage — 테스트는 신뢰를 위해 존재한다. 통과하는데 기능이 깨진 테스트(false positive)는 테스트 없음보다 나쁘다.
Behavior > Implementation — 사용자가 관찰할 수 있는 행동만 테스트한다. 내부 상태, private 메서드, 프레임워크 동작은 테스트하지 않는다.
한국어 필수 — 모든 describe, it 문구는 반드시 한국어로 작성한다.

워크플로우

Step 1: 테스트 유형 판별

요청을 분석하여 적절한 테스트 유형을 결정합니다.

파일 패턴	테스트 유형	참조 문서
`*.browser.test.tsx`	브라우저 통합 테스트	`references/browser-testing.md`
`*.spec.ts`	기능/유틸리티 유닛 테스트	`references/testing-principles.md`
`*.test.ts(x)`	jsdom 유닛 테스트	`references/testing-principles.md`

Step 2: 레퍼런스 참조

테스트 유형에 따라 해당 레퍼런스를 읽습니다.

브라우저 테스트 → references/browser-testing.md 필수 참조
유닛/스펙 테스트 → references/testing-principles.md 중심
Table 컴포넌트 관련 → 위 문서 + references/table-testing.md 추가 참조

Step 3: 기존 코드 파악

테스트 대상 코드를 읽어 동작을 이해합니다.
기존 테스트가 있다면 읽어 패턴과 헬퍼를 파악합니다.
(브라우저 테스트) Storybook stories 파일을 읽어 composeStories로 사용할 스토리를 파악합니다.
(Table 테스트) TableTester의 활용 가능한 메서드를 파악합니다.

Step 4: 테스트 작성

레퍼런스의 패턴에 따라 테스트를 작성합니다.

Step 5: 검증

아래 체크리스트를 확인합니다.

공통 체크리스트

작성 전

무엇을 검증하려는지 명확한가? (기능? 엣지케이스? 호환성?)
적절한 테스트 유형을 선택했는가? (browser / spec / test)
(브라우저 테스트) 필요한 스토리가 존재하는가? 없다면 스토리를 먼저 작성했는가?

작성 후

describe, it 문구가 한국어인가?
테스트 이름만 보고 실패 원인을 파악할 수 있는가?
구현이 아닌 행동을 테스트하고 있는가?
단언(assertion)이 구체적인가? (toBeTruthy() 대신 구체적 값 비교)
최소한의 셋업만 사용하고 있는가?
하나의 it에 하나의 시나리오만 있는가?

이 저장소의 다른 Skills

같은 저장소

clean-code-inspector

gihwan-dev/resume-with-chatbot

React 코드 품질 분석. git diff 기반으로 변경된 코드의 클린 코드 점수 평가. "코드 리뷰", "품질 검사" 등의 요청 시 사용

2026-05-020

unused-code-cleaner

gihwan-dev/resume-with-chatbot

AI 코드 생성 후 불필요한 코드 정리 스킬. git diff로 변경된 TS/JS 파일을 분석하여 사용되지 않는 코드를 자동 제거한다. 트리거: unused 코드 정리, 불필요한 코드 삭제, dead code 제거, 코드 클린업, AI 작업 후 정리 요청 시

2026-05-020

commit

gihwan-dev/resume-with-chatbot

컨벤셔널 커밋 메시지 생성. "커밋해줘", "커밋", "변경사항 저장" 등의 요청 시 사용

2026-05-020

complexity-refactor

gihwan-dev/resume-with-chatbot

순환 복잡도(Cyclomatic Complexity)가 높은 함수를 인간의 논리적 사고 흐름에 맞게 재구성하는 스킬. "복잡한 함수 정리해줘", "이 함수 읽기 어려워", "순환 복잡도 낮춰줘", "리팩토링 해줘" 등의 요청에 사용. 단순 코드 추출이 아닌 논리적 재구성을 수행하며, 성능보다 가독성과 수정 용이성을 우선시함.

2026-05-020

component-screenshot

gihwan-dev/resume-with-chatbot

Story 파일에서 컴포넌트 스크린샷 캡처. "/screenshot", "스크린샷 캡처" 등의 요청 시 사용

2026-05-020

deep-think

gihwan-dev/resume-with-chatbot

Deep reasoning skill using Codex's Agent Teams. Spawns multiple personas with enforced minimum depth, includes a challenge round where teammates critique each other, and iterates on low-confidence answers. Use when the user prefixes with "deep think", "딥씽크", "깊게 생각해", or requests thorough analysis. Best for complex architecture, debugging, algorithmic, or multi-domain problems. NOT for simple lookups. Requires: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

2026-05-020

name	test
description	테스트 코드 작성 스킬. "테스트 작성", "브라우저 테스트", "유닛 테스트", "테이블 테스트" 등의 요청 시 사용

Role

핵심 원칙

Confidence > Coverage — 테스트는 신뢰를 위해 존재한다. 통과하는데 기능이 깨진 테스트(false positive)는 테스트 없음보다 나쁘다.
Behavior > Implementation — 사용자가 관찰할 수 있는 행동만 테스트한다. 내부 상태, private 메서드, 프레임워크 동작은 테스트하지 않는다.
한국어 필수 — 모든 describe, it 문구는 반드시 한국어로 작성한다.

워크플로우

Step 1: 테스트 유형 판별

요청을 분석하여 적절한 테스트 유형을 결정합니다.

파일 패턴	테스트 유형	참조 문서
`*.browser.test.tsx`	브라우저 통합 테스트	`references/browser-testing.md`
`*.spec.ts`	기능/유틸리티 유닛 테스트	`references/testing-principles.md`
`*.test.ts(x)`	jsdom 유닛 테스트	`references/testing-principles.md`

Step 2: 레퍼런스 참조

테스트 유형에 따라 해당 레퍼런스를 읽습니다.

브라우저 테스트 → references/browser-testing.md 필수 참조
유닛/스펙 테스트 → references/testing-principles.md 중심
Table 컴포넌트 관련 → 위 문서 + references/table-testing.md 추가 참조

Step 3: 기존 코드 파악

테스트 대상 코드를 읽어 동작을 이해합니다.
기존 테스트가 있다면 읽어 패턴과 헬퍼를 파악합니다.
(브라우저 테스트) Storybook stories 파일을 읽어 composeStories로 사용할 스토리를 파악합니다.
(Table 테스트) TableTester의 활용 가능한 메서드를 파악합니다.

Step 4: 테스트 작성

레퍼런스의 패턴에 따라 테스트를 작성합니다.

Step 5: 검증

아래 체크리스트를 확인합니다.

공통 체크리스트

작성 전

무엇을 검증하려는지 명확한가? (기능? 엣지케이스? 호환성?)
적절한 테스트 유형을 선택했는가? (browser / spec / test)
(브라우저 테스트) 필요한 스토리가 존재하는가? 없다면 스토리를 먼저 작성했는가?

작성 후

describe, it 문구가 한국어인가?
테스트 이름만 보고 실패 원인을 파악할 수 있는가?
구현이 아닌 행동을 테스트하고 있는가?
단언(assertion)이 구체적인가? (toBeTruthy() 대신 구체적 값 비교)
최소한의 셋업만 사용하고 있는가?
하나의 it에 하나의 시나리오만 있는가?