测验：策略也需要测试

통과 표본만 모아 둔 정책 시험이 위험한 이유는?

• 표본이 많아질수록 CI 실행 시간이 길어져 결국 아무도 시험을 돌리지 않게 되기 때문
• 통과 표본은 정책 문법이 바뀌면 자동으로 깨져서 잦은 거짓 실패를 만들기 때문
• 엔진이 통과 표본만 있는 스위트를 유효하지 않은 것으로 보고 실행을 건너뛰기 때문
• 정책을 통째로 지워도 시험이 초록불이라, 규칙이 느슨해진 날을 잡아 주지 못하기 때문

시험은 초록불인데 클러스터에서는 안 막힌다. 가장 먼저 의심할 것은?

• 엔진 판이 낮아 새 문법을 못 읽고 정책을 빈 규칙으로 해석했을 가능성
• 매치 범위가 어긋나 표본이 전부 skip 인데 시험이 skip 을 실패로 세지 않았을 가능성
• 기대 메시지 문자열에 공백이 섞여 비교가 항상 참이 되었을 가능성
• 표본 파일이 시험 디렉터리 밖에 있어 엔진이 읽지 못했을 가능성

서버 dry-run(?dryRun=All)으로 보낸 요청에 대한 설명으로 옳은 것은?

• 저장 단계만 빼고 정상 경로를 지나므로 어드미션이 실제로 실행되고 검증은 변형 뒤 오브젝트를 본다
• 요청 본문의 문법과 스키마만 검사하고 어드미션 단계는 건너뛴다
• 오브젝트를 실제로 저장한 뒤 응답을 돌려주고 곧바로 삭제해 되돌린다
• 클라이언트에서만 처리되어 API 서버로는 아무 요청도 가지 않는다

정책 시험에서 기대 메시지까지 고정해 두는 이유는?

• 메시지를 고정하지 않으면 엔진이 거부 사유를 아예 생성하지 않아 판정이 비어 버리기 때문
• 메시지 길이가 규칙 평가 순서를 결정해서 짧은 메시지가 먼저 적용되기 때문
• 메시지도 계약이라, 문구가 바뀌면 그것을 붙잡아 자동화한 쪽이 조용히 멈추기 때문
• 같은 메시지를 쓰는 규칙끼리 엔진이 자동으로 묶어 중복 평가를 줄여 주기 때문

정책 저장소 CI 에서 가장 자주 빠지면서 가장 조용히 배신하는 검사 두 가지는?

• 정책 파일 스키마 검사와 YAML 들여쓰기 린트
• 엔진 판 고정과 표본 파일 이름 규칙 검사
• 표본 개수 상한 검사와 CI 실행 시간 상한 검사
• skip 이 0 인지 확인하는 것과 거부 기대 건수가 0 이 아닌지 확인하는 것

골든 케이스 표본을 만들 때 권장되는 방식은?

• 통과 표본을 복사해 위반 필드 하나만 바꾼 쌍으로 두어, 깨졌을 때 무엇이 달랐는지 바로 읽히게 한다
• 표본 하나에 여러 위반을 몰아넣어 파일 수를 줄이고 실행 시간을 아낀다
• 실제 운영 매니페스트를 그대로 복사해 민감한 값까지 포함한 채로 저장소에 둔다
• 매 실행마다 무작위로 필드를 바꾼 표본을 생성해 넓은 입력 공간을 훑는다