1. 도입: 테스트 코드에서 고민되는 질문들
테스트 코드를 작성하다 보면 여러 가지 질문이 떠오릅니다. 그중에서도 특히 많은 고민을 불러일으키는 질문은 아래의 세 가지입니다:
- 테스트에서 외부 요소(현재 시간 등)는 어떻게 제어해야 하는가?
- Private 메서드는 테스트를 해야 하는가?
- 테스트에서만 사용하는 함수나 코드는 어떻게 처리해야 하는가?
(1) 외부 요소는 어떻게 제어해야 하는가?
외부 요소가 테스트에 미치는 영향
코드에서 외부 요소(예: 현재 시간 LocalDateTime.now, 환경 변수, 외부 API 호출 등)를 직접 호출하면, 테스트 작성이 어려워지고 유지보수에 악영향을 줄 수 있습니다. 특히 외부 요소를 직접 호출하면 다음과 같은 문제가 발생합니다:
- 테스트 결과의 불안정성 : 테스트가 실행될 때마다 현재 시간이 달라지기 때문에 결과가 일관되지 않을 수 있습니다.
- 테스트 작성과 유지보수의 어려움 : 외부 요소를 직접 사용하는 경우, 이를 Mocking하거나 대체하는 로직이 필요합니다.
한 번 LocalDateTime.now와 같은 코드를 쓰기 시작하면, 프로젝트 전반에 퍼지면서 관리가 점점 어려워집니다. 따라서 의식적으로 외부 요소를 직접 포함한 로직을 지양하고, 외부에서 주입받아서 사용하도록 해야 합니다.
리팩토링: 외부 요소를 제어할 수 있도록 설계하기
잘못된 코드: 외부 요소를 직접 호출
public ParkingTicket createTicket() {
LocalDateTime entryTime = LocalDateTime.now(); // 외부 요소 직접 호출
if (entryTime.toLocalTime().isBefore(OPEN_TIME) || entryTime.toLocalTime().isAfter(CLOSE_TIME)) {
throw new IllegalArgumentException("주차장이 운영되지 않는 시간입니다.");
}
return new ParkingTicket(entryTime, vehicle);
}위 코드는 현재 시간에 따라 실행 결과가 달라질 수 있으며, 테스트하기도 어렵습니다.
개선된 코드: 외부 요소를 주입받아 사용
public ParkingTicket createTicket(LocalDateTime entryTime) {
if (entryTime.toLocalTime().isBefore(OPEN_TIME) || entryTime.toLocalTime().isAfter(CLOSE_TIME)) {
throw new IllegalArgumentException("주차장이 운영되지 않는 시간입니다.");
}
return new ParkingTicket(entryTime, vehicle);
}LocalDateTime.now()를 호출하는 대신, 현재 시간을 매개변수로 주입받아 사용합니다.- 이를 통해 테스트 시 고정된 값을 전달할 수 있습니다.
테스트 작성: 고정된 값 사용
개선된 테스트 코드
@DisplayName("주차권 생성 시 입차 시간을 기록한다.")
@Test
void registeredEntryTime() {
// given
LocalDateTime fixedEntryTime = LocalDateTime.of(2025, 1, 1, 10, 0); // 고정된 값 사용
Vehicle vehicle = new Vehicle("123가 4567", VehicleType.SEDAN);
// when
ParkingTicket ticket = ParkingTicket.create(vehicle, fixedEntryTime);
// then
assertThat(ticket.getEntryTime()).isEqualTo(fixedEntryTime);
}이렇게 고정된 입력값을 사용함으로써, 테스트가 언제 실행되든 동일한 결과를 얻을 수 있습니다. 또한 테스트를 읽는 사람은 고정된 입력값과 예상 결과를 보고 테스트 의도를 바로 이해할 수 있습니다.
(2) Private 메서드는 테스트해야 하는가?
Private 메서드는 테스트하지 않는다
Private 메서드는 객체 내부의 구현 세부사항입니다. 따라서 이를 직접 테스트할 필요는 없습니다. 그 이유는 다음과 같습니다:
- Public 메서드로 간접 검증 가능 : Private 메서드는 Public 메서드를 통해 호출되므로, Public 메서드를 테스트하는 과정에서 자연스럽게 검증됩니다.
- 클라이언트 입장에서 중요하지 않음 : 클라이언트가 호출할 수 있는 것은 Public 메서드뿐입니다. Private 메서드는 클라이언트가 몰라도 되는 내부 구현입니다.
Private 메서드를 테스트하고 싶다는 생각이 들면, 설계가 복잡하다는 신호일 수 있습니다. 이 경우 Private 메서드의 책임을 작은 객체로 분리하는 것을 고려해야 합니다.
(3) 테스트에서만 사용하는 코드는 어떻게 처리할까?
Request DTO와 테스트 전용 생성자
테스트를 작성하다 보면, 테스트에서만 필요한 데이터 생성자가 필요할 때가 있습니다. 예를 들어, Request DTO를 생성하기 위해 테스트 전용 생성자를 추가할 수 있습니다. 이러한 생성자나 getter 같은 간단한 함수들은 프로덕션 코드에 추가되어도 괜찮습니다.
결론
- 외부 요소는 제어 가능하도록 설계하자 :
LocalDateTime.now와 같은 외부 요소는 최상위 레벨에서 주입받아야 한다. - Private 메서드 테스트는 설계의 신호일 수 있다 : Private 메서드를 테스트하지 말고, 작은 객체로 분리해 Public 메서드로 검증하자.
- 테스트 전용 코드는 효율적으로 관리하자 : 테스트 전용 생성자나 빌더 패턴을 활용해 테스트 데이터를 간결하게 관리하자.
📌 이 글은 TDD 강의를 학습한 내용을 바탕으로 재구성하였습니다. 문제가 되는 부분이 있다면 수정하겠습니다.
