pile·
백엔드·스포카spoqa·

기능 테스트 전환 이야기

문제통합 테스트만으로는 Hibernate Lazy Loading, Flush, TransactionalEventListener 같은 실제 운영 동작을 못 잡아내 배포 후에야 버그가 드러났다.

접근내장 서버로 실제 환경을 재현하고 외부 API는 MockServer로 HTTP 레벨에서 모킹했다. 테스트 헬퍼와 OpenEntityManager Aspect로 데이터·세션 문제를 정리하고 Kotest의 Eventually로 비동기 검증을 도입했다.

결과기존 통합 테스트 코드를 전부 제거하고 기능 테스트만으로 전체 기능을 검증하는 체계를 갖췄고 단위 테스트와 역할 분담도 명확해졌다.

스포카
스포카 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)
·takedown 요청

이 글과 비슷한

  2. 백엔드·네이버페이네이버페이·

    Composite PK에서 시작된 Spring Boot 4 / Spring Batch 6 업그레이드 기록

    문제Spring Data JDBC 의 Composite ID 적용을 위해 Spring Boot 3.5 → 4.0.1 업그레이드 시 Spring Batch, Kotlin, Jackson 등 전체 스택 메이저 전환 필요.

    접근Spring Boot 4 / Spring Batch 6 / Spring Framework 7 / Kotlin 2.3 / Jackson 3 / Kotest 6 / Gradle 9 / ojdbc11 순차 업그레이드. Composite ID 는 Persistable 인터페이스로 구현, JdbcDefaultBatchConfiguration 상속으로 메타데이터 저장.

    결과기술 부채 해결 + 장기 유지보수성 개선. 운영 DB 접근 정책 충돌을 사전 식별해 안정적 배포 달성.

    #kotlin#spring#spring-boot+3