이번 학습 기록에서는 리스트 복사, 첫 번째 일치 위치 탐색, LEFT JOIN 예제를 검증하며 확인한 점을 정리한다. 공통점은 일반적인 입력 하나만으로 구현을 판단하기 어렵다는 것이다. 조건이 달라지는 지점과 예상이 깨지는 사례를 따로 확인해야 했다.
1. 먼저 기대 결과를 적는다
테스트를 실행하기 전에 문제 조건으로부터 기대값을 정한다. 코드가 출력한 값을 보고 정답으로 받아들이면 검증이 아니라 관찰에 그칠 수 있다.
예를 들어 ‘20 이상인 첫 원소의 인덱스’를 찾는다면 다음 기준을 먼저 적을 수 있다.
| 입력 | 기대값 | 검증 목적 |
|---|---|---|
[20, 5] | 0 | 기준과 일치하는 첫 원소 |
[19, 20, 21] | 1 | 기준 직전·일치·초과 |
[5, 20] | 1 | 앞선 실패 뒤의 성공 |
[5, 10] | -1 | 끝까지 일치 없음 |
[] | -1 | 반복문이 실행되지 않는 경우 |
기대값이 서로 같은 사례도 검사하는 목적은 다를 수 있다. ‘답이 마지막에 있음’과 ‘중간에 있음’은 반환 위치 오류를 찾는 데 각각 의미가 있다.
2. 작은 반례가 드러내는 반환 위치
def wrong_solution(values, target):
for index, value in enumerate(values):
if value >= target:
return index
return -1
print(wrong_solution([5, 20], 20)) # -1: 기대값은 1첫 원소가 조건에 맞는 입력만 사용하면 이 오류를 놓칠 수 있다. [5, 20]은 앞선 실패 뒤에 정답이 있는 최소한의 반례다. 실패를 반환하는 위치가 너무 이르다는 점이 명확해진다.
빈 리스트도 별도로 확인해야 한다. 잘못된 구현에서는 반복문에 진입하지 않고 함수 끝에 도달해 None을 반환한다. ‘일치하지 않는 원소가 있음’과 ‘원소가 아예 없음’은 실행 경로가 다르다.
3. 숫자 경계 외에도 구조의 경계가 있다
리스트 복사에서는 [1, 2]와 [[1], [2]]를 비교했다. 얕은 복사를 한 뒤 내부 리스트에 값을 추가하면 원본도 바뀐다. 원소가 정수인지 변경 가능한 리스트인지에 따라 확인할 범위가 달라진다.
SQL에서는 고객별 주문 수를 0건, 1건, 2건으로 구성했다. 이 데이터로 일치하지 않는 행의 NULL 처리와 일대다 조인의 행 증가를 함께 확인할 수 있었다. ON과 WHERE에 같은 금액 조건을 놓아도 남는 고객이 달라진다는 점도 결과표로 비교했다.
경계값은 최솟값과 최댓값에만 한정되지 않는다. 빈 입력, 중복, 중첩 구조, 일치하는 행이 없는 상태도 검증해야 할 경계에 포함된다.
4. 검증을 반복 가능한 형태로 남긴다
다음은 올바른 탐색 구현과 검증 코드다. 각 코드 블록은 독립적으로 실행할 수 있다.
def solution(values, target):
for index, value in enumerate(values):
if value >= target:
return index
return -1
cases = [
([20, 5], 20, 0),
([19, 20, 21], 20, 1),
([5, 20], 20, 1),
([5, 10], 20, -1),
([], 20, -1),
]
for values, target, expected in cases:
actual = solution(values, target)
assert actual == expected, (values, target, expected, actual)
print("5 cases passed")실행 결과는 5 cases passed였다. 다만 유한한 테스트를 통과했다는 사실만으로 모든 입력에서 정답임이 증명되는 것은 아니다. 앞에서부터 탐색하므로 첫 성공이 가장 작은 인덱스라는 논리도 함께 확인해야 한다.
5. 다음 구현에서 확인할 항목
- 조건의 등호 포함 여부와 기준값 바로 전후
- 첫 위치, 마지막 위치, 일치 없음, 빈 입력
- 반환 대상이 값인지 위치인지, 실패 표식은 무엇인지
- 변경 가능한 내부 객체를 공유하는지
- SQL 조건이 일치 대상을 제한하는지 결과 행을 제거하는지
이번 검증에서는 성공하는 예제를 늘리는 것보다 구현이 틀릴 수 있는 이유를 하나씩 정하고 반례를 만드는 방식이 유용했다. 다음 문제에서도 정상 입력을 확인한 뒤, 종료 조건과 데이터 구조가 달라지는 경우를 따로 점검하려 한다.
참고 문서
