📚 TDD(테스트 주도 개발) 학습 및 `@SpringBootTest` 빌드 속도 저하 트러블 슈팅

테스트 주도 개발(Test Driven Development, TDD)은 기능 구현에 앞서 테스트 코드를 먼저 작성하는 소프트웨어 개발 방법론입니다. 테스트 케이스를 먼저 작성하고 이를 통과시킬 최소한의 코드를 작성하는 과정을 반복하며 개발을 진행합니다.

---

🙋‍♀️ TDD에 대한 경험과 의문점

3년 전 Spring 공부 중 테스트 코드를 접했고, 이후 사이드 프로젝트에서 PR 템플릿에 맞추어 단순 값을 대충 바꿔 넣는 정도로만 사용했습니다. 리뷰 없이 '내 맘대로' 작성했기에, TDD 방식은 알았지만 테스트 코드 작성이 단순 반복적이고 재미없는 일로 느껴졌습니다. 특히 '테스트 코드부터 개발'한다는 방식이 현실적으로 상상되지 않았습니다.

TDD 의문점과 해결

Q1. 테스트 코드를 짜는데 시간이 걸린다.

• 테스트 코드에 들이는 시간이 아예 없을수는 없다. 하지만 TDD 방식으로 검증과 개발을 동시에 진행한다면, 개발만 하다가 계획을 변경하고, 사이드 이펙트를 경험하는 것보다 빠를수밖에 없다.

Q2. 테스트 코드부터 개발하는 상황이 상상이 되지 않는다.

• 테이블 설계를 먼저 하는 것에 익숙하다 보니, 전혀 그려지지 않는 일이었다. 하지만 필요한 API요청들을 E2E로 먼저 작성하고, 세세한 로직들을 만들어 가는 과정, 객체의 특성을 녹이는 과정이 이제는 이해되기 시작했다.

Q3. 단위/통합/E2E 각각 어떤 검증을 해야하나요.

단위/통합 테스트 (주로 비즈니스 로직 및 객체 상태 검증)

//DB 저장 메서드가 호출되는지 확인
verify(repository).save(any())
//반환된 객체가 null이 아닌지
assertNotNull(result)
//반환 객체의 핵심 필드가 정확한지 
assertEquals(expectedValue, result.getField())
//특정 필드 값이 비즈니스 로직에 맞는지
assertTrue(result.isValid())
//삭제 메서드가 정확히 1번 호출되었는지 확인
verify(repository, times(1)).deleteById(id)
//삭제 후 조회 시 예외가 발생하는지 확인
assertThrows(NotFoundException.class, () -> service.read(id))

E2E 테스트 (주로 시스템 응답 및 영속성 검증)

//201 응답 확인
assertEquals(HttpStatus.CREATED, response.getStatusCode())
//DB에서 직접 조회하여 객체가 존재하는지 확인.
assertNotNull(repository.findById(id).orElse(null))
//응답 JSON 필드 값 검증
assertEquals(expectedValue, response.getBody().getFieldName())
//DB 조회 결과 Optional이 비어있는지 확인
assertTrue(repository.findById(id).isEmpty())

Q4. 운영DB에서 테스트 코드가 실행될수도 있다던데..

• 이 위험도 때문에 테스트 코드 작성이 주저되기도 했다. 사실 내가 설정을 잘 해놓으면 되는 일인데, 혹여나 하는 걱정이 있었다.

---

🐢 @SpringBootTest 빌드 속도 저하 트러블 슈팅

E2E 및 통합 테스트 개발 중 빌드 시간이 5분 이상 소요되는 현상이 발생했습니다. 원인을 찾기 시작했습니다.

1) @Spy와 @SpyBean 차이점 검토 (원인 아님)

특징	@Spy (Mockito)	@SpyBean (Spring Boot Test)
프레임워크	Mockito	Spring Boot Test
사용 환경	단위 테스트 (Unit Test)	통합 테스트 (Integration Test)
객체 대상	개발자가 new로 생성한 일반 인스턴스	Spring 컨텍스트 내의 기존 Bean
주입 방식	@InjectMocks를 통한 수동 주입	@Autowired를 통한 Spring의 자동 주입
영향 범위	테스트 메서드/클래스 내부	Spring Application Context 전체

@SpyBean 사용 시점과 속도 저하 시점이 비슷하여 의심했지만, 이는 근본 원인이 아님을 확인했습니다.

2) Testcontainers 환경 문제 발견 (주요 원인)

Docker와 Testcontainers가 띄워지는 로그를 통해 Docker 관련 문제임을 추정했습니다.

✅ 해결 과정
1) Docker Desktop 업데이트
2) Testcontainers 아이콘을 발견하고 실행 중인 컨테이너를 모두 삭제했습니다.
3) Containers running locally > Embedded Runtime을 desktop-linux로 변경했습니다.
4) 설정 변경 후 테스트 실행 속도가 현저히 빨라졌습니다.

🔎 Embedded Runtime vs. Desktop Linux Docker 데몬

성능 및 오버헤드 (M1/Mac 환경의 경우 더 중요)
Embedded Runtime (리눅스 네이티브): Testcontainers는 도커 API를 사용하여 컨테이너를 직접 실행합니다. 파일 시스템 접근이 호스트 리눅스 커널 수준에서 이루어지기 때문에 오버헤드가 거의 없어 빌드 및 테스트 속도가 가장 빠릅니다.

Docker Desktop (Mac/Windows): Mac이나 Windows에서 Docker Desktop을 사용하면, 도커 데몬은 항상 내부 VM 내에서 실행됩니다. 특히 M1/M2/M3 Mac의 경우, 성능 개선이 이루어졌지만 여전히 네이티브 리눅스에 비하면 약간의 파일 I/O 오버헤드가 발생할 수 있습니다.

제 환경(M1)에서는 예상과 달리 Embedded Runtime에서 더 오래 걸리는 현상을 경험했습니다. 이부분은 좀더 공부해봐야 직접적인 문제를 알수 있을것 같습니다.

💡 TDD 관련 학습 내용 정리

이번 경험을 통해 알게 된 주요 개념과 도구를 정리했습니다. 추후 적합한 도구를 활용해 다양한 테스트 코드를 경험해 보려고 합니다.

🟢 테스트 더블 (Test Double)

• Dummy – 테스트에 필요하지만 실제로 사용되지 않는 더미 객체
• Stub – 특정 메서드 호출 시 미리 정의된 값 반환
• Fake – 실제 구현과 비슷하지만 단순화된 객체 (예: In-memory DB)
• Mock – 호출 여부, 인자 등을 검증할 수 있는 객체
• Spy – 실제 객체를 그대로 사용하면서 일부 동작만 감시/검증

🧪 E2E 테스트

• TestRestTemplate – Spring Boot 서버 띄워 HTTP 요청/응답 검증
• WebTestClient – WebFlux, 실제 HTTP 호출
• RestAssured – REST API E2E 테스트
  🧠 통합 테스트
• @SpringBootTest – 전체 스프링 컨텍스트
• TestContainers – DB/Kafka/Redis 연동

🧱 단위 테스트

• Repository / Service / Controller
• JUnit / Kotest
• Mock / Spy (Mockito)
• @ParameterizedTest / @ValueSource

🔍 슬라이스 테스트

• @WebMvcTest – Controller만, Service/Repo Mock
• @DataJpaTest – Repository/JPA
• @RestClientTest – RestTemplate/WebClient
• @JsonTest – JSON 직렬화/역직렬화
• MockMvc – 컨트롤러 테스트

🎨 코드 포맷 / 스타일

• Spock – BDD 스타일

🗂 테스트 데이터

• Fixture Monkey – 코드 기반 픽스처 생성
• DBRider – DB 기반 픽스처 생성