BaseIntegrationTest에서 통합 테스트 데이터 정의 구조 개선

[Gyuhyeok99]

논의 배경

현재 BaseIntegrationTest를 상속받는 방식으로 공통 테스트 데이터를 관리하고 있습니다.
이 방식은 테스트마다 별도 세팅 없이 공통 데이터를 재사용할 수 있어 초기 개발에는 효율적이었습니다.
하지만 최근 전체 조회 테스트를 작성하면서, 기본으로 생성되는 siteUser, application 등의 데이터가 테스트 결과에 영향을 주는 문제가 발생했습니다.
그로 인해 테스트 신뢰성이 떨어지고, 테스트를 작성하기 어려워졌습니다.

• 관련 이슈: feat: 관리자 페이지 학점 인증 관리 api 추가 #207

[Gyuhyeok99]

java-test-fixtures 도입

BaseIntegrationTest에서 미리 데이터를 정의했던 이유는,
테스트의 given() 절이 불필요하게 길어질 경우 가독성이 떨어지기 때문이었습니다.

그래서 공통 Test Fixture를 잘 활용하면 좋겠다고 생각했지만,
각 패키지마다 중복된 Fixture가 생기는 단점이 있었습니다.

이를 해결하기 위해 java-test-fixtures를 도입하여,
공통 Fixture를 모듈화하고 테스트 간의 데이터 충돌 없이 독립적인 데이터 구성이 가능하도록 개선하면 어떨까요?

참고자료 : https://tech.kakaopay.com/post/given-test-code-2/

[Gyuhyeok99]

추가로, 제 생각에는 대학 정보와 같은 데이터는 테스트 중 생성/수정/삭제 등의 동작을 수행하지 않기 때문에,
기존처럼 BaseIntegrationTest에 그대로 두어도 괜찮다고 생각합니다!

그 외의 유저나 학점과 같이 테스트 중 상태가 바뀌는 데이터들은 테스트 목적에 맞게 독립적으로 구성하는 것이 적절하다고 생각하며,이러한 데이터는 test-fixture를 통해 생성하면 좋을 거 같다고 생각했습니다.

[nayonsoso]

이 주제에 대해서 이야기 꺼내주셔서 너무 좋네요😊
저도 그 의도에 정말 공감하고 있습니다.
아무래도 test fixture의 구성이 잘 논의되어야 이후의 일이 많아지지 않을 것 같아서,
코드레벨에서 더 명확하게 논의하면 좋겠어서 몇가지 의견을 드려요!

---

java-test-fixtures 도입

java-test-fixtures는 멀티 모듈에서 유용하고, 그 외에는 굳이 필요하지 않다고 생각해요.
실제로 규혁님이 링크해주신 글의 다른 시리즈에서도 동일하게 말하고 있고요!

ref. https://tech.kakaopay.com/post/mock-test-code/#mock-test-%EB%B0%A9%EB%B2%95-%EC%A0%95%EB%A6%AC

---

그리고 추가적으로 더 질문이 있는데요,

공통 Fixture를 모듈화하고 테스트 간의 데이터 충돌 없이 독립적인 데이터 구성이 가능하도록 개선하면 어떨까요?

"공통 Fixture를 모듈화" 한다는 말씀이 멀티 모듈로 가자는 말씀이신가요?
모듈화라는 단어를 어떤 의미로 쓰셨는지 궁금하네요!

---

테스트 중 상태가 바뀌는 데이터들은 테스트 목적에 맞게 독립적으로 구성하는 것이 적절하다고 생각하며,
이러한 데이터는 test-fixture를 통해 생성하면 좋을 거 같다고 생각했습니다

이 부분에 대해서 코드 레벨로 더 구체적으로 설명해주시면 좋겠어요.
'테스트 목적에 맞게 독립적으로 구성' 한다는게 아래 중 어떤걸 의도하신건가요?

형식

• fixture를 생성하는 메서드를 선언하여, 각 테스트 함수에서 fixture 함수를 호출하여 사용
• static final fixture 객체를 미리 만들어두어, 각 테스트 함수에서 접근하여 사용
• data.sql 파일을 만들어 @Sql 어노테이션으로 로드

위치

• 테스트 클래스 내부
  • 중복 코드가 많을 수 있지만, 하나의 파일 안에서 다 확인할 수 있음
• 사용되는 도메인 패키지 하위
  • package private 객체에 대한 fixture도 생성 가능 (아직 우리 어플리케이션에 없긴 함)
• 도메인 패키지와 같은 레벨의 다른 fixture 패키지
  • 전체 테스트 코드에서 사용할 fixture를 하나의 위치에서 다 같이 선언

[Gyuhyeok99]

저런 글이 또 있었군요 😅 제가 좀 섣불리 생각했던 거 같네요.
저는 싱글모듈이어도 사용하면 좋겠다고 생각했던 이유가

private SiteUser createSiteUser() {
        SiteUser siteUser = new SiteUser(
                "test@example.com",
                "nickname",
                "profileImageUrl",
                "1999-01-01",
                PreparationStatus.CONSIDERING,
                Role.MENTEE,
                Gender.MALE
        );
        return siteUserRepository.save(siteUser);
    }

이런 유저 생성하는 private test-fixture가 현재 10개 이상 중복으로 테스트코드에 있는 거 같아서 이를 재활용할 수 있게 한 곳에 모아두면 좋겠다라고 생각했었습니다.

그렇다면 그걸 어디에 정의해두면 좋을까라고 했을 때 한 눈에 알아보기 쉬운 testFixtures에 두고 쓰면 확장성(언제가 할 수도 있는 멀티모듈)에도 좋을 거 같다고 생각해버린 거 같아요 🥲 YAGNI를 지키지 않았네요 ㅎㅎ..

잘 정리해서 말씀해 주셔서 감사해요.

지금 저희 상황에서 다시 생각해봤을 때 제가 생각한 의도는

fixture를 생성하는 메서드를 선언하여, 각 테스트 함수에서 fixture 함수를 호출하여 사용
전체 테스트 코드에서 사용할 fixture를 하나의 위치에서 다 같이 선언

이 방식을 생각했었습니다.

테스트 클래스 내부

현재 사용하는 방식인데, 가독성은 괜찮지만 생각보다 중복 코드가 꽤 많고 나중에 컬럼 하나만 바뀌어도 테스트 수십 개를 손봐야 하는 일이 생길 수 있을 것 같습니다.

사용되는 도메인 패키지 하위

저희 main 쪽에서는 package-private 객체를 따로 사용하고 있지 않아서 이 방식보다는 3번 방식처럼 fixtures 패키지를 따로 만들어서 UserFixture, ScoreFixture 등 도메인별로 나눠 관리하는 게 더 가독성 있고 유지보수도 편할 것 같다는 생각이 듭니다.

영서님은 어떻게 생각하시나요?

추가로

static final fixture 객체를 미리 만들어두어, 각 테스트 함수에서 접근하여 사용

이 방식으로 하면 BaseIntegrationTest 때의 문제와 같은 문제가 발생한다고 생각했는데 맞나요?

[nayonsoso]

제 생각도 규혁님과 동일해요!

• 함수를 호출해서, 원하는 객체를 그때그때 생성 & 저장
  • 글로벌 객체를 fixture로 만들어 공유하면, 상태가 변하는 등의 문제가 있을 것이라 생각했어요.
  • data.sql 방식으로 테스트 데이터를 추가하면, 엔티티의 컬럼이 바뀔 때
    컴파일 에러가 아니라 런타임 에러가 발생해서 에러를 늦게 발견할것이라 생각했어요.
• 전체 테스트 코드를 하나의 패키지에서 관리
  • 저도 createSiteUser() 같은 함수를 매번 선언하는건 중복이 많다 생각했어요😅
  • 각 도메인 별 fixture 를 만드는 것도 같은 이유로 중복이 많을것 같고요~

---

추가로 몇가지를 더 생각해봤는데, 여기에 대해서는 어떻게 생각하시나요?

• 해당 도메인에서만 필요한 코드이면, private 메서드로 만들기
  • 예를 들어 PostCommandServiceTest의 createPostUpdateRequest() 같은 것들이요!
• 미리 세팅되어야 할 데이터가 많다면 도메인 package 하위에 fixture 만들기
  • 예를 들어 지원을 위해서는 "지역 / 국가 / 대학교 / 지원을 위한 대학 정보"가 모두 세팅되어있어야 해요.
    이 경우 아주 많은 fixture 함수를 호출해야하고, 심지어 그 세팅이 테스트의 핵심적인 내용은 아니예요.
    그래서 application 패키지 하위에 그 세팅을 위한 클래스를 분리하는 것도 좋겠다고 생각했어요.
• 메서드 체이닝으로 값 설정하기
  • 제가 다른 프로젝트에서 메서드 오버로딩으로 fixture를 구현한 적이 있는데,
    요구사항이 복잡해질수록, 테스트 케이스가 다양해지고 오버로딩도 너무 많아지더라고요😵‍💫
    그래서 메서드 체이닝으로 설정하는건 어떨지 제안 드리고 싶어요!

[nayonsoso]

📝 테스트 fixture의 요구사항을 정리한 회의 내용입니다. 📝

• fixture 객체는 테스트 코드 전체에 공유되어선 안된다.
• 이를 위해, 도메인 객체를 생성하는 함수를 제공하는 형태로 fixture를 제공한다.
• 가독성을 위해 기본적으로 메서드 채이닝 방식을 사용한다.
  • 단, 같은 도메인 개발자라면 익숙한 기본 세팅 은 별도 체이닝 없이 한 번에 세팅되게 한다.
• 도메인별로 fixture를 분리한다. (변경 전파 최소화)
• 다른 도메인과의 연관관계(FK)가 있다면, 저장 순서를 fixture 내부에서 책임진다.
  • 테스트 작성자가 FK 순서를 직접 신경쓰지 않게 하기 위함이다.
  • 다른 대안으로는 JPA의 cascade = CascadeType.PERSIST 옵션이 이야기되었지만,
    테스트코드 작성을 위해 프로덕션 코드를 변경하는 것은 바람직하지 않으므로, 적용하지 않기로 했다.
• 회의를 통해 나눈 인사이트 :
  • 도메인 간 데이터가 마치 DDD의 Aggregate처럼 함께 묶여 움직이거나,
    반대로 완전히 의존이 분리된 구조 (e.g. 단순 ID 참조) 라면, 테스트 데이터 설정이 더 간결하고 명확해질 수 있겠다.