[제안] Test Fixture를 이용해 기존 테스트 코드의 복잡도 개선

[EunjiShin]

💁‍♀️ 제안 사항

• Test 세팅 컴포넌트를 만들어 테스트할 때 매번 직접 의존성을 주입하고 Test Double(Fake)을 생성하는 번거로움을 개선해요.
  • DI container :: 스프링 IoC/DI를 대체해주는 컴포넌트
  • Data Factory :: 더미 데이터 생성을 위한 팩토리

👀 제안 이유

• 테스트에서 직접 DB call을 하면, 테스트 속도도 느려지고 제어하기도 어려워져요.
• 이런 문제를 개선하기 위해 DIP를 활용, FakeRepository 등을 만들어 테스트를 진행했어요.
• 이랬더니 속도는 빨라졌지만, 아래의 문제가 생겼어요.
  • Service가 많아질수록, Repository 메서드가 많아질수록 Fake 생성 비용 & 유지관리 비용이 커져요.
  • 테스트 코드 안에 Fake 생성 로직이 섞여, 가독성이 떨어져요. 테스트 코드보다 init 코드가 더 김! 😇
  • @beforeeach 에서 FakeRepository를 만들고 데이터를 저장하므로, 테스트 클래스마다 더미 데이터 생성 과정이 필요해요.
• Test Fixture를 이용해 위 문제를 해결하고자 해요.
  • DIContainer를 구현해 테스트가 올라갈 때 필요한 의존성을 모두 주입
  • Data Factory(e.g., ReviewFactory)를 이용해 Fake 생성 비용 절감

✅ 참고 사항

• 지금 테스트가 많이 없어 속도 이슈가 없는데도 DB call을 피하는 이유

  • 테스트 속도가 느려서 빌드에 이슈가 생길 정도라면, 이미 겉잡을 수 없는 상황이 아닐까 해요.
    • 그때는 테스트가 엄청 쌓였을 텐데, 그 테스트들을 하나하나 개선하는 건 너무 괴로울 것 같아요 🔫
  • 현재의 고통과 미래의 고통의 트레이드 오프인데, 한 번에 크게 앓는 것보단 작게 쫌쫌따리 앓는게 좋겠다고 생각했어요 🤔

• TestFixture를 쓰면 테스트간의 독립성이 사라지는 것 아닌지?

  • DIcontainer는 단순 의존성 주입이니까 논외! Factory에 한해서 주의할 필요가 있다고 생각해요.
    • @beforeeach와는 다르게 더미데이터 양식을 같은 클래스 내에서 확인할 수 없으니 번거로워질 수도 있구요.
    • 이런 문제를 개선하기 위해, Factory method를 사용하려고 해요.
      • Factory가 정해진 더미데이터를 자동으로 생성 (a.k.a data.sql)

        List<Review> reviews = reviewFactory.createAll();
        

      • Factory는 method를 통해 매개변수 기반으로 더미데이터 생성

        // 단순 예시 입니당. 이렇게 하겠다는 것 X
        // 1~10 범위의 리뷰 데이터를 순차적으로 생성. string에 들어갈 값들은 "review"로 통일 
        List<Review> reviews = reviewFactory.createAll(1, 10, "review");
        

✍️ 적용한다면 언제?

1차 MVP 끝나고 테스트를 거쳐 도입해보려고 해요.