[42GG] 효율적인 TestFixture 관리

 
지난 회고에서 TestFixture에 대해 알게 되었고, 팀원들 모두 java-text-fixtures를 활용할 수있도록 gg-utils에 TestFixture를 생성하기로 결정했다.
 
추가적으로 현제 프로젝트에서 TestDataUtils라는 오직 하나의 클래스로 TestFixture를 모두 관리하고 있다는 문제점을 알게되었고, TestFixture 관련 논의에 이어서 추가적으로 어떻게 TestFixture를 효율적으로 관리할 수 있을지 논의했다.
 
먼저 현재 사용되고 있는 TestDataUtils의 가장 큰 문제점은 어떤 엔티티를 어디서 생성하는지, 즉 어떤 메서드가 존재하는지 파악하기 어렵다는 것이었다. 따라서 이를 해결하기 위해 먼저 TestDataUtils 분리해야한다.
 

gg-utils
├── build.gradle
└── src
    ├── main
    │   └── java
    │       └── gg
    │           └── utils
    │               ├── RedisKeyManager.java
    │               ├── dto
    │               └── exception
    └── testFixtures
        └── java
            └── gg
                └── utils
                    ├── AgendaTestDataUtils.java	# HERE!
                    ├── ItemTestUtils.java
                    ├── TestDataUtils.java
                    ├── annotation
                    ├── config
                    ├── dto
                    └── fixture		# HERE!
                        └── agenda
                            ├── AgendaAnnouncementFixture.java
                            ├── ...
                            └── AgendaFixture.java

 
결론적으로 각 Entity의 Fixture 클래스를 만들고, AgendaTestDataUtils에서는 여러가지 엔티티를 조합해서 생성하는 용도로 사용하기로 결정했다.
 
@BeforEach 등을 이용해서 setUp 메서드를 사용하는 것은 테스트 간의 결합도를 높인다는 단점이 있다고 한다. 또한 여러가지 상황에서 사용할 수 있는 메서드를 미리 구현해놓거나 모든 Test Fxitrue를 미리 생성해두는 방법도 생각해봤지만 너무 비효율적이라고 생각했다.
 
각 테스트마다 요구사항이 다르기 때문에 결국에는 각 테스트에 맞는 Fixture를 생성해야한다고 생각했다. 또한 개발 일정이 조금 촉박하기 때문에 이미 레거시로 남겨진 AgendaMockData와 TestDataUtils는 남겨두고, 기능 개발이 종료되면 추후에 리펙토링 하기로 결정했다.
 
추가로 Object Mother 패턴을 사용하여 Fixture를 Enum 타입으로 관리하는 방법이 있다는 것을 알게되었다. Fixture를 생성하는 구문의 중복을 제거하고 가독성이 좋아지게 때문에 인자값이 적고 동적으로 변경되는 경우가 적다면 고려해볼만 한 것 같다.
 

참고자료

 
테스트 픽스처 올바르게 사용하기

테스트 픽스처 올바르게 사용하기

테스트 픽스처(Test Fixture)를 어떻게 만드는 것이 좋은 걸까?

테스트 픽스처(Test Fixture)를 어떻게 만드는 것이 좋은 걸까?

테스트 픽스처를 만들 때 Object Mother 패턴을 도입해봤습니다. 근데 이제 Enum을 곁들인

테스트 픽스처를 만들 때 Object Mother 패턴을 도입해봤습니다.  근데 이제 Enum을 곁들인