테스트 코드 작성, 낭비가 아닌 투자였다.

"또 테스트 코드를 작성하라고? 실제 기능 개발하기도 바쁜데..."

많은 개발자, 특히 저와 같은 주니어 개발자들이 테스트 코드 작성에 대해 처음 가지는 생각입니다.

저 역시 그랬습니다. 

 

테스트 코드를 작성하면 개발 시간이 배로 늘어날 것이고, 코드를 리팩터링 할 때마다 테스트 코드까지 수정해야 한다면 유지보수는 더욱 힘들어질 거라고 생각했습니다.

 

그리고 무엇보다 "도대체 어떤 것을 검증해야 옳은 테스트 코드인가?"라는 근본적인 질문이 항상 머릿속을 맴돌았습니다.

 

약 70개의 단위 테스트 코드를 작성하며 신규 기능을 개발한 지금, 제 인식은 완전히 바뀌었습니다. 테스트 코드 작성은 시간 낭비가 아니라 오히려 시간을 절약하기 위한 투자였습니다. 테스트 코드를 통해 안정적인 리팩토링이 가능해졌고, Postman 같은 도구로 수동 검증하던 불필요한 작업들이 자동화되었습니다. 게다가 BDD 방식으로 작성된 테스트 코드는 팀원들에게 기능의 의도를 명확히 전달하는 '문서'가 되었습니다.

 

이 글에서는 JUnit5, Mockito를 활용해 약 70개의 단위 테스트를 작성하며 배운 실전 노하우를 공유하려 합니다. 특히 주니어 개발자 관점에서 테스트 코드의 가치, BDD 스타일 테스트 코드의 구성 방법, 그리고 테스트 코드 작성 시 직면하게 될 문제점들과 그 해결책에 대해 이야기하겠습니다.

 

테스트 코드가 개발 프로세스에 가져온 변화

"테스트 코드는 개발 속도를 늦춘다." 이것이 제가 가장 크게 오해했던 부분입니다. 하지만 실제로 프로젝트에 테스트 코드를 적용해 보니, 정반대의 결과를 가져왔습니다.

 

테스트 코드 작성 전: 불안한 개발 사이클

테스트 코드를 작성하기 전에는 다음과 같은 개발 사이클을 반복했습니다:

1. 비즈니스 코드 작성
2. Postman으로 API 호출 및 응답 확인
3. 문제 발견 시 코드 수정
4. 다시 Postman으로 테스트
5. 연관된 다른 기능들도 여전히 정상 작동하는지 일일이 확인

 

리팩토링이 필요할 때마다 이 과정을 반복해야 했고, 변경사항이 다른 기능에 미치는 영향을 확인하는 과정은 시간이 갈수록 복잡하고 부담스러워졌습니다. "내가 놓친 케이스가 있지 않을까?"라는 불안감은 항상 따라다녔습니다.

 

테스트 코드 작성 후: 개발 사이클

테스트 코드를 작성한 후, 개발 사이클이 완전히 바뀌었습니다

 

1. 테스트 코드 작성 (또는 기존 테스트 수정)
2. 기능 코드 작성
3. 테스트 실행으로 기능 검증
4. 모든 테스트가 통과하면 다음 기능으로 진행

 

(1, 2번의 순서는 바뀔 수 있으며 1번을 먼저하는 방식을 흔히 TDD라고 불립니다.)

 

특히 리팩토링 과정에서 테스트 코드의 가치가 확실히 드러났습니다. 코드 구조를 개선하거나 성능을 최적화할 때, 모든 테스트가 통과한다면 기존 기능을 깨뜨리지 않았다는 자신감을 가질 수 있었습니다.

 

실제 사례: 조건부 로직의 리팩토링

가장 인상적이었던 경험은 주가 데이터를 조회하는 서비스에서 발생했습니다. 

장 전 / 장 중 / 장 종료 등 다양한 상황에 따라 다른 방식으로 데이터를 가져오는 조건부 로직이 있었습니다. 이를 리팩토링할 때, 각 시나리오에 대한 테스트 코드가 있었기 때문에 자신감 있게 코드를 수정할 수 있었습니다

 

예시 코드 (BDD 스타일의 테스트 케이스 예시 (장 중 주가 데이터 조회)

@Test
@DisplayName("장 중에는 실시간 주가 데이터를 조회한다")
void getRealTimePriceWhenMarketIsOpen() {
    // Given
    given(marketStatusChecker.isMarketOpen()).willReturn(true);
    given(stockPriceRepository.findRealTimePrice(STOCK_CODE))
        .willReturn(Optional.of(new StockPrice(STOCK_CODE, 50000, LocalDateTime.now())));
    
    // When
    StockPriceDto result = stockPriceService.getCurrentPrice(STOCK_CODE);
    
    // Then
    assertThat(result.isRealTimePrice()).isTrue();
    assertThat(result.getPrice()).isEqualTo(50000);
}

 

이러한 테스트 코드 덕분에 복잡한 조건부 로직을 전략 패턴으로 리팩터링 하는 과정이 훨씬 수월했고, 모든 시나리오가 여전히 정상 작동한다는 확신을 가질 수 있었습니다.

 

테스트 코드로 인한 버그 조기 발견

테스트 코드를 작성하면서 가장 놀라웠던 것은 기능 개발 중에 미처 생각하지 못했던 엣지 케이스나 버그를 사전에 발견할 수 있었다는 점입니다. 특히 "주말에 조회 시 직전 거래일의 종가를 보여준다"는 요구사항을 구현할 때, 테스트 코드를 작성하며 "공휴일이 연속될 경우"에 대한 처리가 빠져있다는 것을 발견했습니다.

 

테스트 코드가 없었다면 이런 케이스는 프로덕션 환경에서 발견되었을 테고, 그만큼 대응 비용이 커졌을 것입니다.

결론적으로, 테스트 코드 작성은 개발 프로세스의 '추가 작업'이 아니라 더 빠르고 안정적인 개발을 가능하게 하는 필수적인 '투자'였습니다.