|
| 1 | +# Fixture Monkey - Claude Code 가이드 |
| 2 | + |
| 3 | +## 절대 규칙 |
| 4 | + |
| 5 | +- 기존 테스트는 **삭제/수정/주석 처리 금지** |
| 6 | +- 테스트 실패 시 바로 롤백 (개선 가능하다고 판단되면 사용자에게 롤백 여부 확인) |
| 7 | +- Adapter 작업 시 `fixture-monkey`, `fixture-monkey-api` 모듈 코드 수정 금지 (필요 시 사용자에게 확인) |
| 8 | +- 커밋은 사용자가 명시적으로 요청할 때만 (메시지는 영어) |
| 9 | +- 데드 코드는 제거한다 |
| 10 | +- [작업 흐름] 을 보고 작업을 한다 |
| 11 | + |
| 12 | +## 프로젝트 구조 |
| 13 | + |
| 14 | +| 모듈/폴더 | 역할 | |
| 15 | +|------|------| |
| 16 | +| `fixture-monkey/` | 메인 모듈 (ArbitraryBuilder, FixtureMonkey 등) | |
| 17 | +| `fixture-monkey-api/` | 공용 API 인터페이스 | |
| 18 | +| `object-farm-api/` | JvmNodeTree, PathExpression 등 구조 관련 API | |
| 19 | +| `fixture-monkey-tests/` | 통합 테스트 | |
| 20 | +| `history/` | 벤치마크 결과 + 작업 히스토리 | |
| 21 | +| `guide/` | 프로파일링 가이드 등 참고 문서 | |
| 22 | + |
| 23 | +## 빌드 및 테스트 |
| 24 | + |
| 25 | +```bash |
| 26 | +./gradlew build # 전체 빌드 |
| 27 | +./gradlew :fixture-monkey:test # 특정 모듈 테스트 |
| 28 | +./gradlew :fixture-monkey:test --tests "com.navercorp.fixturemonkey.test.FixtureMonkeyAdapterTest" |
| 29 | +``` |
| 30 | + |
| 31 | +**Adapter 작업 시 회귀 테스트**: |
| 32 | +```bash |
| 33 | +./gradlew clean \ |
| 34 | + :fixture-monkey:test --tests "com.navercorp.fixturemonkey.adapter.*" \ |
| 35 | + :fixture-monkey-tests:java-tests:test --tests "com.navercorp.fixturemonkey.tests.java.adapter.*" \ |
| 36 | + :fixture-monkey-tests:java-17-tests:test --tests "com.navercorp.fixturemonkey.tests.java17.adapter.*" \ |
| 37 | + :fixture-monkey-tests:kotlin-tests:test --tests "com.navercorp.fixturemonkey.tests.kotlin.adapter.*" |
| 38 | +``` |
| 39 | + |
| 40 | +## 코드 스타일 |
| 41 | + |
| 42 | +- 탭 들여쓰기 (스페이스 아님) |
| 43 | +- 주석은 `// given`, `// when`, `// then`만 허용 (예외 시 사용자 확인) |
| 44 | +- Javadoc은 public API에만 작성 |
| 45 | +- `@API` 어노테이션으로 API 안정성 표시 (`EXPERIMENTAL`, `MAINTAINED` 등) |
| 46 | + |
| 47 | +## 디버깅 절차 |
| 48 | + |
| 49 | +테스트 실패 시 아래 순서를 따른다: |
| 50 | + |
| 51 | +1. **코드 분석 우선** - 코드를 읽고 원인 추론 |
| 52 | +2. **런타임 확인** - 분석만으로 부족하면 디버그 로그 추가 후 `--info` 플래그로 실행 |
| 53 | +3. **문제 격리** - 반복 실패 시 최소 재현 테스트 작성 (sample() → adapt → 특정 Phase 순으로 좁힘) |
| 54 | +4. **수정 및 검증** - 원인 부분만 수정, 기존 테스트 전체 통과 확인 |
| 55 | + |
| 56 | +tracer 활성화: |
| 57 | +```java |
| 58 | +FixtureMonkey fm = FixtureMonkey.builder() |
| 59 | + .plugin(new JavaNodeTreeAdapterPlugin() |
| 60 | + .tracer(AdapterTracer.console())) |
| 61 | + .build(); |
| 62 | +``` |
| 63 | + |
| 64 | +## 테스트 케이스 관리 |
| 65 | + |
| 66 | +테스트 작성/발견 시 해당 경우의 수가 **기존 테스트에서 커버하지 못하는 새로운 경우의 수**라고 판단되면: |
| 67 | + |
| 68 | +1. `test-case/` 폴더의 해당 카테고리 마크다운 파일에 경우의 수를 추가 |
| 69 | +2. 카테고리가 없으면 새 마크다운 파일 생성 |
| 70 | +3. 각 경우의 수는 **원자적 단위**(하나의 독립된 동작/조건)로 기록 |
| 71 | +4. 타입 변형(String→Int, List→Set→Array)은 같은 경우의 수로 취급 — 동작이 다른 경우만 별도 |
| 72 | + |
| 73 | +### 파일 형식 |
| 74 | + |
| 75 | +- `[x]` 이미 테스트됨 (`테스트파일:메서드명`) |
| 76 | +- `[ ]` 미구현 |
| 77 | + |
| 78 | +### 카테고리 |
| 79 | + |
| 80 | +| 파일 | 카테고리 | |
| 81 | +|------|---------| |
| 82 | +| `basic-generation.md` | 기본 타입/객체 생성 | |
| 83 | +| `container.md` | 컨테이너 타입 | |
| 84 | +| `customization.md` | set/size/apply/postCondition 등 | |
| 85 | +| `generic.md` | 제네릭 타입 | |
| 86 | +| `interface-abstract.md` | 인터페이스/추상/sealed class | |
| 87 | +| `recursive.md` | 재귀/순환 참조 | |
| 88 | +| `instantiator.md` | 생성자/팩토리 메서드 | |
| 89 | +| `introspector.md` | ArbitraryIntrospector 관련 | |
| 90 | +| `register.md` | register/registerGroup | |
| 91 | +| `strict-mode.md` | strict mode | |
| 92 | +| `plugin.md` | 플러그인 | |
| 93 | +| `property-selector.md` | PropertySelector/expression | |
| 94 | +| `kotlin.md` | Kotlin 전용 | |
| 95 | +| `annotation-validation.md` | 어노테이션/validation | |
| 96 | +| `then-apply-ordering.md` | thenApply/size/set 순서 상호작용 | |
| 97 | + |
| 98 | +## 문서 관리 규칙 |
| 99 | + |
| 100 | +- 작업 중 생성한 문서(가이드, 분석 등)는 `guide/`에 저장한다 |
| 101 | +- 벤치마크 실행 시 결과를 `history/benchmark-history.md`에 추가한다 |
| 102 | +- 작업 완료 시 `history/work-log.md`에 날짜와 한 줄 요약을 추가한다 |
| 103 | + - 형식: `- YYYY-MM-DD: 작업 내용 한 줄 요약` |
| 104 | + |
| 105 | +## Plan 작성 규칙 |
| 106 | + |
| 107 | +1. Claude Code가 자동 생성하는 plan 파일에 작성 |
| 108 | +2. 파일명: 작업 내용을 요약하는 제목 (예: `add-map-entry-support.md`) |
| 109 | +3. 문서 내용: 작업 목표, 변경 대상 파일, 구현 계획 |
| 110 | +4. 구현 완료 후 `plans/` 디렉토리에 최종 plan 복사 |
| 111 | + |
| 112 | +## 문서 동기화 |
| 113 | + |
| 114 | +코드 변경 시 관련 문서도 함께 업데이트: |
| 115 | +- `AdapterTracer`, `ResolutionTrace` 변경 시 → `architecture/adapter-tracer.md` 업데이트 |
| 116 | + |
| 117 | +## 작업 흐름 |
| 118 | +아래 흐름을 거이 무조건 지켜야 한다. 지킬 필요가 없거나 왜 지켜야할지 모르겠으면 사용자에게 묻는다 |
| 119 | + |
| 120 | +1. 재현 가능한 테스트를 작성한다 |
| 121 | +2. 기능을 구현한다 |
| 122 | +3. 재현 가능한 테스트를 실행한다. 실패할 경우 2번을 진행한다. 성공하면 4번으로 간다 |
| 123 | +4. 회귀 테스트를 실행한다 |
0 commit comments