나홀로 무작정 TDD 도입해보기 (with Kotlin Spring Boot)

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

웹 개발

대상자

- 초보 개발자, TDD 도입 경험자

- Kotlin/Spring Boot 사용자

- 테스트 코드 작성 시 가독성/유연성에 관심 있는 개발자

핵심 요약

• TDD는 테스트 코드 작성 후 리팩토링을 통해 코드 품질 향상 가능
• TestContainer 사용 시 DB 별도 환경 구축으로 테스트 격리 가능 (예: @BeforeEach, @AfterEach 활용)
• DDD 구조 적용 시 테스트 요구사항과 코드 설계 간 유기적 연계 가능

섹션별 세부 요약

1. TDD 도입 배경 및 장점

• TDD는 Red, Green, Refactor 단계를 통해 코드 품질을 보장하고, 예외 처리가 명확한 테스트 요구사항 작성이 가능
• 테스트 코드를 먼저 작성함으로써 로직 구현 시 의존성 낮춤, DTO 활용 증대 가능
• Kotlin 사용 시 NPE(Null Pointer Exception) 컴파일 시점 검증 가능

2. TestContainer 적용과 문제점

• MySQL, Redis에 TestContainer 적용하여 클래스 단위로 DB 격리
• 테스트 컨테이너의 다운타임 문제로 인해 메서드 단위 테스트는 비추천
• @AfterEach에서 테이블 삭제/재생성 방식으로 테스트 격리 대안 제시

3. TDD 도입 시 어려움 및 해결 방향

• 테스트 요구사항 다수 작성 시 코드 복잡도 증가 가능성
• DDD 구조를 통해 도메인 별 패키지 분리로 테스트 요구사항과 코드 설계 연계
• 예외 케이스 미정의 시 테스트 통과 ≠ 로직 완성 (예: 100% 테스트 통과도 비즈니스 로직 완성 보장 불가)

4. 테스트 코드 신뢰성 및 개선 방안

• JUnit5의 테스트 순서 보장 불가 문제로 인해 테스트 간 간섭 가능성
• 테스트 컨테이너 재활용, 테이블 삭제/재생성으로 테스트 시간 단축 방안 제시
• 프론트와의 API 명세서 정확성 확보 필요 (예: DTO/핸들러 유연성 확보)

5. Kotlin 사용 경험

• NPE 컴파일 시점 검증, 가독성 향상 (예: val, fun 활용)
• Java 대비 코드 간결성 우위 체감 (예: 생성자 정의 생략 가능)
• 코루틴 등 비동기 처리 기능 미활용으로 아쉬움 남음

결론

• DDD 구조 + TDD 적용 시 테스트 요구사항과 코드 설계 간 유기적 연계 가능
• TestContainer 사용 시 테스트 컨테이너 재활용, 테이블 삭제/재생성으로 테스트 시간 최적화
• 테스트 코드 작성 시 프론트와의 API 명세서 정확성 확보 필요
• Kotlin의 NPE 방지, 가독성 향상 효과를 체감하여 Java 개발자에게 추천