플랫폼별 부트스트랩 회귀 하나가 JSON 도구인 jq가 호스트에 없다는 이유로 먼저 실패했다. 시험하려던 것은 매니페스트 처리였는데, 판정은 개발 머신의 패키지 상태가 가져갔다.
해결책은 테스트 전용 PATH 앞에 필요한 동작만 흉내 내는 jq 스텁을 두는 것이었다. 이미 확보한 Python 인터프리터로 정해진 JSON 응답을 만들면, 호스트에 jq가 있든 없든 같은 입력과 출력을 재현할 수 있다. 이 회귀가 확인하려는 것은 특정 필드를 읽어 다음 단계로 넘기는 동작이지, 배포판마다 실행 파일이 어디에 설치됐는지가 아니다.
이런 격리는 테스트를 빠르고 설명 가능하게 만든다. 네트워크, 로케일, 셸 유틸리티, 사용자 설정처럼 시험 대상 밖의 조건을 줄이면 실패 원인이 짧아진다. “내 컴퓨터에서는 된다”의 반대편에서 “내 컴퓨터에 그 도구가 없어서 실패했다”도 함께 치울 수 있다.
문제는 스텁이 실제 jq를 증명하지 않는다는 데 있다. 옵션 조합, 종료 코드, 표준 오류, 공백과 인코딩, 필드가 없을 때의 동작 중 하나만 달라도 테스트는 초록색인데 실제 호스트에서는 깨질 수 있다. 필요한 동작만 구현한 스텁은 그 덕분에 안정적이지만, 잘못 옮겨 적은 계약을 스스로 정답이라고 확인하는 순환 검증에도 빠지기 쉽다.
그래서 두 시험은 역할을 나눠야 한다. 매 커밋에서는 좁고 동작이 충실한 스텁으로 결정론적 회귀를 돌린다. 별도의 통합 시험에서는 지원하는 실제 jq와 실제 셸을 사용해 옵션, 출력, 오류 동작의 호환성을 확인한다. 앞의 실패는 코드 회귀를 가리키고, 뒤의 실패는 환경 통합 문제를 가리키도록 판정도 분리한다.
재현성을 얻으려고 현실을 통째로 지우면 테스트가 아니라 모형 관리가 된다. 시험에서 세상을 줄인 만큼, 줄여 낸 부분을 실제 환경에서 다시 만나는 자리가 필요하다.