메뉴
테스트가 과하게 mock/fixture/구현세부 assertion에 묶였는지 점검하고, 기능 테스트·내부 로직 테스트·외부 의존성 mock 경계를 기준으로 실용적으로 다듬을 때 사용한다. "테스트가 과하지 않은지", "모킹 기준", "내부 메서드는 직접 테스트", "외부 API만 mock", "unit/contract test 어디까지" 같은 요청에 사용한다.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | test-boundary-refactor |
| description | 테스트가 과하게 mock/fixture/구현세부 assertion에 묶였는지 점검하고, 기능 테스트·내부 로직 테스트·외부 의존성 mock 경계를 기준으로 실용적으로 다듬을 때 사용한다. "테스트가 과하지 않은지", "모킹 기준", "내부 메서드는 직접 테스트", "외부 API만 mock", "unit/contract test 어디까지" 같은 요청에 사용한다. |
| argument-hint | [파일/디렉터리/PR/diff] [--apply] [--staged] |
| disable-model-invocation | false |
테스트를 “많이 쓰는 것”이 아니라 책임 경계에 맞게 납득 가능하게 쓰는 것으로 다듬는다.
테스트는 책임 경계에 맞춰 쓴다.
기능 단위 테스트는 유저 관점의 행동과 결과만 검증한다.
내부 메서드/로직은 mock하지 않고 분리해서 직접 테스트한다.
API, DB, OAuth, router, webview, third-party SDK 같은 외부 의존성만 mock으로 격리한다.
실제 코드 수정에 들어갈 때는 references/test-refine-runbook.md를 읽고 적용한다. SKILL.md는 판단 기준, runbook은 diff audit → 경계 분류 → 수정 순서 → 가까운 검증 순서를 담은 실행 체크리스트다.
| 범주 | 무엇을 검증하나 | 좋은 테스트 | 피해야 할 냄새 |
|---|---|---|---|
| 사용자-facing 기능 테스트 | 사용자가 보는 행동과 결과 | “드롭다운이 열린다”, “버튼 클릭 후 상태 문구가 바뀐다”, “CTA가 올바른 링크를 가진다” | 내부 함수 호출 여부, 구현 상태 변수, 불필요한 provider/mock 세팅 |
| 내부 로직 테스트 | 계산, 분기, mapper, helper, hook/service 순수 책임 | 로직을 분리해 입력→출력을 직접 검증 | 컴포넌트 테스트에서 내부 메서드를 mock/spy로 우회 |
| 외부 의존성 boundary | API, DB, OAuth, router, webview, third-party SDK | mock/stub/fake recorder로 외부 효과를 차단하고 내 코드가 넘기는 contract를 검증 | 실제 외부 호출, 과한 e2e, 외부 성공을 내 테스트 책임으로 삼기 |
| contract/integration | 내 코드 계층 사이에서 값이 누락되지 않는지 | 작은 범위의 real path + 외부 boundary만 fake | 전체 app suite fan-out, broad fixture, flaky environment 의존 |
먼저 현재 요청이 분석인지 수정인지 분리한다.
/test-refine 또는 “고쳐줘/정리해줘/다듬어줘”면 수정 후보까지 진행한다.--apply가 있으면 경계가 명확한 안전한 수정은 바로 적용할 수 있다.사용자가 준 파일/디렉터리/PR/diff anchor부터 본다. anchor가 없으면 현재 git diff에서 시작한다.
확인할 것:
각 테스트 또는 describe block마다 아래 라벨을 붙인다.
[behavior] 사용자 행동/결과 검증
[logic] 내부 순수 로직 직접 검증
[boundary] 외부 의존성 mock/stub/fake
[contract] 내 코드 계층 간 값 전달/호출 contract
[noise] 목적 대비 과한 mock/fixture/assertion
다음이 보이면 수정 후보로 표시한다.
| 냄새 | 우선 수정 |
|---|---|
| behavior test가 내부 구현을 봄 | assertion을 사용자-visible 결과로 바꾼다 |
| 내부 로직이 컴포넌트 안에 묻힘 | 순수 함수/hook/service로 분리해 직접 테스트한다 |
| 외부 의존성이 실제 호출됨 | 외부 boundary만 mock/stub/fake로 격리한다 |
| mock이 너무 많음 | 테스트 목적에 필요한 외부 boundary mock만 남긴다 |
| fixture가 너무 큼 | 검증 대상 필드만 남긴 최소 fixture로 줄인다 |
| unit만으로 contract 누락 위험 | 외부 boundary만 fake인 작은 contract test를 추가한다 |
| wrapper test가 broad fan-out | 가까운 spec 직접 실행 또는 fan-out 사실을 명시하고 baseline 분리 |
수정할 때는 작게 간다.
금지:
분석만 할 때:
## test-refine 결과
### 경계 분류
| 테스트/블록 | 분류 | 판단 |
|---|---|---|
### 과한 부분
- ...
### 권장 수정
1. ...
### 가까운 검증
- 실행할 테스트/린트와 fan-out 예상
수정까지 했을 때:
완료했습니다.
- 정리: behavior test는 사용자 결과만 남김 / 내부 로직 직접 테스트 / 외부 boundary mock 정리
- 변경: `path...`
- 검증: `command` 통과
- 주의: baseline 또는 남은 gap
검증 명령은 현재 diff와 가장 가까운 범위만 선택한다.
pnpm <script> -- <path>가 실제로 좁혀지는지 package script를 모르면 먼저 확인한다.현재 worktree를 최신 production 기반 새 branch로 in-place 전환해야 할 때 사용한다. "/to-production", "production으로 옮겨", "production 바라보게", "hotfix로 다시 쌓아" 요청에 사용한다. 기존 작업 commit은 backup 후 cherry-pick하고, 새 worktree가 필요하면 /wt fork --hotfix가 담당한다.
열린 PR의 리뷰 코멘트나 changes requested에 대해 부모/현재 대화와 작업 내역을 확인한 뒤, 표면적 답변이 아니라 근본 원인을 판단해 코드 수정·커밋·푸시·스레드 답글·review re-request까지 수행해야 할 때 사용한다. `--push-only` 모드에서는 코멘트/re-request 없이 커밋·푸시 후 수동 게시용 답글 초안을 세션에서 다듬는다. "PR 코멘트 대응", "리뷰 대응", "이거 대응작업-커밋-푸시-코멘트까지", "근본적으로 대응", "대응할 게 없으면 근거 코멘트" 요청에 사용한다.
Local guide for using interactive_shell in this repo. Prefer it for dev servers, TUI apps, REPLs, database shells, log viewers, and commands that need a visible terminal overlay. Do not use it for subagent-style delegation; use the subagent tool for that.
열린 PR의 GitHub Actions/CI 실패를 분석해 원인을 분류하고, 코드·generated artifact·테스트·환경 문제를 근본 대응한 뒤 검증, 커밋, push까지 수행해야 할 때 사용한다. "CI 실패 대응", "체크 실패 봐줘", "Actions 실패 고쳐줘", "pr-checks 실패", "ci-ship" 요청에 사용한다.
PR을 만들기 전 또는 remote에 올리기 전, 변경사항을 의도 단위로 커밋하고 lint/typecheck/test/build 같은 사전 검증을 통과시킨 뒤 push해야 할 때 사용한다. "ship 해줘", "커밋해서 푸시", "올리기 전에 검증", "push 준비" 요청에 사용한다.
PR/구현 검증을 PM·비개발자도 이해할 수 있는 캡처 중심 HTML 리포트로 만든다. Jira/Notion/Slack/와이어프레임/PR test plan 같은 기획 근거를 사용자-facing 동작과 매핑하고, 핵심 UI 흐름은 스크린샷/GIF를 primary evidence로 증명한다. 로직/API/DB/code diff 검증은 하단 기술 보조 검증으로 정리한다. 기본은 로컬 확인용이며 업로드/PR 업데이트는 명시 요청 시에만 한다.