현재 코드와 테스트를 보고 변이 테스트 도구 개선하기

## 변경 전마다 현재 코드, 테스트, 설계 기록 확인하기 현재 소스 트리, 테스트, 스키마, 아키텍처 결정, 기여자 문서를 명세로 간주하라. 저장소의 근거와 충돌할 때는 기억, 오래된 가정, 일반적인 프레임워크 패턴을 신뢰하지 마라. 각 기능이나 수정마다 다음을 수행하라. 1. 관련 이름, 실패, 잘못된 입력, 경계 사례를 포함하여 가장 가까운 단위·통합·종단 간·아키텍처·자체 변이 테스트를 검색하라. 2. 담당 구현을 읽고 순서, 기본값, 실패 의미론, 성능 제약을 파악하라. 3. 코드만으로 의도가 분명하지 않으면 참조된 설계 기록과 상위 프로젝트의 논의를 읽어라. 4. 구현 전에 초점을 좁힌 실패 사례를 작성하거나 이식하고 해당 근거와 연결하라. 5. 자명하지 않은 메커니즘, 버전 관문, 의도적인 비호환성의 이유를 기록하라. 프로젝트 용어집을 일관되게 사용하라. 변이는 다른 프로세스에서 적용될 수 있는 직렬화 가능한 설명으로, 변이 연산자는 별도의 적격성 검사와 변환의 결합으로 모델링하라. 수정하기 전에 실행 파이프라인을 그려라. 구성, 소스 및 커버리지 수집, AST 보강, 변이 생성, 변이체 실행, 선택적 후속 분석, 보고는 순서가 정해진 책임 경계다. 변경으로 문서화된 경로, 관문, 규칙이 사실과 달라지면 같은 변경에서 해당 문서도 갱신하라. ## 공개 API, 타입, 이름 짓기 규칙 지키기 - 프로덕션 코드는 테스트나 성능 측정에 의존해서는 안 된다. 배포되는 테스트 도우미는 명시적인 프로덕션 측 테스트 네임스페이스에 두고 의존 방향을 기계적으로 강제하라. - 공개 API를 허용 목록으로 취급하라. 나머지는 모두 내부용으로 표시하고 확장 지점을 문서화하며, 허용 목록의 모든 변경을 호환성 사건으로 분류하라. - 테스트 대역으로 절대 교체하지 않을 클래스에만 엄격한 `final`을 사용하라. 한 클래스를 모의 처리하려는 목적만으로 인터페이스를 추가하지 말고, 모의 처리 가능한 서비스는 기술적으로 재정의할 수 있게 유지하라. - 함수와 상수를 일관되게 가져오라. `false`를 반환할 수 있는 호출에는 명시적인 실패 의미론을 선택하라. 실패가 예외적이면 안전한 래퍼를 사용하고 false 반환이 필요하면 이름이 명확한 비안전 별칭을 사용하라. - 타입이 지정된 상수, 명시적인 재정의 표시, 불변 값 객체를 선호하라. 자체 속성에 결과를 메모이제이션하는 클래스는 `readonly`로 만들지 마라. - 정적 분석으로 증명할 수 없는 불변 조건에만 런타임 어설션을 사용하라. 어설션 메시지는 실패가 의미하는 버그를 식별해야 한다. - 이름으로 계약을 표현하라. `find*`는 null 가능 값을 반환하고, `get*`는 값을 보장하며, 이름 있는 생성자는 도메인 의미를 나타내고, 예외는 일반적인 `Exception`으로 끝내지 말고 도메인 실패를 설명해야 한다. - 인스턴스당 한 번의 보이지 않는 재사용에는 `Memoized*`를 사용하라. 호출자가 키, 무효화, TTL, 공유 저장소를 관찰할 수 있을 때만 `Cached*`를 사용하라. - 순수 정적 클래스나 상수만 담은 클래스는 인스턴스화할 수 없게 하라. 의존성 주입은 상태를 가지거나 입출력을 수행하는 협력 객체에만 사용하라. - 상위 프로젝트에서 복사한 코드는 식별 가능하게 유지하고 출처 표시를 보존하며, 의도적인 모든 로컬 차이를 문서화하라. ## 지연 평가를 유지하고 하위 프로세스 명령을 인수 배열로 전달하기 - 비용이 큰 재사용 가능 값은 메모이제이션된 지연 추상화로 표현하라. 가공하지 않은 생성기는 한 번만 순회할 수 있으며 되감기, 개수 계산, 버퍼링을 해서는 안 된다. - 엄격한 일대일 매핑과 일대다 평탄화 매핑을 구분하라. 비슷한 메서드 이름이 서로 다른 스트림 카디널리티를 감추게 하지 마라. - 측정된 성능 핵심 경로에서 참조에 의한 변이는 소유권과 제자리 효과가 문서화된 경우에만 허용하라. - 시간이나 디스크 기본 기능을 직접 호출하지 말고 시계와 파일 시스템 추상화를 주입하라. 테스트에서 시간과 파일 시스템의 결과를 제어할 수 있어야 한다. - 하위 프로세스 명령을 처음부터 끝까지 문자열 인수 배열로 표현하라. 배열 원소 하나는 정확히 인수 하나다. 셸 명령을 미리 결합하거나 공백으로 분리될 것이라 가정하지 마라. - 타입 지정 접근자와 지연 팩터리를 갖춘 명시적 서비스 레지스트리를 하나만 유지하라. 소비자는 타입 없는 서비스 조회를 사용해서는 안 되며, 추측으로 추가한 도달 불가능한 서비스는 금지한다. - 공유 프로세스 상태를 변경하지 말고 컨테이너를 복제하여 구성을 다시 바인딩하라. 배선 클로저가 복잡해지면 타입 지정 빌더를 추출하라. - 각 필드의 의미론에 따라 구성을 병합하라. null 가능 재정의에는 null 병합을 사용하고, 어느 쪽 소스든 강제로 켤 수 있는 플래그에는 논리합을 사용하라. 이 규칙을 통합하면 동작이 눈에 띄지 않게 바뀐다. - 상대 출력 경로는 구성 파일 위치를 기준으로 해석하고, 명시적으로 허용된 스트림 경로를 보존하며, 사용자가 의도한 변경만 처리하도록 버전 관리 기준점을 계산하라. ## AST 처리 순서를 지키고 변이 전 AST를 바꾸지 않기 - 방문자 등록 순서를 알고리즘의 일부로 취급하라. 소비자보다 먼저 이름과 부모를 해석하고, 테스트를 연결하기 전에 제외를 적용하며, 각 파일을 처리하기 전에 재사용 가능한 방문자 상태를 초기화하라. - 타입 지정 노드 속성 접근자를 통해 정보를 전달하라. 제외는 노드를 부적격으로 표시할 뿐이며, 보강 과정에서 노드를 제거하거나 교체하지 않는다. - 비용이 큰 커버리지 조회는 지연 방식으로 적격 노드에만 연결하라. 커버리지 파일 탐색과 파일별 테스트 위치 파싱 사이의 두 단계 지연 평가를 보존하라. - XML 질의는 네임스페이스를 인식하는 안전한 래퍼를 통과시켜라. 순서가 있는 형식 대체 경로와 그 버전 근거를 유지하며, 정리 작업으로 아직 지원되는 분기를 제거해서는 안 된다. - 프로세스 실행기를 스트리밍 방식으로 유지하라. 사용자 테스트가 사용하는 작업 프로세스 식별자는 1부터 시작하는 정확한 API 값이다. 후속 분석은 스케줄러별 분기가 아니라 프로세스 컨테이너 체인에 속한다. - 스케줄링 계산에서 단위 의미론을 보존하라. 작업을 대기열에 넣는 데 걸린 시간은 항목 수가 아니라 기간이다. 작업 프로세스 슬롯을 재사용하기 전에 완료된 컨테이너 참조를 해제하라. - 버전별 테스트 실행기 구성 변경을 분리하고 조합 가능하게 유지하라. 기준이 되는 최신 커버리지 구성, 사용자 포함 필터, glob 패턴을 지원하는 경로, 레거시 문서 형식을 보존하라. - 토큰 위치와 노드 클래스로 변이 대상을 일치시켜라. 변이 전에 원본 AST를 복제하고, 형식 보존 출력을 위해 원본 토큰을 유지하며, 원본 트리를 바이트 단위로 동일하게 보존하라. - 변이 해시, 필드 순서, 필수 위치 속성을 공개 재실행 계약으로 취급하라. 노드를 재구성할 때 모든 자식과 속성을 복사하라. 유효한 교체 값은 스칼라, 노드 하나, 노드 목록 중 하나일 수 있다. ## 잘못되거나 동등한 변이체를 만들지 않는 변이 연산자 만들기 완전한 변이 연산자 변경은 구현, 모든 중앙 레지스트리와 프로필 매핑, 구성 스키마, 표준 테스트를 갱신하며, 동작이 공개된 경우 사용자 문서도 갱신한다. - 변이 연산자의 공개 표면은 정의, 안정적인 이름, 적격성, 변환으로 최소화하고, 구성 가능한 변이 연산자에만 구성 접근을 제공하라. - 정의에는 변이, 범주, 변경 전후 예시, 사용자가 변이체를 제거하는 방법을 설명하라. - 적격성 검사에서는 언어 식별자를 실제 대소문자 규칙에 따라 비교하고, 중첩 문맥이 중요하면 상위 노드를 순회하라. - 구문 오류, 반드시 발생하는 치명적 오류, 동등한 변이, 무한 루프, 다른 변이 연산자가 이미 담당하는 변이를 절대 생성하지 마라. - 중복이나 동등성이 생길 수 있으면 근거를 밝히고 이름 있는 비변이 사례를 추가하라. - 교체 AST 노드를 만들 때 모든 자식과 메타데이터를 복사하여 속성이 조용히 사라지지 않게 하라. - 프로덕션 순회 테스트 장치를 통해 변이 연산자를 실행하라. 적격성이나 범위 동작을 우회하는 일회성 순회기를 만들지 마라. - 예상 출력이 없음을 명시적인 비변이 어설션으로 취급하고, 데이터 세트 이름이 명세처럼 읽히게 하라. - 변이 양이 바뀌면 변이 연산자별로 생성, 제거, 생존, 시간 초과된 변이체 수를 보고하라. ## 매번 같은 결과를 내고 변이체를 잡아내는 테스트 작성하기 - 모든 구체 소스 클래스에 표준 테스트를, 모든 테스트에 명시적인 커버리지 대상을 부여하라. - 입출력 테스트는 통합 테스트로, 입출력이 없는 테스트는 비통합 테스트로 분류하라. 양방향으로 이 경계를 강제하라. - 테스트를 결정론적으로 유지하라. 생성된 임시 경로를 사용하고, 출력 순서에 민감한 테스트 데이터의 동시성을 고정하며, 환경 변수를 백업하고, 존재하지 않는 경로를 하드코딩하지 마라. - 설명적인 사례 이름을 가진 정적 데이터 공급자를 사용하라. 매개변수가 많은 테스트 시그니처에는 이름 있는 인수와 기본값을 선호하되, 서로 다른 부분 집합을 사용하는 테스트끼리 공급자 하나를 공유하지 마라. - 깊은 모의 객체 그래프를 작은 불변 빌더나 가짜 구현으로 대체하라. 느슨한 어설션 때문에 변이가 빠져나가지 않도록 모의 객체 기대값에서 정확한 인수를 검증하라. - 변이가 드러나도록 프로덕션 코드를 구성하라. 테스트할 수 없는 매직 리터럴보다 조기 반환, 분리된 불리언 결과, 이름 있는 상수를 선호하라. - 누락된 의존성을 숨기는 생성자 기본 인수를 피하라. 데이터 공급자의 기본값은 각 사례가 달라지는 부분만 나타내게 할 때 허용된다. - 프로젝트의 방문자 테스트 장치, 명령 테스트 장치, 기타 프로덕션 인식 테스트 준비물을 사용하라. 집중된 단위 테스트가 있어야 할 자리에 일회성 진단 스크립트를 작성하지 마라. - 생존한 변이체는 테스트가 빠졌거나 코드를 재구성해야 함을 뜻한다. 억지 테스트를 작성하지 말고 실제로 제거할 수 없거나 성능에만 관련된 사례를 논의하라. - 반복 작업 중에는 집중 테스트를 실행하라. 인계 전에는 저장소 포매터, 아키텍처 및 정적 분석 검토, 관련 통합 그룹, 기준이 되는 전체 테스트 스위트를 실행하라. ## 코드를 정리할 때도 버전별 설정과 대체 경로 남기기 - 버전 경계와 단계별 대체 경로를 보호 대상 동작과 함께 문서화하라. 최신 형식만 익숙하다는 이유로 호환성 매트릭스를 단순화하지 마라. - 순서가 있는 구성 미니 언어에서는 키를 차례로 처리하고 뒤의 항목이 우선하게 하라. `false` 센티널은 중첩 프로필을 포함해 해당 키가 등록한 모든 것을 제거해야 한다. - 설정을 결합할 때 병합 방향과 명시적인 중복 제거를 보존하라. 명령줄 선택은 파일 선택을 대체할 수 있지만 전역 제외 규칙은 계속 유지해야 한다. - 단일 레지스트리를 지원되는 모든 변이 연산자의 기준 정보원으로 삼고 자동화된 커버리지 검사를 여기서 파생하라. - 테스트 이름 필터가 정규식 한계에 가까워지면 정밀 필터링에서 안전한 상위 집합으로 완화하고, 마지막에는 필터를 생략하여 전체 스위트를 실행하라. 아무 테스트도 실행하지 않는 상태로 절대 완화하지 마라. - 빈 선택이 유효할 때 실행기의 “실행된 테스트 없음” 결과를 통과로 간주하는 연계 규칙을 보존하라. - 디버거 제거 후 재시작에서는 현재 로드된 확장 기능만으로 역량을 추론하지 마라. 재시작 처리기에 건너뛴 버전을 묻고 필요한 자식 프로세스에서만 커버리지를 활성화하라. - 메모리 한도 조정은 정적 분석 후 임시 자식 프로세스 구성에만 적용하고, 명시적 보호 조건 아래 최선 노력 방식으로 수행하라. - 프로세스를 많이 사용하는 최적화는 유지하기 전에 측정하라. 런타임이나 도구 체인 버전이 바뀌면 오래된 성능 우회책을 다시 검증하라. ## 잠금 파일을 지키고 CI를 통과한 풀 리퀘스트만 병합하기 무인 설치 중 고정된 잠금 파일을 절대 우회하지 마라. 의존성 해결에 잠금 파일 변경이 필요하면 중단하고 명시적인 승인을 받아라. 정확한 버전, 무결성 해시, 라이선스 호환성은 공급망 경계다. 보호된 기본 브랜치에 직접 푸시하거나, 브랜치 보호를 우회하거나, 관리 권한으로 병합을 강제하지 마라. 다음 순서를 사용하라. 1. 초점을 좁힌 기능 브랜치를 만들어라. 2. 가장 작고 일관된 변경을 수행하고 집중 검사를 실행하라. 3. 저장소에서 요구하는 메시지 규칙에 따라 커밋하라. 4. 브랜치를 푸시하고 병합 요청을 열어라. 5. 필수 형식, 타입, 단위, 통합, 종단 간 검사가 모두 끝날 때까지 기다려라. 6. 실패를 우회하지 말고 수정하라. 7. 승인된 방식으로 병합하고 브랜치를 제거하라. 리팩터링과 동작 변경을 섞지 마라. 수정된 버그에는 회귀 테스트가 필요하고, 호환성 단절에는 명시적인 릴리스 노트와 마이그레이션 지침이 필요하며, 사용자에게 보이는 동작에는 동기화된 사용자 문서가 필요하다. 릴리스 자동화가 관례적 커밋 메시지에서 메타데이터를 도출하게 하라. 문서화된 재정의는 의도적인 재분류에만 사용하고 생성된 릴리스 결과물을 절대 수동 편집하지 마라. 신뢰할 수 없는 기여에 대한 지속적 통합은 비밀 정보 없이 읽기 전용 권한으로 실행하라. 비밀 정보가 필요한 미리보기는 권한 있는 유지관리자가 신원 확인을 거친 명령으로 명시적으로 실행하지 않는 한 포크를 건너뛰어야 한다. 배포한 모든 예시를 빌드 매트릭스에 등록하고 해당 경로, 상태, 내용을 확인하는 기본 동작 테스트를 추가하라. 필수 검사와 배포 후 근거가 통과해야만 릴리스 또는 배포가 완료된다.