mock이던 stub이던 가짜 객체들이 쌓이면 보기 싫어지는 가장 큰 이유는 그 가짜 객체들이 도메인 시나리오를 반영하지 못하고 있기 때문일 가능성이 높습니다.

한곳에 다 몰아넣기보다는 테스트 시나리오에 맞게 네이밍을 적절하게 하고 도메인별로 구분하여 픽스처를 구성하시면 픽스처 자체만으로도 일종의 시나리오를 문서화한 느낌을 어느정도는 줄 수 있습니다.

만약 애플리케이션이 도메인에 맞게 이미 분리가 되어 있다면 aggregate root만 픽스처를 만드셔도 좋습니다. 그렇게 되면 테스트 픽스처가 어느정도 이상 커지지 않아 복잡성을 조절할 수 있습니다.

devcrema

답변 감사드립니다.

제가 이해한 것으로 예를들면 클래스명Test.class 가 아닌 시나리오명.class 등으로 테스트 클래스를 만들고 그 클래스에 해당 시나리오에 대한 테스트를 구성한다.  라고 생각을 하는데, 혹시 말씀하신거랑 비슷하신건지 답변해 주실 수 있으시나요?

클래스명Test.java는 두되 별도로 테스트 데이터를 위한 fixture class를 만드는 게 좋다고 생각합니다.

클래스별로 테스트를 만들면 이점이 해당 테스트 복잡도가 높아지면 자연스럽게 객체의 역할을 분리할 수 있거든요.

거기에 저는 보통 테스트 객체 종류에 따라 도메인 엔티티명Stub.java와 같이 환경을 구성합니다.

예를들어 OrderMenuService라는 객체의 테스트를 만든다고 하면 아래와 같이 구성합니다.

popularMenu라는 이름만으로도 인기메뉴를 위한 테스트 객체를 표시할 수 있고 중복코드를 한곳에 넣어둘 수 있습니다.

class OrderMenuServiceTest {

  ..

  fun testOrderMenu(){

    // given

    val menu = repository.save(MenuStub.popularMenu)

    // when

    val popularMenu = orderMenuService.orderPopularMenu()

   // then

    assertEquals(menu, popularMenu)

  }

  ..

}

class MenuStub{...}

devcrema

답변 감사드립니다. 큰 도움이 되었어요.