수정한 결함의 확인과 기존 동작의 부작용 검사는 목적이 다르다. 둘 다 실제 결과를 판단할 독립적인 근거가 필요하다.
테스트 오라클은 관찰한 결과의 옳고 그름을 판단하는 근거다. 앞의 정수 1~21일 규칙을 구현하기 전에 표로 적어 두면 그 표가 비교 기준이 된다. 구현 결과를 그대로 복사해 예상값으로 삼거나 오래된 정책 표를 검토 없이 유지하면 테스트가 통과해도 판단 근거부터 틀릴 수 있다.
가상 오류는 상한을 '< 21'로 작성해 21일을 거부한 것이다. '<= 21'로 고친 뒤 21일을 허용하는지 확인하는 검사는 해당 결함의 수정 확인이다. 이어 0은 거부하고 1은 허용하는지, 22와 문자열은 여전히 거부하는지 보면 기존 동작에 대한 회귀 검사 목적이 된다. 같은 입력이 두 목적에 기여할 수도 있으므로 파일명이나 반복 횟수만 보고 분류하지 않는다.
실제 서비스라면 입력 검사를 공유하는 예약 화면·API·기간 연장 절차와 저장·복원 경로도 영향 분석에서 살핀다. 아래 작은 예제는 순수 함수의 결과만 확인한다. 날짜 계산·시간대·권한·실제 DB와 여러 화면의 회귀까지 검증했다는 뜻은 아니다. 변경된 계약이 있다면 코드와 예상표를 어느 근거로 함께 바꿨는지도 기록한다.
- 01 →
현재 규칙을 확인한다
- 02 →
결함을 다시 재현한다
- 03 →
수정 결과를 비교한다
- 04
영향 범위의 기존 동작을 확인한다
같은 상황에서 비교하기
| 개념 | 기준 | 확인할 점 |
|---|---|---|
| 테스트 오라클 | 결과를 판단할 근거 | 현재 합의한 정책인지 확인한다 |
| 수정 확인 | 원래 결함이 고쳐졌는가 | 21일을 다시 실행해 예상과 비교한다 |
| 회귀 검사 | 변경 때문에 기존 동작이 깨졌는가 | 영향받는 정상·무효 입력과 연결 흐름을 고른다 |
도서관 예제로 따라가기
// 결함이 있던 조건
const before = days => Number.isInteger(days) && days >= 1 && days < 21;
// 수정한 조건: 합의한 상한을 포함한다
const after = days => Number.isInteger(days) && days >= 1 && days <= 21;| 입력 | 수정 전 | 수정 후 | 규칙에서 정한 예상 |
|---|---|---|---|
| 21 | 거부 | 허용 | 허용 |
| 0 | 거부 | 거부 | 거부 |
| 1 | 허용 | 허용 | 허용 |
| 22 | 거부 | 거부 | 거부 |
| '21' · 문자열 | 거부 | 거부 | 거부 |
예상값은 정수 1~21이라는 합의에서 먼저 정했다. before(21)의 false를 그대로 정답으로 복사하면 결함을 감추게 된다. 이 표는 수정 전후를 비교하는 새 창작 사례이며 기존 문제의 해설이 아니다.
내 말로 설명해 보기
21일 오류를 고친 뒤 0·1·22와 문자열을 다시 보는 이유는 무엇인가? 예상표의 근거도 설명해 보자.
설명 예시 확인
21은 원래 결함의 수정 확인이고 다른 입력은 기존 허용·거부 동작의 부작용을 살피는 회귀 범위다. 예상표는 구현 출력이 아니라 현재 합의한 정수 1~21일 규칙에서 정한다. 더 큰 서비스의 연결 영향은 별도로 분석해야 한다.
참고한 자료
이전 개념 자료와의 연결
이전 자료에서 다룬 주제를 이어받아 설명과 예시를 다시 썼어요.
- 회귀 테스트
- 예상 결과와 테스트 오라클