JSON 검사기에 예외를 하나 추가하면 당장 막힌 파일은 열립니다. 문제는 그 다음입니다. 어제 정상적으로 거부되던 값까지 통과하는지 알 수 없습니다. 회귀 검사는 예전에 맞게 동작하던 규칙이 수정 후에도 같은 판정을 내는지 확인하는 절차입니다.
이 실험의 계약을 먼저 고정했습니다.
필드는 id, title, owner, due, status 다섯 개입니다. ID와 제목은 빈 문자열이면 안 됩니다. 담당자는 문자열이거나 실제 null이어야 합니다. 날짜는 YYYY-MM-DD 모양뿐 아니라 달력에 존재해야 하고, 상태는 pending, in_progress, done만 받습니다. 신규 필드도 일단 거부합니다.
단순히 “통과 가능”만 넣지 않았습니다.
| 유형 | 예제 | 기대 |
|---|---|---|
| 정상 | 최소 필드·done·윤년 2월 29일 | 통과 3건 |
| 자료형 | 숫자 ID·문자열 “null”·배열 | 거부 |
| 형식과 의미 | 2026-02-29·09/24 | 거부 |
| 계약 | 누락 제목·추가 priority·빈 ID·complete | 거부 |
자동 검사는 예외 예제가 충분히 다양할 때만 유용합니다. 정상 값만 열 개 넣으면 정상 값을 받는다는 사실밖에 알 수 없습니다.
12건 전체가 예상한 판정과 일치했습니다.
실행 결과의 fixtures는 12, passedExpectations도 12였습니다. 이 숫자는 제공한 함수가 정한 예제에서 예상대로 동작했다는 뜻입니다. 실제 업무의 필드 이름·허용 상태·시간대가 다르다면 이 계약을 그대로 쓰면 안 됩니다.
규칙을 바꿀 때는 선택 기록을 남깁니다.
- 바꾸려는 규칙과 예상되는 호환성 변화를 한 줄로 적습니다.
- 실패해야 하는 예제를 먼저 추가합니다.
- 전체 예제를 실행하고 달라진 판정을 검토합니다.
- 실제 원자료 대조와 권한·보안 검토는 별도 단계로 남깁니다.
이 글의 재현 자료
전체 자료의 범위·실행 방법·주의사항은 재현 자료 안내에서 한번에 확인할 수 있습니다.
원문과 함께 읽기
한 건이 통과해도 배열 전체는 실패할 수 있습니다.
개별 레코드 검사는 ID가 문자열인지를 볼 수는 있지만, 배열 안에 같은 ID가 두 번 들어왔는지는 별도로 보아야 합니다. 같은 ID의 내용이 다르면 뒷행으로 덮어쓰지 말고 충돌로 분리합니다. 행 수와 ID 집합을 원본과 비교하면 누락·중복·새로운 ID를 같이 찾을 수 있습니다.
다만 중복이라고 바로 삭제하지 않습니다. 업무에 따라 같은 ID의 변경 이력을 여러 행으로 남길 수 있기 때문입니다. 스키마는 레코드 형태를, 업무 규칙은 레코드 사이의 관계를 정합니다.
엄격한 검사와 유연한 검사는 배치 위치가 다릅니다.
| 위치 | 선택 | 이유 |
|---|---|---|
| 외부 입력 경계 | 엄격한 규칙 | 모르는 필드·형식을 조기에 보류 |
| 버전 변환 계층 | 명시적 변환 | 예전 필드를 새 형태로 옮기고 기록 |
| 내부 조회 화면 | 필요한 읽기 호환성 | 기록은 보존하되 새 저장은 현재 계약만 사용 |
추가 필드를 모두 무시하면 오타도 조용히 사라집니다. 반대로 모든 예전 파일을 거부하면 이관이 불가능합니다. 호환성은 검사기의 예외로 숨기지 말고, 버전별 변환 함수와 회귀 예제로 다루는 편이 안전합니다.
회귀 결과는 릴리스 기록으로 남깁니다.
- 규칙 버전과 코드 커밋을 기록합니다.
- 예제 개수, 통과 개수, 예상과 다른 판정을 저장합니다.
- 실패 예제의 원본을 민감정보 없는 최소 재현으로 줄입니다.
- 달라진 판정이 의도한 변경인지 작성자와 발행 책임자가 구분해 확인합니다.
실행한 예제 12건이 모두 예상과 일치한다고 사실성 검수까지 끝난 것은 아닙니다. 스키마는 형식 계약을 확인하고, 원자료 대조는 그 값이 현실과 같은지를 확인합니다.
