Service 단 Test Code 작성 요령

Question

안녕하세요~ 예전에 TC 를 작성하면서 발생한 궁금점들이 이번 강의를 통해서 다시 한번 생기게 되어서 질문 올리게 되었습니다!!

UserSerivce 를 Test 하기 위해 UserRepository 모킹주입을 하였습니다. 이 때, stub 을 사용하여 모킹 객체의 동작을 정의해주는데, 제가 예전에 이렇게 했을 때
(강의 예제와 같은) UserRepository 의 동작을 일괄적으로 관리하기 위해 @BeforeEach 를 사용하였습니다. |
이렇게 했더니 실제로 많은 일을 수행하는 Repository 에 들어가는 when 절이 정말 많아지고 BeforeEach 가 매우 길어져서(필요한 연관 객체들 User 와 연관된 A,B,C 등의 Entity 모두 그 때 그 때 생성해주는 코드까지 다 결합되어 있었음),
이게 과연 맞는가? 싶은 생각이 들었습니다.
해당 강의를 통해서 그냥 그렇게 하는게 맞았었나보네 싶은데 , 보통 그렇게 BeforeEach 혹은 각 TC 코드가 길어져도 이렇게 Test 하는게 관례적인 모습일까요?

그간 물어볼 사람이 없어서 못 물어봤는데 이렇게 질문드릴 수 있게 되어서 다행입니다 ㅠ

최주호 · Answer

그래서 저는 서비스 테스트 시에, 단순히 서비스 내부에 로직만 테스트합니다. 강의 계속 보시다 보면, stub에 대한 내용이 나올 것입니다. stub이 필요하긴 하나, DB에서 조회되는 모든 stub을 작성하는 것 또한 굉장히 많은 일이 들게 됩니다.

인프런 AI 인턴 · Answer

안녕하세요, 인프런 AI 인턴이에요. 당신이 작성한 Test 코드에 대한 궁금점에 대해 답변드리겠습니다. @BeforeEach를 사용하여 UserRepository의 동작을 일괄적으로 관리하는 방법은 일반적으로 많이 사용되는 방법이에요. 이렇게 하면 각각의 테스트 케이스마다 UserRepository를 생성하고 설정하는 번거로움을 줄일 수 있습니다. 따라서, 각 TC 코드마다 UserRepository의 설정을 일일이 작성하는 것보다는 코드를 간결하게 유지할 수 있게 됩니다. 하지만, 많은 연관 객체들이 UserRepository에서 사용되는 경우에는 @BeforeEach가 길어질 수 있다는 점을 인지하셨군요. 이런 상황에선 @BeforeEach에서 생성되고 설정되는 연관 객체들의 코드도 포함하게 되므로, @BeforeEach가 복잡해질 수 있습니다. 이러한 상황에서 고려할 수 있는 방법은 테스트 데이터를 미리 생성하는 Fixture를 사용하는 것입니다. 테스트 데이터를 미리 생성해두면 @BeforeEach 코드에서 생성하는 로직을 테스트 데이터로 대체할 수 있어서, 코드를 간결하게 유지할 수 있습니다. 또한, 모킹한 객체의 동작을 설정하는 부분에서 when 문이 많아진다고 말씀하셨는데, 이 역시 효율적인 관리가 필요할 수 있습니다. 핵심 동작들을 잘 분리하고, 동작 설정을 한 곳에서 일괄적으로 처리하게 될 경우 코드의 가독성을 높히고 유지보수도 용이해집니다. 결론적으로, 일괄적으로 관리되는 테스트 코드와 관련된 객체들은 @BeforeEach를 사용하여 생성하는 것이 일반적이지만, 코드가 복잡해지는 상황이라면 테스트 데이터 Fixture를 사용한다거나, 동작 설정을 한 곳에서 관리하는 등의 방법을 고려해볼 수 있습니다. 더 궁금한 사항이 있으시면 언제든지 질문해주세요! 이번에도 도움이 되었기를 바랄게요. 좋은 하루 되세요!