테스트 fixture

실전! 코틀린과 스프링 부트로 도서관리 애플리케이션 개발하기 (Java 프로젝트 리팩토링)

22강. Enum Class를 활용해 책의 분야 리팩토링 하기

2025. 01. 02. 02:26 작성

수정됨

안녕하세요 강사님.

코틀린을 배우는데 좋은강의 만들어주셔서 감사합니다.

테스트를 위한 fixture 코드 부분에 대해 의견 여쭤보고 싶습니다.

강의에선 직접 엔티티 내부에 테스트를 위한 fixture 함수를 만들어 주셨는데, 팀 내부 의사결정에 따라 두어도 괜찮을 수도 있을 것 같지만 만약 테스트용 코드는 분리해야 한다고 하면

아래처럼 테스트 코드 패키지쪽에 fixture 생성을 위한 유틸파일을 만들고, 테스트 코드에서만 Book.fixture(...) 같은 형태로 사용할 수 있도록 엔티티에 비어있는 companion object를 만든 뒤 확장함수를 작성하는 형태로 해도 괜찮을지 의견 여쭤보고 싶습니다.!

테스트코드용 유틸 생성

User, Book 등의 엔티티에 비어있는 동행객체 선언
엔티티별 Companion 확장함수 작성
테스트 코드에서 엔티티.fixture() 형태로 사용

java spring kotlin spring-boot 리팩토링

답변 2

최태현

지식공유자

2025. 01. 02. 22:20

안녕하세요 우럭아왜우럭님~~ 🙂 닉네임이 참 센스 있으시네요~~!!! 🤣

우선 말씀해주신 내용은 두 가지 인 것 같습니다!

[1. test 패키지에 fixture를 만들면 어떨까?]

저는 개인적으로 test 패키지에 fixture를 만드는 것도 좋은 방법이라고 생각하긴 하는데 딱 한 가지 치명적인 아쉬움이 있습니다. 🥲

바로 멀티 모듈에서 상위 모듈이 하위 모듈의 테스트 패키지에 (기본적으로는) 접근할 수 없다 인데요!

제 경험상 아무리 작은 서비스라 하더라도 멀티 모듈을 사용하는 경우가 많고 layered architecture에 맞춰 가장 모듈을 단순하게 나눠도

core (Entity가 들어 있는 모듈)
api
admin
scheduler
batch

와 같이 두 개 이상의 depth가 생기게 됩니다. 이때 상위 모듈 (ex. api, admin) 에서 하위 모듈 (core)에 있는 fixture를 활용해 테스트를 작성해야 하는데! fixture가 테스트 패키지에 들어 있다면 별도로 복잡한 gradle 설정을 해주지 않는한 fixture 코드를 재사용하기가 어렵더라고요~ 🥲

그래서 결국

테스트에서만 사용될거지만 멀티 모듈의 개발 편의성을 위해 프로덕션 코드에 fixture 만들기
테스트 패키지의 의존성을 엮기 위해 번거로운 gradle 설정과 테스트 환경이 일부 꼬일 수 있는 문제를 감수하고 테스트 코드에 fixture 만들기

중 하나를 선택해야 하는데요! 저는 여기서 대부분 전자의 방법을 선택하는 편입니다. 🙂

[2. fixture를 별도 파일로 분리하면 어떨까?]

매우 좋은 방법이라고 생각합니다! 저는 Companion 의 확장 대신 진짜 Companion 객체 안에 만드는 편이긴해요!

도메인 필드가 2~3개 정도 일때는 굳이 파일을 나누지 않아도 괜찮은데 필드가 5~6개가 넘어가고 (실제로는 수십개가 있는 경우도 허다하니) 파일을 나누는게 더 깔끔한 것 같습니다.

public class UserFixtures {
  companion object {
    fun create(...): User {
      ...
    }
  }
}

그런데 작성해주신걸 보니 Companion의 확장 함수도 좋을 것 같네요! 👍

열심히 들어 주시고 더 좋은 방법도 고민해 주시다니 대단하시네요~~

또 궁금한 점 있으시면 편하게 질문 남겨주세요! 감사합니다. 🙇

인프런 AI 인턴

2025. 01. 02. 02:31

안녕하세요, 인프런 AI 인턴입니다. 우럭아왜우럭님, 코틀린을 공부하시면서 강의를 통해 많은 도움을 받고 계신 듯하여 기쁩니다. 테스트 코드 작성과 관련하여 좋은 질문을 주셨네요.

테스트용 Fixture 코드를 엔티티 내부에 두는 방식

강의에서 엔티티 내부에 테스트용 fixture 함수를 만들었던 것은, 코드의 응집성과 테스트 편의성을 높이기 위한 선택일 수 있습니다. 그러나, 말씀하신 대로 팀의 코드 스타일이나 정책에 따라 테스트 코드와 프로덕션 코드를 명확히 구분하는 것이 중요한 경우, Fixture 코드를 별도로 관리할 수도 있습니다.

테스트코드 패키지에 유틸리티 파일 분리

이미지에서 설명하신 것처럼, FixtureUtils.kt와 같은 파일을 만들어 테스트 코드에서만 사용할 수 있도록 fixture를 관리하는 방법은 충분히 권장할 수 있는 좋은 방법입니다. 특히, 코드를 분리하여 유지보수성과 가독성을 높일 수 있으며, 프로덕션 코드와의 결합도를 줄일 수 있습니다.

비어있는 Companion Object: Kotlin에서는 확장 함수를 사용하여 클래스 외부에서 함수를 추가할 수 있어, 비어있는 companion object를 선언하고, 해당 객체에 fixture 함수를 확장 함수로 작성하는 방법은 유연성을 제공합니다.
엔티티별 Companion 확장함수 작성: 각 엔티티에 대해 확장함수를 통해 fixture를 제공함으로써, 코드가 더욱 깔끔하게 관리될 수 있습니다.

테스트 코드에서 엔티티.fixture() 형태로 활용

엔티티 클래스 내에 동행 객체를 선언하고, 이 객체에 확장 함수를 작성하여 엔티티.fixture() 형태로 사용할 수 있도록 한 것은, 코드의 일관성과 테스트 코드의 가독성을 높이는 좋은 방법입니다.

관련하여 테스트 픽스쳐 관련 질문 게시물을 참고하시면, 최태현 강사님의 상세한 설명과 팀 내에서의 결정적인 요인들이 매우 유용할 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변