으어어어어
729
2020-06-23 19:00:03
4
356

테스트 코드를 깔끔이 유지하는 방법에 대한 질문입니다.


테스트 코드를 짜다보면 해당 테스트 케이스에서 사용해야할 데이터, 혹은 테스트를 수행하기 위한 환경이나 선행되어야 하는 조건을 만족시키기 위해 Mockito 등을 이용하여 가짜 객체를 만드는데, 이런것들이 쌓이다 보면 코드도 길어지고 보기 싫어집니다.


그래서 테스트 데이터와 Mockito를 이용하여 가짜 객체를 만드는 헬퍼 클래스를 만든다거나, 추상 클래스를 만들어 추상 클래스에 테스트 데이터등을 모은 후 추상 클래스를 상속받아 사용하거나 해봤지만, 코드 자체는 짧아지고 깔끔해진것 처럼 보이지만 테스트에 대해 명확히 하는 느낌은 없는거 같습니다.


혹시 여러분은 테스트 데이터나 테스트를 위한 환경을 만드는 작업등을 어떤식으로 관리 하시고 계시나요? 도움을 주시면 감사하겠습니다.

0
  • 답변 4

  • devcrema
    1k
    2020-06-23 22:40:26

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

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

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

  • 으어어어어
    729
    2020-06-23 23:25:46

    devcrema

    답변 감사드립니다.


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



  • devcrema
    1k
    2020-06-25 21:02:37

    클래스명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{...}

  • 으어어어어
    729
    2020-06-25 21:27:29

    devcrema


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

  • 로그인을 하시면 답변 을 등록할 수 있습니다.