discipline-tddlisted

# TDD 실천 규율 ## 언제 쓰나 TDD 사이클을 어떻게 운용할지, 어떤 학파를 선택할지, 테스트 목록을 어디서 시작할지, AI 보조 구현 시 테스트를 어떻게 명세로 활용할지가 불명확할 때 로드한다. 경계: - pytest fixture·mock·assert·팩토리 상세 작성법 → `dddjango-implementation-test` - 테스트 코드 품질(가독성·구조·냄새) 원칙 → `dddjango-discipline-cleancode` - Django TestClient·API 테스트 메커니즘 → `implementation-django` - migration 전용 테스트와 DB-backed 현행 동작 테스트의 기술적 식별 → `dddjango-implementation-test` ## 핵심 운영 원칙 - TDD의 목표는 작동하는 깔끔한 코드다: 두려움 없이 변경할 수 있는 용기가 핵심 (§1.1–§1.2) - Red-Green-Refactor 순서를 지켜라: 실패하는 테스트 먼저, 통과 후에만 리팩토링 (§2.1) - 고전 학파(상태 검증)를 기본으로, 협력 구조 설계가 목적일 때만 런던 학파(행위 검증)를 선택한다 (§3.1–§3.4) - 좋은 테스트의 4대 기둥: 회귀 방지, 리팩토링 내성, 빠른 피드백, 유지 보수성 — 리팩토링 내성은 타협하지 않는다 (§4.1–§4.4) - 테스트 목록은 후보일 뿐이다. 모든 영구 test artifact의 add/update/move/split/rename/remove/weaken·재조직 전에 §5.5 입장 심사를 거치며, 의미 보존 재조직은 새 case·Red 없이 전후 보호가 같아야 한다 (§5.1–§5.3) - 영구 테스트는 승인된 현행 계약·독자 실패·기존 권위 coverage를 판정한다. 공개 Python 계약은 별도 사용자 승인 또는 deployed consumer evidence 중 하나로 자격을 얻는다. `pending`은 G1을 막고 `reuse`·`reject`는 test artifact write가 0이다 (§5.5) - migration 전용 테스트는 만들지 않고 기존 것도 삭제한다(절대 규칙 — `migrations/`는 생성물·`check-test-config` #637). 과거 버그에서 태어났어도 현행 계약을 검증하는 회귀 테스트는 보존한다 (§5.5) - 초록 막대 전략: 가짜로 구현하기 → 삼각측량 → 명백한 구현 순으로 진행 (§6.1–§6.3) - 테스트는 격리하고, AAA 패턴으로 구조화하라: Arrange-Act-Assert (§7.1–§7.2) - Mock보다 출력·상태 검증을 우선한다: Mock 과다 사용은 리팩토링 내성을 약화시킨다 (§7.6) - Outside-In 이중 루프도 바깥·안쪽 테스트를 자동 의무화하지 않는다. Walking Skeleton은 실제 얇은 E2E 행동이다 (§9.1–§9.2) - AI 보조 TDD에서 테스트는 명세다: 개발자가 테스트를 작성하고, AI 구현은 테스트를 통과한 후 검증한다 (§17.1–§17.