주문 컨트롤러 공급 유형 테스트의 사전 결함 7건 수정

테스트 코드에서 사전 결함 7건을 정정했다. 정확히는 OrderControllerSupplyTypeTest — 공급 유형별 주문 흐름을 검증하는 컨트롤러 테스트 파일에서 발견된 버그들.

왜 테스트 코드의 "사전 결함"이 심각한가

흔히 테스트 코드는 "동작하는 코드 옆에 있는 보조 파일" 정도로 가볍게 여기는 경우가 있다. 하지만 팀을 이끌면서 늘 강조하는 건, 테스트 코드의 결함은 프로덕션 결함보다 어떤 의미에서 더 위험하다는 것이다.

이유는 단순하다. 결함 있는 테스트는 거짓 안전감을 준다. 빨간불이 켜져야 할 상황에 초록불이 켜지거나, 반대로 멀쩡한 로직인데 계속 실패를 뱉어내면서 팀 전체의 CI 신뢰도를 갉아먹는다. 특히 OrderControllerSupplyTypeTest처럼 공급 유형이라는 비즈니스 분기가 복잡한 영역을 다루는 테스트라면, 결함이 7건씩 쌓여 있다는 건 그 테스트 스위트 전체가 사실상 "있으나 마나" 상태였다는 뜻이다.

"사전 결함"이라는 표현도 중요하다. 단순히 assert가 틀린 게 아니라, 테스트가 실행되기도 전에 — setUp, 픽스처 구성, Mock 세팅, 의존성 주입 등 — 어딘가에서 이미 망가져 있는 상태. 이런 결함은 발견하기도 귀찮고, 고치기도 지저분하다. 그래서 미뤄지는 경우가 많다.

어떤 유형의 결함들이었나

7건이라는 숫자는 단순 오타 수정이 아니라, 꽤 조직적으로 훑어야 나오는 수치다. OrderControllerSupplyTypeTest 하나의 파일에서 이 정도가 나왔다면, 아마 아래 유형들이 복합적으로 섞여 있었을 가능성이 높다.

공급 유형 분기는 보통 한 컨트롤러 안에서 여러 경로를 타기 때문에, 케이스별로 별도의 테스트 메서드를 작성하다 보면 이런 누적 오류가 생기기 쉽다.

수정 작업 자체에서 배운 것

// Before: 공급 유형 코드가 하드코딩된 문자열로 들어가 있었음
mockMvc.perform(post("/order/create")
    .param("supplyType", "01")  // 실제 enum은 SupplyType.DIRECT
    .param("orderId", "TEST_001"))
    .andExpect(status().isOk());

// After: 실제 도메인 모델의 값 사용
mockMvc.perform(post("/order/create")
    .param("supplyType", SupplyType.DIRECT.getCode())
    .param("orderId", "TEST_001"))
    .andExpect(status().isOk());

이런 차이가 사소해 보이지만, 서비스 로직이 바뀌거나 enum 코드값이 리팩토링되는 순간 테스트는 조용히 깨진 채로 방치된다. 상수를 직접 참조하면 컴파일 타임에 잡힌다.

테스트 결함 정정 작업을 혼자 묵묵히 하는 것도 좋지만, 팀 차원에서는 이 작업을 기술 부채 청산 이슈로 등록하고, 왜 7건이나 쌓였는지 원인을 짚는 게 더 중요하다. 리뷰 단계에서 테스트 파일도 동등하게 검토했는지, 테스트 작성 기준이 명문화되어 있는지.

이번 건을 계기로 테스트 파일도 PR 리뷰에서 프로덕션 코드와 동일한 기준으로 들여다보는 걸 팀 컨벤션으로 다시 한번 못 박았다. 결함 7건 정정보다 이게 더 의미 있는 산출물이라고 생각한다.

끝.