맹검 테스트 스위트
이 스위트는 계약으로부터 도출된 독립적인 증거이며, 적합성의 정의가 아닙니다. 따라서 테스트 실패는 구현이나 테스트가 잘못되었음을 의미할 뿐, 계약이 잘못된 것은 아닙니다.
test-writer는 각 테스트의 형태를 결정하고, test-oracle-reviewer는 독립적인 값으로 간주할 대상을 결정합니다. 이 스킬은 이들을 둘러싼 격리 환경입니다.
작성자가 보는 것
계약 파일, 계약이 작성된 인터페이스(계약 크레이트 또는 모듈, 해당 타입 및 문서), 그리고 공개된 소스(명세, 벤더드 벡터, 캡처)입니다. 구현, 이전 구현, 또는 계약을 산출한 풀 리퀘스트는 볼 수 없습니다. 이들은 계약에 대한 특정 해석을 담고 있어, 스위트가 테스트가 아닌 확증 역할을 하게 만들기 때문입니다. 구현이 존재하는 경우, 작성자는 해당 구현이 없는 커밋의 작업 트리에서 새로운 컨텍스트를 갖습니다. 읽지 말아야 할 목록이 이를 보완하지만 대체하지는 않습니다. 이미 구현을 본 컨텍스트는 이를 잊을 수 없기 때문입니다.
예상 값
테스트에서 인용된 공개된 소스, 계약이 명시하는 속성, 또는 계약이나 인용된 표준이 방법을 고정한 유도(derivation)로부터 얻은 값입니다. 벡터 옆에 기록되어 검토자가 다시 계산할 수 있어야 합니다. 계약의 구현만이 수행할 수 있는 계산에서 얻은 값은 절대 사용하지 않습니다. 그러한 값을 확인하는 것은 계약을 다시 구현하는 것을 의미하기 때문입니다. 유도된 벡터는 변경 사항이 영향을 미치는 모든 결합된 필드(길이, 체크섬, 서명)를 고려해야 합니다. 그렇지 않으면 결과가 유도가 주장하는 바와 일치하지 않습니다. 공개된 답이 없는 경우, 여러 구현 간의 출력을 비교합니다. 차등 검사(differential check)는 단독으로 사용되지 않습니다. 두 구현에 공유된 버그가 있으면 통과하기 때문입니다. 수동으로 작성된 음성 입력(negative input)은 대상이 되는 차원에서만 독립적으로 유효한 컨트롤과 다릅니다. 따라서 테스트는 명명된 이유로만 실패할 수 있습니다. 특정 입력을 거부하는 규칙은 해당하는 입력을 하나 받습니다. 수락만으로 테스트되는 그러한 규칙은 모든 것을 수락함으로써 충족되기 때문입니다. 벤더드 소스는 출처, 버전, 체크섬이 기록되며, 전체를 가져오거나 자체 섹션 경계에서 잘라냅니다. 절대 편집하지 않습니다. 편집되거나 잘라낸 벡터는 오라클로 만드는 출처를 잃기 때문입니다. 스위트 옆에 커버리지 기록을 유지합니다: 각 절을 확인하는 테스트, 검토로만 확인된 절, 의도적으로 확인하지 않은 경계를 기록하여, 침묵이 커버리지로 오해되지 않도록 합니다.
검토 및 병합
검토자는 test-reviewer를 실행하고 계약을 커버리지 기록과 양방향으로 확인합니다. 모든 절에는 테스트 또는 기록된 공백이 있으며, 모든 테스트는 해당 절을 인용합니다.
구현 전에 스위트를 작성하고, 하나의 구현이 이를 통과하면 병합합니다. 이렇게 하면 적합한 구현이 통과할 수 없는 테스트가 이후의 모든 구현을 구속하기 전에 발견됩니다.
구현 중 읽기 전용
구현 풀 리퀘스트는 스위트나 계약을 절대 편집하지 않습니다. 테스트가 잘못된 것 같거나 절에 테스트가 없는 경우, 벡터 또는 절, 예상 값과 관찰된 값, 인용된 소스와 함께 에스컬레이션합니다. 수정 사항은 스위트를 소유한 풀 리퀘스트(진행 중인 경우 해당 리드, 병합된 후에는 새 풀 리퀘스트)로 이동합니다. 새로운 작성자가 동일한 입력을 가지고, 구현의 출력이 아닌 결정을 받아 스위트가 맹검 상태를 유지합니다.