검사를 돌려서 0건이 나오면 통과인지를 물어야 한다. 검사가 대상을 하나도 못 봤을 때도 0건이 나오기 때문이다.
Table of contents
Open Table of contents
사례 — 오류 없이 0건이 나온 경우들
rsync -n 에 -v 를 안 붙여서 아무것도 안 나온 적이 있고 그것을 차이 없음으로 읽었다. find 에 -L 이 없어 심볼릭 링크를 안 따라가서 그 아래 것들이 전부 빠진 적도 있다.
눈으로 같은 한글인데 NFC 와 NFD 정규화 형태가 달라 비교가 전부 거짓이 되면서 1천여 건이 0건으로 나온 적도 있다. 권한이 없어 조회가 거부됐는데 2>/dev/null 로 오류 출력을 버려서 빈 결과만 남은 경우와 orders 테이블 이름으로 찾았지만 코드는 Order 모델 이름을 쓰던 경우도 있었다. 전부 오류 없이 0건이었으므로 통과로 읽혔다.
검증 — 대조군을 만드는 확인
지금은 검사 결과가 나오면 반대 입력으로 한 번 더 돌린다. 통과가 나왔으면 실패해야 하는 입력을 넣고 실패가 나왔으면 성공해야 하는 입력을 넣는다.
둘 다 같은 결과가 나오면 그 검사는 아무것도 가르지 못한 것이다. 금지 표현을 찾는 grep -c 검사에서 0건이 나왔을 때 정상 파일에 그 표현을 일부러 붙여 다시 돌려 검출되는 것을 보고 나서야 앞의 0건을 믿었다. 번거로워 보이지만 몇 초면 되고 그 몇 초가 확인했다와 확인한 줄 알았다를 가른다.
해결 — 함께 출력하는 개수
두 가지 방법이 있었는데 검사 스크립트는 그대로 두고 사람이 매번 대조군을 돌리는 것과 스크립트가 검사 N건 · 위반 M건 을 나란히 찍게 고치는 것이다. 뒤쪽을 골랐다. 이유는 대조군은 사람이 잊지만 출력은 잊지 않아서다. 대신 검사 스크립트 전부의 출력 형식을 한 번 손봐야 하는 것을 감수했다. 검사한 수와 위반 수를 나란히 두면 0건이 무슨 뜻인지 바로 알 수 있고 앞의 숫자가 0이면 아무것도 안 본 것이다.
이 규칙을 만든 지 몇 분 만에 그 규칙이 자기 첫 실패를 잡았다. 검사를 상대 경로로 돌렸더니 파일 수가 빈칸으로 찍혀서 바로 드러났다.
주의 — 축이 맞는지 보는 확인
더 어려운 경우는 검사가 도는데 다른 것을 재고 있는 경우다. 배포한 settings.json 들이 서로 같은지 md5 로 확인해서 해시가 일치했고 통과로 봤다.
그런데 그 파일은 머신마다 달라야 하는 종류였고 확인해야 할 것은 같은지가 아니라 다른지였다. 검사는 정상 동작했고 축이 반대였으므로 대조군으로도 안 잡히며 검사가 무엇을 확인해야 하는지를 먼저 정해야 한다.
행위와 결과의 구분
명령이 성공했다는 것과 의도한 상태가 됐다는 것은 다르다. 링크를 만들었다는 것과 그 대상이 실제로 있다는 것은 별개이고 파일을 보냈다는 것과 양쪽 내용이 같다는 것도 별개다.
그래서 지정한 방식과 다른 방식으로 되읽는다. 만든 개수를 세는 대신 다시 조회한 개수를 세고 링크는 생성 수가 아니라 test -e 로 해소되는지를 확인한다.
정리
- 0건은 통과가 아니라 아무것도 측정하지 않은 것일 수 있다
-v누락과-L누락과NFC차이가 전부 오류 없이 0건이 된다- 권한 거부와 잘못된 검색어도 같은 모양으로 나온다
- 통과가 나오면 실패해야 하는 입력으로 한 번 더 돌린다
- 같은 결과가 나오면 아무것도 안 가린 것이다
- 검사 결과와 본 개수를 함께 출력한다
- 검사가 도는데 축이 반대일 수 있다
- 행위의 성공을 결과의 성공으로 삼지 않고 다른 방식으로 되읽는다