[리팩토링] JUNIT5 테스트 코드 리팩토링하기 - @ParameterizedTest 와 @MethodSource 활용

🔍 리팩토링 전의 코드

프로젝트 중 테스트를 작성하면서, 기계적이고 반복적으로 하나의 패턴을 여러 상황별 테스트 메서드에 공통으로 사용하고 있음을 발견했다. 아래 두 코드 블럭들과 같이 모든 코드가 동일하고 ErrorCode 의 종류와 HTTP 상태를 나타내는 status() 만 차이가 있는 메서드들이 있었다. 기능 구현 메서드들을 작성할 때에는 템플릿 콜백 패턴과 같이 인터페이스를 활용해 중복을 제거하고 관심사를 분리할 수 있었는데, 테스트 코드에서는 한 번도 매개 변수를 가진 메서드를 정의해본 적이 없다는 단순한 이유로 하나의 메서드에서 작성한 코드를 ctrl+c, ctrl+v (복사 후 붙여넣기) 하여 다른 메서드에서 쓰는 비효율적인 프로그래밍을 했다. 리팩토링을 거쳐서 어떻게 중복을 줄이고 공통된 패턴을 분리했는지 알아보자.

@Test
@DisplayName("로그인 하지 않았거나 작성자와 현재 로그인된 유저가 일치하지 않아 포스트 수정에 실패한다.")
@WithMockUser
void fail_edit_post_inconsistent_user() throws Exception {

    given(postService.editPost(any(), eq(postId), any()))
        .willThrow(new UserException(ErrorCode.INVALID_PERMISSION, "사용자가 권한이 없습니다."));

    mockMvc.perform(put(editUrl).contentType(MediaType.APPLICATION_JSON)
        .content(objectMapper.writeValueAsBytes(editPostRequest))
        .with(csrf()))
        .andExpect(status().isUnauthorized())
        .andExpect(jsonPath("$.result.errorCode").value("INVALID_PERMISSION"))
        .andDo(print());

    verify(postService).editPost(any(), eq(postId), any());
}

@Test
@DisplayName("데이터베이스에서 수정할 포스트를 찾지 못하면 수정에 실패한다.")
@WithMockUser
void fail_edit_post_not_in_db() throws Exception {

    given(postService.editPost(any(), eq(postId), any()))
            .willThrow(new UserException(ErrorCode.DATABASE_ERROR, "DB 에러"));

    mockMvc.perform(put(editUrl).contentType(MediaType.APPLICATION_JSON)
            .content(objectMapper.writeValueAsBytes(editPostRequest))
            .with(csrf()))
            .andExpect(status().isInternalServerError())
            .andExpect(jsonPath("$.result.errorCode").value("DATABASE_ERROR"))
            .andDo(print());

    verify(postService).editPost(any(), eq(postId), any());
}

🔨 @ParameterizedTest 와 @MethodSource 를 활용한 리팩토링

우선 사용한 어노테이션은 다음과 같다:

• @ParameterizedTest : 매개 변수가 있는 테스트 메서드에 붙이는 어노테이션.
• @MethodSource : @ParameterizedTest는 다양한 Source (출처) 로부터 메서드에 사용되는 매개변수를 불러온다.
  • @EnumSource : enum 타입 클래스의 상수 변수들을 매개 변수로 활용하고자 할 때 사용되는 어노테이션.
  • @NullSource, @EmptySource : 각각 null 값, 빈 값 (문자열, Collection, 배열만 해당) 을 활용하고자 할 때 사용.
  • @CsvSource : 쉼표로 분리된 값을 써서 여러 매개 변수를 지정하는 어노테이션.
  • @ValueSource : 하나의 매개 변수를 지정할 때 사용하는 어노테이션.
    @MethodSource 는 복잡한 객체들이 매개 변수일 때, 매개 변수를 지정하는 메서드 하나를 생성하여 활용하는 어노테이션이다.
• 간단히 소개하면, @MethodSource 외에도 아래와 같은 Source 들이 있다:

그래서, 아래와 같이 메서드 위에 두 개의 어노테이션을 붙이고, @MethodSource 에는 어떤 메서드를 참조할 것인지 명시했다.

@ParameterizedTest
@DisplayName("데이터베이스에서 수정할 포스트를 찾지 못하면 수정에 실패한다.")
@WithMockUser
@MethodSource("provideErrorCase")
void fail_edit_post_not_in_db(ErrorCode errorCode, ResultMatcher isError) throws Exception {

    given(postService.editPost(any(), eq(postId), any()))
            .willThrow(new UserException(errorCode, errorCode.getMessage()));

    mockMvc.perform(put(editUrl).contentType(MediaType.APPLICATION_JSON)
            .content(objectMapper.writeValueAsBytes(editPostRequest))
            .with(csrf()))
            .andExpect(isError)
            .andExpect(jsonPath("$.result.errorCode").value(errorCode.name()))
            .andDo(print());

    verify(postService).editPost(any(), eq(postId), any());
}

@MethodSource 에서 사용한 메서드는 아래와 같다:

private static Stream<Arguments> provideErrorCase() {
    return Stream.of(Arguments.of(ErrorCode.INVALID_PERMISSION, status().isUnauthorized()),
            Arguments.of(ErrorCode.DATABASE_ERROR, status().isInternalServerError()));
}

반환 타입이 Stream<Arguments> 로 되어 있다. provideErrorCase() 는 Stream 형태로 매개 변수, Arguments 들을 묶어서 반환한다. 위의 중복된 패턴을 가지고 있는 두 코드는 각각 INVALID_PERMISSION 에러와 DATABASE_ERROR 에러에 대한 처리를 테스트하는 코드였다. 매개 변수로 사용될 ErrorCode 와 status() 를 Stream 형태로 묶어서 지정해준 것을 볼 수 있다.

🧶 문제 발생과 해결

여러 메서드를 하나로 묶다 보면, 컨트롤러 테스트의 특성 상 하나의 API 에서는 Mock 객체 Service 를 사용하지만, 다른 하나의 API 에서는 사용하지 않는 경우가 있음에도 패턴이 겹치는 이유로 묶는 상황이 발생한다. 즉, 테스트 대상 API 에서 사용되지 않으면서 동작이 정의된 객체가 있는 것이다. 이 때에는 unnecessary stubbing 에러가 발생한다. 해결을 위해 구글링을 한 결과, 두 가지의 방법이 있음을 알게 되었다. 하나는 Mockito 의 스태틱 메서드를 활용하는 것이고, 다른 하나는 어노테이션을 활용하는 방법이다. 나는 어떤 특정 상황에서 불필요하게 Mock 객체의 동작을 정의 (stubbing) 을 하고 있는지 알고 있어서, 알고 있는 위치에서 동작을 정의하는 줄에 메서드를 추가하였다:

Mockito.lenient().when(postRepository.findById(mockPost.getId())).thenReturn(optionalPost);

Mockito.lenient().when(userRepository.findByUserName(mockPost.getAuthor().getUserName())).thenReturn(optionalUser);

💡 한 번 더 리팩토링: enum 타입 클래스 활용

이후 많은 양의 변수들이 하드 코딩 된 모습이 지저분해서 PostTestEssentials enum 타입 클래스를 생성했다. 다양한 상수 변수들을 클래스 내부에 추가한 뒤, 롬복을 사용해 각 변수의 값을 @Getter 메서드를 활용해 가져오게 했다.

자주 사용되는 문자열 값을 담은 상수 변수들을 모아 두었다.

+ 롬복을 test 디렉토리 하위 클래스들에서도 사용할 수 있도록 build.gradle 에 의존성을 추가해주었다:

📌 출처

https://stackoverflow.com/questions/42947613/how-to-resolve-unneccessary-stubbing-exception

How to resolve Unneccessary Stubbing exception

https://www.baeldung.com/parameterized-tests-junit-5