Ponytail Beck Tdd

Ponytail + Beck TDD

켄트 벡의 TDD와 Tidy First 글을 개발 절차의 근거로 삼고, Ponytail의 유지보수 가능한 최소 구현 원칙을 적용한다. 벡이 작성하거나 공인한 스킬은 아니다. 이 스킬의 설명·검토·편집 요청 자체는 제품 코드 변경 요청이 아니다.

요청에 맞는 경로

• 새 기능이나 버그 수정은 아래 개발 순환을 따른다.
• 기존 구현·테스트의 점검이나 개선은 기존 테스트 개선 절차를 먼저 읽고, 현재 보장과 문제를 확인한 뒤 필요한 변경만 한다. 정상인 기존 동작의 테스트 보강에 새 동작 개발의 RED를 강요하지 않는다.
• 점검·리뷰만 요청하면 근거와 개선안을 보고한다. 개선까지 요청하면 허용된 범위의 변경과 검증까지 진행한다. 테스트 개선 중 발견한 제품 결함의 수정 범위는 요청과 기존 권한으로 판단한다.

작업을 시작할 때

• 현재 요청, 저장소 지침, 기존 변경, 영향을 받는 동작과 호출자를 확인한다. 관련 경로부터 읽는다.
• 필요한 동작과 기존에 보존할 동작을 테스트 시나리오 목록으로 적는다. 기존 작업 목록이 있으면 재사용한다. 구현 구조를 미리 확정하거나 모든 테스트를 한꺼번에 작성하지 않는다.
• 전체 목표와 필수 제약은 유지하되, 지금 구현할 한 가지 동작으로 작업 범위를 좁힌다. 나머지 요구사항은 목록에 남겨 끝까지 처리한다.

개발 순환

1. RED: 목록에서 다음 한 가지 동작을 골라 가장 단순한 실행 가능한 실패 테스트를 작성하고 실행한다. 기대 결과는 요구사항에서 도출한다. 실패가 원하는 동작의 부재 때문인지 확인하고 환경·도구 오류와 구분한다.
2. GREEN: 새 테스트와 기존 관련 테스트가 통과할 만큼만 제품 코드를 변경한다. 새 사례가 발견되면 목록에 추가한다. 현재 테스트가 요구하지 않은 기능을 미리 구현하지 않는다.
3. 구조 정리: 테스트가 통과한 상태에서 필요한 만큼 이름, 중복, 결합, 상태 관리 등을 개선한다. 구조 변경과 동작 변경을 구분하고, 구조 변경 전후 동작을 검사한다. 다음 변경을 쉽게 만드는 데 필요한 범위에서 멈춘다.
4. 테스트 목록의 다음 동작으로 진행한다. 한 순환의 통과를 전체 요청의 완료로 취급하지 않는다.

실패를 숨기려고 테스트를 삭제·비활성화하거나 검증을 약화하지 않는다. 실제 계산 결과를 그대로 기대값으로 복사하지 않는다. 기대값이나 테스트 자체가 잘못되었다면 요구사항에 근거해 수정하고 이유를 남긴다.

순수한 구조 변경에는 기존 테스트로 동작 보존을 확인한다. 동작 변화가 없는 작업에 새 실패 테스트를 억지로 만들지 않는다. 관련 테스트와 저장소의 필수 검사 범위를 지키고, 긴 검사 실행 시점은 프로젝트 지침과 변경 위험에 맞춘다.

테스트 묶음을 다듬는 기준

• 테스트는 동작을 설명하고 서로 독립적으로 실행되어야 한다. 내부 구조를 그대로 복제한 테스트나 검증 없는 커버리지용 테스트를 만들지 않는다.
• 테스트 전체가 주는 신뢰성, 실행 속도, 읽기 쉬움, 수정 비용, 실패 원인을 좁히는 능력을 함께 평가한다. 개수나 크기를 목표로 삼지 않는다.
• 작은 테스트를 복사하고 계속 늘려 거대한 시나리오로 만들지 않는다. 더 큰 테스트가 생겼다는 이유로 작은 테스트를 자동 삭제하지 않는다.
• 동일한 검증이 반복되면 작은 테스트가 제공하는 진단력을 살리고 더 큰 테스트의 중복 검증을 줄이는 구성을 먼저 검토한다. 각 테스트는 필요한 초기 상태를 직접 준비하며, 다른 테스트의 실행 결과에 의존하지 않는다.
• 동작의 변형들이 실제로 독립적이면 각 변형은 집중된 테스트로 검사하고, 함께 연결되는지는 필요한 통합·관통 테스트로 확인한다. 독립성이 입증되지 않은 상호작용은 별도로 검사한다.
• 통합·관통 테스트는 실제 제품 구성요소 사이의 연결을 검증한다. 핵심 구현을 전부 대역으로 바꾼 호출 확인을 전체 동작 검증으로 보고하지 않는다. 외부 시스템이나 장치에 대역을 사용했다면 검증 경계를 밝힌다.
• 테스트를 삭제하거나 검증을 옮길 때는 전체 묶음이 잃는 동작 보장과 진단력을 검토하고, 변경 후 관련 검사를 실행한다. 어려운 회귀의 검출력이 불분명하면 알려진 실패 재현이나 제한된 결함 주입으로 확인한다. 일괄 삭제 목표나 의무적인 전체 변이 테스트 체계를 도입하지 않는다.

Ponytail 구현 기준

• 기존 코드, 표준 라이브러리, 플랫폼의 기본 기능, 이미 설치된 의존성을 먼저 사용한다.
• 원인이 있는 경계에서 수정한다. 현재 필요가 없는 계층, 팩토리, 레지스트리, 범용 프레임워크, 의존성을 추가하지 않는다. 중복은 설계의 단서이며 즉시 추상화하라는 명령이 아니다.
• 필요한 기능, 복구, 데이터 무결성, 보안, 접근성을 충족하는 가장 단순하고 유지보수 가능한 구현을 선택한다.
• 관련 없는 전면 정리나 재설계를 끼워 넣지 않는다. 단순함을 이유로 요청한 동작이나 저장소의 필수 검사를 생략하지 않는다.
• 사용자가 Ponytail 강도를 지정했다면 유지하고, 지정하지 않았다면 full의 구현 기준을 따른다. 모드 종료·변경 요청을 존중한다.

완료와 보고

완료한 동작, 실제 확인한 실패와 통과, 구조 정리, 중요한 테스트 구성 변경, 남은 제약을 간결하게 설명한다. 정적 검사, 빌드, 실행 테스트, 실제 장치·운영 환경의 증거를 구분한다. 테스트 실행이 불가능하면 시도한 내용과 미검증 범위를 밝힌다.

구조 변경과 동작 변경은 검토 가능한 단위로 구분한다. 커밋을 요청받았다면 두 종류를 분리하되, 이 개발 절차가 커밋·푸시·배포의 추가 권한을 부여하지는 않는다.

출처 확인, 설계 설명 또는 이 스킬 개정이 필요할 때 근거와 해석을 읽는다. 일반 구현마다 전체 참고 글을 다시 읽을 필요는 없다.