OxideTerm 테스트 감사
계층이 동작을 소유하는 곳에서 유용한 회귀 방지를 유지하십시오. 요청된 변경을 해결하는 가장 작은 검토를 사용하십시오. 테스트 개수나 삭제된 줄이 아닌 보존된 계약과 감지된 오류로 결과를 판단하십시오.
해당 AGENTS.md를 읽으십시오. 저장소 루트에서 명령을 실행하십시오. 검증 매트릭스 및 테스팅 가이드는 프로젝트별 검사를 정의합니다. 이 스킬은 테스트 품질 결정을 제공합니다.
범위 선택
- 테스트 작성 또는 변경: 해당 동작에 대한 작성 질문을 적용하고 가장 가까운 기존 테스트 범위를 검사하십시오.
- 실패 진단: 테스트가 실패한 이유를 파악하고 구현, 기대치, 픽스처 또는 환경 중 무엇이 잘못되었는지 확인한 후 편집하십시오.
- 기존 테스트 감사: 요청된 모듈 또는 동작을 검토하고 각 제안된 변경에 대한 증거를 기록하십시오. 요청된 범위인 경우에만 전체 하위 시스템으로 확장하십시오. 각 배치에 대해 동일한 증거 기준을 사용하십시오.
이 스킬을 생성하거나 호출한다고 해서 광범위한 정리, 하위 에이전트, 커밋, 푸시 또는 PR이 허가되는 것은 아닙니다. 사용자의 기존 권한 및 검토 전용 경계를 존중하십시오. 편집이 이미 승인되었고 증거가 충분하면 추가 승인 라운드 없이 진행하십시오.
작성 질문
테스트를 추가하거나 변경하기 전에 다음을 식별하십시오.
- 보호되는 관찰 가능한 동작 또는 독립적인 계약.
- 그럴듯한 회귀 및 실패할 특정 단언.
- 가장 가까운 기존 테스트 범위가 놓친 부분. 적절할 때 해당 범위를 확장하십시오. 다른 계층은 별개의 통합, 프로토콜 또는 수명 주기 위험이 필요합니다.
- 테스트에 비즈니스 호출자가 없는 프로덕션 익스포트, 스위치, 래퍼 또는 인젝션 훅이 필요한지 여부. 기존 소유 경계에서 테스트하는 것을 선호하십시오.
구현과 독립적으로 예상 값을 사용하십시오. 픽스처는 올바른 동작과 가능한 버그를 구분해야 합니다. 필터를 테스트할 때는 제외된 후보를 포함하고, 정렬을 테스트할 때는 다른 정렬 키를 포함하며, 수정을 확인할 때는 실제 민감한 입력을 포함하십시오. 생성자 필드 라운드트립, 비어 있지 않은 결과 또는 단언되는 동작을 수행하는 목업만으로는 의도된 워크플로우에 대한 충분한 증거가 아닙니다.
테스트 헬퍼와 픽스처는 합법적으로 테스트 전용일 수 있습니다. 우려되는 점은 프로덕션 API를 왜곡하거나 테스트만을 위해 프로덕션 동작을 유지하는 것입니다.
실패하는 테스트 진단
전체 테스트, 입력, 프로덕션 경로, 주변 테스트 범위 및 관련 변경 기록을 읽으십시오. CI의 경우 실패한 커밋, 작업, 테스트 이름 및 단언을 식별하십시오. 일반적인 0이 아닌 종료는 근본 원인이 아닙니다. 단언이 해당 동작에 의존하는 경우 종속성 소스 또는 유형을 검사하십시오.
증거를 기반으로 실패를 분류하십시오.
- 제품 회귀: 의도된 계약이 여전히 유지됩니다. 실패를 재현하고 승인된 범위 내에서 소유 구현을 수정하십시오.
- 오래된 기대치: 기록과 현재 계약이 의도적인 동작 변경을 보여줍니다. 지원되는 릴리스 형식 및 API에 대한 보호를 유지하면서 예상 동작을 업데이트하십시오.
- 잘못된 테스트 또는 픽스처: 케이스가 주장된 조건을 실행하지 않거나, 우연한 상태에 의존하거나, 관련 없는 이유로 실패합니다. 실제 경계에서 설정과 단언을 수정하십시오.
- 환경 실패: 컴파일, 종속성, 리소스, 플랫폼 또는 외부 픽스처로 인해 동작을 테스트할 수 없습니다. 해당 제한 사항을 보고하십시오. 통과하거나 오래된 테스트로 재해석하지 마십시오.
기본 실패는 테스트를 삭제하는 이유가 아닙니다. 버그 수정의 경우 수정 전에 의도된 실패를 보여주고 수정 후 성공을 보여주십시오. 유효한 CI 증거 또는 캡처된 로컬 기준선이 동일한 실패를 증명하는 경우 이를 재사용하십시오. 의례를 위해 값비싼 검사를 반복하지 마십시오.
예를 들어, .oxide 플러그인 테스트는 비밀번호 없는 검증과 복호화된 가져오기 미리보기를 구분해야 합니다. 암호화된 형식의 검증 응답은 메타데이터를 노출해서는 안 됩니다. 비밀번호를 포함하는 미리보기에는 여전히 명시적으로 예상되는 설명과 연결 이름이 포함되어야 합니다. 해당 단언을 업데이트하면 플러그인 계층에서 또 다른 저수준 복호화 테스트 없이 계약을 유지할 수 있습니다.
편집 전 감사
각 후보를 매개변수 행을 포함하여 전체적으로 읽으십시오. 프로덕션 진입점, 호출자, 관련 종속성, 형제 구현 및 중복 테스트를 추적하십시오. 테스트가 존재하는 이유에 대한 기록과 실제로 실행되는 CI 라우팅을 확인하십시오.
제안된 변경에 대한 간결한 증거 기록을 사용하십시오. 저장된 보고서가 요청되지 않은 경우 작업 응답 내에 포함하십시오.
| 테스트 및 위치 | 동작 및 신뢰할 수 있는 실패 | 결정 | 남아 있거나 수리된 증거 | 검증 |
|---|---|---|---|---|
| 정확한 테스트 이름 및 경로 | 단언이 감지할 수 있는 것 | 유지 / 수정 / 통합 / 삭제 | 명명된 테스트 또는 경계 (관련 기록 포함) | 집중 명령 또는 수동 시나리오 |
- 유지: 독립적으로 의미 있는 계약을 보호합니다.
- 수정: 동작은 중요하지만 입력, 단언, 이름 또는 예상 결과가 잘못되었거나 너무 약합니다.
- 통합: 중복 설정 또는 케이스를 제거하기 전에 별개의 단언을 명명된 기본 테스트로 이동합니다.
- 삭제: 더 강력한 남아 있는 증거의 이름을 지정하거나 동작에 더 이상 지원되는 계약이 없음을 입증하십시오. 불확실성은 조사하거나 유지하는 것을 의미합니다.
테스트와 함께 제거된 프로덕션 코드의 경우 비테스트 호출자를 식별하고 코드가 오래된 이유를 설명하십시오. 헬퍼, 익스포트, 기능 또는 픽스처를 제거하기 전에 참조를 검색하십시오. 감사의 일부로 관련 없는 단순화를 수행하지 마십시오.
조사할 가치가 있는 패턴
- 테스트가 구현의 소스 텍스트, 비공개 호출 형태 또는 정확한 내부 표현을 반복하고 동작을 유지하는 리팩터링 후에 실패합니다.
- 여러 계층이 동등한 입력으로 동일한 헬퍼를 호출하고 자체 통합을 실행하지 않고 해당 단언을 반복합니다.
- 픽스처가 실제 소유자가 생성해야 하는 콜백 순서, 완료 알림 또는 유지된 결과를 미리 준비합니다.
- 거부 테스트가 테스트한다고 주장하는 권한 검사에 도달하기 전에 매개변수 검증에 의해 거부됩니다.
- 동시성, 취소 또는 깨우기 테스트가 경쟁 작업이나 대기자를 생성하지 않고 최종 플래그만 확인합니다.
- 성공 단언이 계약이 내용, ID, 정렬 또는 지속적인 부작용일 때
Ok,Some, 길이 또는 비어 있지 않음만 확인합니다.
이는 조사 신호이지 자동 삭제 규칙이 아닙니다. 독립적인 보안 기본값, 프로토콜 바이트, 지속성 및 마이그레이션 형식, 플러그인 API, 플랫폼 동작, 패키징, 국제화 및 아키텍처 제약 조건을 유지하십시오. 정적 검사는 실제 계약을 보호하고 관련 없는 이름 변경에 영향을 받지 않을 때 유용할 수 있습니다. 느린 실행만으로는 테스트가 중복되었다고 판단할 수 없습니다.
OxideTerm 경계
| 동작 | 선호되는 검증 경계 |
|---|---|
| 구문 분석, 설정 정규화, 직렬화 또는 데이터 병합 | 명시적인 예상 값 및 지원되는 형식 샘플을 사용하는 소유 도메인 크레이트 |
| SSH 노드 공유, SFTP, 포워딩, 재연결 또는 점프 호스트 | 실제 소비자 등록, 취소 및 정리를 포함한 런타임 소유자; 런타임 소유권 참조 |
| 혼합 페이지, 포커스, 팝업 또는 지연된 UI 결과 | 기존 GPUI 테스트 컨텍스트 및 기능 엔티티; 네이티브 IME, 창 및 GPU 동작은 여전히 호스트 검증 필요 |
| 플러그인, MCP 또는 CLI 어댑터 | 실제 디스패치 및 반환된 데이터, 권한, 대상 ID 또는 부작용; 도메인 헬퍼만 재생하지 마십시오 |
| 수정 및 자격 증명 수명 | 관련 출력 또는 소유권 경계를 통한 합성 비밀 입력; 민감한 데이터 참조 |
| 패키징 및 저장소 스크립트 | 기존 스크립트 테스트 또는 검증 매트릭스에서 선택한 실제 드라이런 계약 |
공유 노드 테스트의 경우 하나의 터미널을 닫아도 다른 실제 소비자가 계속 사용 가능해야 합니다. 오래된 결과 처리를 위해 소유자가 변경된 후 이전 완료를 전달하십시오. 기존 픽스처 및 이벤트 기반 동기화를 사용하십시오. 임의의 슬립 및 추가 재시도는 이러한 조건을 설정하지 않습니다.
검증 및 마무리
테스트 실행을 시작하기 전에 관련 소스/테스트 편집을 완료하십시오. 실행 중에 체크아웃을 안정적으로 유지하십시오.
- 집중 테스트 또는 모듈을 실행하십시오. 예:
cargo test -p <crate> <test_filter>. 실제로 소유하는 대상 및 플랫폼을 사용하십시오. 데스크톱 테스트는oxideterm-gpui-app의oxideterm-native바이너리 대상에 있습니다. 독립 실행형 원격 에이전트는--manifest-path agent/Cargo.toml을 사용합니다. - 결과를 읽고 의도된 테스트가 실제로 실행되었는지 확인하십시오. 일치하는 테스트가 0개인 성공적인 명령은 증거가 아닙니다. 제거 또는 이동 후 명명된 남아 있는 테스트 범위와 별개의 영향을 받는 통합 검사를 실행하십시오.
- Rust 편집의 경우
cargo fmt --check및git diff --check를 실행하십시오. 검증 매트릭스에 따라 크레이트 검사, 스크립트 테스트, 로케일 감사 또는 수동 워크플로우를 추가하십시오. 관련 변경 또는 새로운 증거가 무효화될 때까지 결과를 재사용하십시오. - 최종 diff 및 상태를 검토하십시오. 고유한 동작이 사라지지 않았는지, 제품 실패를 숨기기 위해 단언이 약화되지 않았는지, 관련 없는 작업이 변경되지 않았는지 확인하십시오.
단언에 대한 구체적인 의문을 해결하는 데 필요한 경우에만 의도적인 변형을 사용하십시오. 사용자 작업과 격리하고 나중에 정확한 소스를 복원하십시오. 모든 테스트에 필요하지 않습니다. 하위 시스템 전체 감사는 최종 영향을 받는 제품군을 실행하기 전에 제거된 케이스를 명명된 남아 있는 테스트와 조정해야 합니다.
결정, 여전히 보호되는 동작, 실제로 실행된 검사 및 중요한 검증되지 않은 경계를 보고하십시오. 삭제가 발생한 경우 제거된 테스트 범위를 설명하십시오. 요청된 범위가 완료되면 중지하십시오. 개수 또는 감소 목표를 충족시키기 위해 감사를 확장하지 마십시오.
출처
OpenClaw의 test-audit 및 campaign guidance에 있는 테스트 가치 및 증거 원칙에서 가져왔습니다. 실행, 소유권 및 검증은 여기에서 OxideTerm의 저장소 규칙을 따릅니다.