Scarab Diagnostic Suite 현장 테스트 #009: Moby 테스트 하네스(Test Harness) 가시성 경계

이번 현장 테스트는 Moby를 대상으로 진행되었습니다.

문제는 containerd 스냅샷터(snapshotter)가 활성화된 상태에서 발생하는 docker-py 실패에 관한 오래된 오픈 스레드였습니다:

https://github.com/moby/moby/issues/46742

원래의 이슈에는 다이제스트(digest) 불일치, 이미지 저장/로드(save/load) 차이, 풀(pull) 실패, 캐시(cache) 동작, 그리고 스냅샷터(snapshotter)와 그래프 드라이버(graphdriver) 간의 차이점을 포함하여 여러 개의 실패하는 docker-py 통합 테스트가 나열되어 있었습니다.

언뜻 보기에 이것은 엔진/스냅샷터(engine/snapshotter) 동작 문제일 가능성이 있어 보였습니다.

하지만 현재 리포지토리(repo) 상태는 더 신중한 이야기를 들려주었습니다.

Scarab Diagnostic Suite는 이번 패스(pass)를 통해 현재 엔진 레벨의 스냅샷터(snapshotter) 수리가 완료되었음을 확인하지 못했습니다.

대신, 더 좁지만 여전히 유용한 경계를 드러냈습니다:

test coverage truth exists in source comments, but is not clearly emitted in test output
(테스트 커버리지의 진실은 소스 코드 주석에는 존재하지만, 테스트 출력 결과에는 명확하게 나타나지 않음)

쉬운 말로 설명하자면:

현재의 docker-py 하네스(harness)에는 이미 영향을 받는 일부 테스트 영역에 대해 내장된 제외(deselection) 로직이 있습니다.

해당 제외 로직에는 특정 테스트가 왜 건너뛰어지거나 제외되는지를 설명하는 소스 코드 주석이 포함되어 있습니다.

하지만 그 이유가 pytest가 실행되기 전의 테스트 실행 출력 결과에 명확하게 인쇄되지 않습니다.

즉, CI 또는 로컬 로그를 읽는 사람은 어떤 docker-py 커버리지가 의도적으로 실행되지 않았는지, 혹은 그 이유가 무엇인지 즉시 알 수 없다는 것을 의미합니다.

따라서 이것은 “스냅샷터(snapshotter)를 수정하는” 결과가 아니었습니다.

이것은 테스트 하네스(test-harness)의 가시성(visibility)에 관한 결과였습니다.

로컬 패치 후보(patch candidate)는 현재의 제외(deselection) 동작을 유지하되, pytest 옵션을 빌드하기 전에 선택기(selector)와 이유를 출력하는 헬퍼(helper)를 통해 제외 로직을 중앙 집중화합니다.

이렇게 하면 엔진 동작을 변경하지 않고도 테스트 실행을 더 정직하게 만들고 해석하기 쉽게 만들 수 있습니다.

저는 유지 관리자(maintainer)를 향해, 이러한 방향의 PR(Pull Request)이 유용할지, 아니면 남은 제외(deselection) 항목들을 제거하거나 수정하는 데에만 이슈를 집중하기를 원하는지 묻는 의견을 남겼습니다.

현장 테스트 #009

프로젝트: Moby

이슈 유형: docker-py/containerd 스냅샷터(snapshotter) 테스트 실패

경계: 테스트 하네스(test harness) 제외(deselection) 진위 여부 vs CI/로그 가시성

결과: 더 좁혀진 진단 결과 및 로컬 가시성 패치 후보

상태: PR(Pull Request) 전 유지 관리자(maintainer)의 방향성 요청

이 현장 테스트의 중요한 부분은 절제입니다.

Scarab은 기존 이슈의 형태를 현재 리포지토리(repo)에 강제로 적용하지 않았습니다.

Scarab은 현재 상태를 점검하여, 원래의 실패 표면(failure surface) 중 일부가 이미 의도적인 제외(deselection) 동작으로 흡수되었음을 확인하였고, 남아 있는 진위 격차(truth gap)를 식별했습니다. 즉, 하네스는 왜 커버리지(coverage)가 건너뛰어지는지 알고 있지만, 테스트 출력 결과는 그 이유를 충분히 가시적으로 보여주지 못하고 있다는 점입니다.

이것은 여전히 소프트웨어 진위 드리프트(software truth drift)입니다.

모든 진단적 승리가 거대한 수리인 것은 아닙니다.

때로는 현재 시스템에서 무엇이 실제로 여전히 진실인지 명확히 하는 것이 올바른 기여가 될 수 있습니다.