테스트 도구 실전 · 지연 평가를 관측하는 내보내기 테스트 · 이론

지연 평가를 관측하는 내보내기 테스트의 설계 원리

한 줄 요약

행 소비 횟수·개행 이스케이프·공개 필드·응답 형식을 검증합니다.

개념 지도: 한 줄 요약 · 왜 이게 필요했나 · 어떻게 동작하나 · 계약을 읽고 실패를 예측하는 워크시트

왜 이게 필요했나

작은 리스트로 테스트한 내보내기 코드는 정상처럼 보였지만 큰 입력을 모두 list로 바꾸며 메모리를 소진했다. 결과가 같은 것만으로 실행 방식의 계약까지 같다고 할 수 없다. 지연 소비를 눈으로 보이는 상태로 바꿔야 한다.

어떻게 동작하나

입력 생성기가 소비될 때마다 리스트에 흔적을 남긴다. 생성 직후 0회, 첫 next 이후 1회, 상한 이후 더 이상 소비하지 않는지를 확인한다. 한글과 개행을 포함한 JSON Lines를 다시 파싱하고 HTTP 응답의 Content-Type과 내부 필드 제거도 검사한다.

학생 테스트 → 정상 구현: 실제 시험 모두 통과           └→ 계약 위반 구현: 해당 동작에서 실패수집 실패·0개 실행·강제 종료 ≠ 결함 검출

계약을 읽고 실패를 예측하는 워크시트

다음은 구현을 통째로 외우는 답안이 아니라 단계별 코드 리뷰입니다. 각 변경 조각은 의도적으로 계약을 깨뜨립니다. 변경 후에도 정상 사례가 통과할 수 있다는 점에 주의하세요. 실행 전에 어느 입력·예외·상태를 관측하면 차이가 드러날지 예상하고, 구현 후에는 그 예상과 결과를 비교합니다.

1. 행 계약을 검증한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: validate_row(row)는 dict이며 id가 bool 제외 양의 int, name이 비어 있지 않은 str일 때 row를 반환합니다. 나머지는 ValueError입니다. 추가 내부 필드는 허용합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: bool과 숫자를 구분하고 빈 이름을 오류로 처리합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

not isinstance(row.get("id"), int)

이 조각이 들어간 함수의 공개 계약과 비교해 보세요. 성공 사례 하나로는 구분되지 않는다면 거절되어야 할 입력이나 실패 이후의 상태를 관측 대상으로 선택합니다.

2. 공개 행만 만든다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: project(row)는 validate_row 후 id와 name만 가진 새 dict를 반환합니다. 원본 내부 필드는 그대로 보존합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 내보내기 경로도 일반 API와 같은 공개 필드 정책을 적용해야 합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

"name":row["name"], "internal_cost":row.get("internal_cost")}

3. 줄 경계를 보존하며 인코딩한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: encode_line(row)는 project 결과를 ensure_ascii=False, separators=(',',':'), sort_keys=True로 JSON 인코딩하고 마지막에 '
' 한 개를 붙인 str입니다. name 안 개행은 JSON 이스케이프여야 합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 문자열 덧붙이기로 JSON을 만들면 따옴표와 개행에서 형식이 깨집니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

ensure_ascii=True

4. 출력 개수 상한을 검증한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: validate_max(value)는 bool 제외 int 1~1000만 그대로 반환하고 그 외 ValueError입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 무한 입력을 실수로 끝까지 읽지 않도록 호출자에게 상한을 요구합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

<= 1001

5. 필요한 행만 소비한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: take_rows(rows, maximum)는 islice 등으로 최대 maximum개만 지연 반환하는 iterator입니다. 호출 시 maximum을 검증하며 한 번 next하면 입력을 한 번만 소비합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: list(rows)로 바꾸는 순간 무한 입력과 대용량 입력을 처리할 수 없습니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

islice(list(rows), validate_max(maximum))

6. 행을 지연 직렬화한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: json_lines(rows, maximum=100)는 take_rows에서 받은 행마다 encode_line을 yield합니다. 전부 합친 문자열이나 리스트를 반환하지 않습니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 객체 선택과 표현 변환을 각각 지연 단계로 유지합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

for row in list(take_rows(rows, maximum)):

7. 내려받은 줄을 다시 검증한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: decode_lines(text)는 splitlines의 각 비어 있지 않은 줄을 json.loads 후 validate_row하고 리스트로 반환합니다. 빈 문자열은 [], 비어 있는 중간 줄은 ValueError입니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: 빈 파일과 형식이 깨진 빈 레코드를 구분합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

continue

8. HTTP 다운로드를 완성한다 — 테스트

제공된 service.py의 다음 공개 계약을 테스트하세요: create_app(rows)는 GET /export에서 json_lines(rows, 100)을 application/x-ndjson StreamingResponse로 반환합니다. rows는 다시 순회 가능한 리스트입니다. 내부 필드가 없고 각 행의 내용과 순서를 보존해야 합니다. 정상 구현에서는 통과하고 이 계약을 어긴 구현에서는 실제 테스트 본문의 실패로 검출해야 합니다. 앞 단계 테스트를 유지하며 test_ 함수를 추가하세요.

판단의 근거: Content-Type만 스트리밍으로 적고 내부에서는 전체를 모으지 않았는지 생성기 시험과 함께 확인합니다. 구현 파일은 수정하지 않습니다. pytest.raises로 예상 예외를 확인하고 정상 결과에는 구체적인 예상값을 단언하세요.

리뷰할 잘못된 변경 조각:

media_type="application/json"

현장에서 만나는 모습

TestClient는 응답을 버퍼링하므로 네트워크 첫 바이트 지연이나 메모리 상한 전체를 증명하지 않는다. 지연 평가 여부는 별도의 계수 생성기로 검사한다. 스트림 시작 이후 잘못된 행을 만나면 정상 오류 JSON으로 상태를 바꾸기 어렵다. 실서비스는 사전 검증·행별 오류 형식·중단 정책 중 무엇을 택할지 정해야 한다. 제공 구현은 읽어도 되지만 채점은 별도 사본을 사용한다. 소스 문구 검사나 파일 수정으로 결함을 우회하지 말고 공개 인터페이스의 실행 결과를 검사한다.

다음 실습에서 할 것

여덟 단계가 하나의 실행 가능한 결과물로 이어집니다. 행 계약을 검증한다 — 테스트 → 공개 행만 만든다 — 테스트 → 줄 경계를 보존하며 인코딩한다 — 테스트 → 출력 개수 상한을 검증한다 — 테스트 → 필요한 행만 소비한다 — 테스트 → 행을 지연 직렬화한다 — 테스트 → 내려받은 줄을 다시 검증한다 — 테스트 → HTTP 다운로드를 완성한다 — 테스트.

각 단계는 함수나 파일이 존재한다는 사실이 아니라 실제 반환값·예외·상태 변화를 검사합니다. 정답을 본 뒤에는 일부러 경계 비교나 정리 코드를 바꾸어 어떤 시험이 실패하는지 확인하세요. 앞선 시험이 다음 단계에서도 유지되는 이유를 설명하고, 이 실습이 보장하지 않는 운영 조건을 한 가지 적어 보세요.