테스트 감사
이 스킬에는 두 가지 모드가 있습니다:
- 작성 모드. 아래의 작성 게이트는 사용자가 추가하거나 변경하는 모든 테스트에 적용됩니다.
- 감사 모드. 생산 소유자별로 일관된 배치 단위로 가치가 낮은 증명을 제거하십시오. 삭제 횟수를 쫓지 마십시오. 목표는 각 계약이 하나의 강력한 소유자를 갖는 스위트를 만드는 것이지, 단순히 숫자를 줄이는 것이 아닙니다.
한 번에 전체 하위 시스템의 테스트 표면을 정리하는 캠페인의 경우 먼저 CAMPAIGN.md를 읽으십시오.
작성 게이트
테스트를 추가하기 전에 다음 네 가지 질문에 답하십시오:
- 이 테스트가 보호하는 관찰 가능한 동작, 불변 조건, 또는 독립적인 계약은 무엇입니까?
- 어떤 신뢰할 수 있는 회귀(regression)가 이 테스트를 실패하게 만듭니까?
- 기존 증명이 이를 왜 놓쳤습니까? 각 계약은 가장 강력한 경계에서 하나의 주요 소유자를 가져야 합니다. 다른 계층의 테스트는 이를 정당화할 고유한 전송 또는 수명 주기 위험이 있어야 합니다. 거의 동일한 복사본을 추가하는 대신 기존 테이블과 공유 픽스처를 확장하고, 반복되는 설정을 통합하십시오.
- 생산 호출자가 없는 내보내기, 플래그, 래퍼, 또는 주입 훅이 필요합니까? 그렇다면 대신 실제 경계로 증명을 이동하십시오.
지원 규칙:
- 경계 및 비용 가이드를 사용하여 테스트가 어디에 위치해야 하고 어떤 비용이 들 수 있는지 결정하십시오.
- 회귀 테스트는 수정 전에 의도된 이유로 실패해야 하고 수정 후에는 통과해야 합니다. 수정 전 실패를 보여줄 수 없으면 보고서에 그렇게 명시하십시오.
- 소유 경계에서의 하나의 회귀 테스트가 버그를 포괄합니다. 버그가 통과한 모든 계층에서 이를 재현하지 마십시오.
- 동작을 보존하는 리팩터링은 테스트를 깨뜨리지 않아야 합니다.
정크 패턴
- 자체 비교, 복사된 인벤토리, 소스 grep, 구현 또는 호출 형태 단언, 중복 계약, 테스트 전용 시임(seam), 테스트 대상이 생성한 예상 값, 그리고 단언되는 동작을 제공하는 목(mock)을 거부하십시오.
- 픽스처는 소유자가 생성해야 할 영수증이나 순서를 위조해서는 안 되며, 코드가 절대 쓰지 않는 경로를 통해 지속성을 주장해서는 안 됩니다.
- 음성 제어(negative control)는 의도된 가드에서 실패해야 하며, 테스트 이름은 실제로 실행하는 동작과 일치해야 합니다.
- 감사 후보를 검토할 때는 전체 체크리스트를 사용하십시오.
유지 기준
- 공개 API, SDK, 프로토콜, 설정, 마이그레이션, 스토리지, 보안, 플랫폼, 기본값, 프롬프트 바이트, 생성된 다국어 출력, 패키징, 릴리스, 아키텍처, 관찰 가능한 순서 등 독립적인 계약을 보호하는 테스트는 유지하십시오. 정적이거나 느리다고 해서 테스트를 폐기할 수 있는 것은 아닙니다.
- 소스 검사는 식별자 전용 리팩터링을 견디고 독립적인 사용자 대면 계약을 보호하는 경우에만 허용됩니다.
- 실패하는 기준선 테스트는 삭제할 테스트가 아니라 수리해야 할 제품 버그일 수 있습니다.
감사 및 검증
- 감사 편집 전에 후보 증거 및 워크플로를 읽으십시오. 전체 소유자, 호출자, 히스토리를 검사하고, 삭제 전에 남은 증명을 기록하십시오.
- 쓸모없는 생산 시임(seam)을 테스트와 함께 삭제하십시오. 삭제 횟수에 최적화하지 마십시오.
- 테스트 실행이 진행 중인 동안 체크아웃을 편집하지 마십시오. 소유자 및 형제 테스트에 대한 프로젝트의 집중 테스트 명령을 실행하고, 프로젝트의 변경 파일 검사를 실행한 후, 랜딩 전에 리뷰를 받으십시오.
- 원인, 유지된 계약, 증명과 그 비용, 변경된 생산 코드 대 테스트 코드 라인 수, 후속 조치를 보고하십시오. 태스크가 권한을 부여할 때만 커밋, 푸시 또는 랜딩하십시오.