[JUnit5] @WithMockUser에서 username이 의도대로 작동 안 함

SecurityContextHolder에서 유저 정보를 가져오며 테스트 중 겪었던 작은 문제와 그에 대한 대처를 이야기하고자 한다.
같은 경험을 했거나 더 좋은 경험이 있다면 댓글로 ✍️ 🙏 

 

SecurityContextHolder에서 유저 정보를 효율적으로 가져오기

첫 번째 문제 상황

진행하던 프로젝트에서 Spring Security의 `SecurityContextHolder`를 사용해 로그인한 유저의 정보를 가져와야 하는 상황이 생겼다. 흔히 많은 예제에서 username 필드로 email을 사용해서 우선 처음에는 email로 세팅했다. 여기서 작은 문제가 생겼다.

 

user와 연결된 다른 많은 테이블들이 있었고, 이 테이블들과 join을 할 때마다 email로 먼저 유저 정보를 조회하고, 그 후 user의 id값으로 다시 join을 해야 했다. 이렇게 되면 매번 조회가 두 번이나 발생하게 되는데, 이는 효율성 면에서 좋지 않다고 생각했다.

 

개선 방향

이 문제를 해결하기 위해 `SecurityContextHolder`에 저장되는 값으로 email대신 user의 id값을 저장하기로 결정했다. 이렇게 하면 user와 연결된 다른 테이블을 조회할 때 email로 중간 조회 없이 바로 id값으로 join을 할 수 있게 된다.

---

JUnit5와 MySQL의 Auto Increment: 테스트의 함정

두 번째 문제 상황

JUnit5를 이용한 단위 테스트 중 `@WithMockUser(username = "1", roles = "USER") 어노테이션을 사용하여 mock 유저를 생성하며 테스트를 하고 있었다. 그런데 위의 이유 때문에 username을 MySQL의 Auto Increment 값인 id로 세팅하면서 문제가 생겼다.

// 실패한 테스트 케이스

/** 비즈니스 로직 **/
public MissionResponse createMission(MissionCreateServiceRequest request) {
    int userId = securityService.getCurrentUserInfo().getUserId();
    User user = userReadService.findByOne(userId);

    Mission mission = request.toEntity(user);
    Mission savedMission = missionRepository.save(mission);

    return MissionResponse.of(savedMission);
}
    
/** 테스트 로직 **/
@DisplayName("미션 내용들을 받아 미션을 생성한다.")
@Test
@WithMockUser(username = "1", roles = "USER")
void createMission() {
    // given
    User user = createUser("user@daum.net", "user1234!", SnsType.KAKAO, "010-1111-1111");
    Mission mission = createMission(user, "운동하기", CHECKED, LocalTime.of(0, 0));
    missionRepository.save(mission);

    MissionCreateServiceRequest request = MissionCreateServiceRequest.builder()
        .missionDescription("책 읽기")
        .alertStatus(CHECKED)
        .alertTime(LocalTime.of(23, 30))
        .build();

    // when
    MissionResponse missionResponse = missionService.createMission(request);

    // then
    assertThat(missionResponse)
        .extracting("missionDescription", "alertStatus", "alertTime")
        .contains("책 읽기", CHECKED, LocalTime.of(23, 30));

    List<Mission> missions = missionRepository.findAll();
    assertThat(missions).hasSize(2)
        .extracting("missionDescription", "alertStatus", "alertTime")
        .containsExactlyInAnyOrder(
            tuple("운동하기", CHECKED, LocalTime.of(0, 0)),
            tuple("책 읽기", CHECKED, LocalTime.of(23, 30))
        );
}

이렇게 미션을 생성하는 테스트가 있는데, 테스트 자체를 개별적으로 실행했을 때는 아무런 문제가 발생하지 않았다. 그러나 테스트의 수가 늘어나며 user 데이터 생성 및 클렌징 로직이 추가되면서 테스트 실패의 문제가 발생하기 시작했다. 이는 단위 테스트의 기본 원칙 중 하나인 '테스트는 독립적으로 동작해야 한다'는 원칙을 위배하고 있는 문제였다.

 

문제의 원인을 파악하기 위해 디버깅을 진행했다. 우선 테스트는 실행 순서를 보장하지 않는다. 첫 번째 실행된 테스트에서 생성된 user의 id값은 1이었고, 이후 실행되는 테스트에서는 `deleteAllInBatch()`를 통해 데이터를 클렌징하는 과정을 거쳤다. 초기에는 이 클렌징 과정으로 인해 AI값이 1로 초기화된다고 생각했으나, 실제로는 그렇지 않았던 것 같다. 그래서 이후 테스트에서 예측하지 못하는 id값이 부여되었다. 결과적으로 id값은 우리가 직접 제어할 수 없는 영역으로 들어가게 되었다.

 

실패한 개선 방향

처음에는 1차원적으로 "그러면 SecurityContextHolder에 UserInfo라는 객체로 email이랑 id를 둘 다 넣어야겠다"라고 생각했다. 왜냐하면 테스트에서 email은 내가 직접 넣어줄 수 있고 유니크하기 때문에 적합하다고 생각했고 예제에서는 "그래서 다 email을 넣었던 건가?"라고 생각했다.

@Service
public class SecurityService {

    public UserInfo getCurrentUserInfo() {
        Object principal = SecurityContextHolder.getContext().getAuthentication().getPrincipal();

        if (principal instanceof UserInfo) {
            return (UserInfo) principal;
        }

        throw new RuntimeException("Unknown principal type: " + principal.getClass().getName());
    }
}

 

그리고는 테스트에서는 어노테이션을 하나 만들어서 우리만의 WithMockUser를 재정의 했다. 

@Retention(RetentionPolicy.RUNTIME)
@WithSecurityContext(factory = WithMockUserInfoSecurityContextFactory.class)
public @interface WithMockUserInfo {
    int userId() default 1;

    String email() default "email@gamil.com";

    String role() default "USER";

}

public class WithMockUserInfoSecurityContextFactory implements WithSecurityContextFactory<WithMockUserInfo> {
    @Override
    public SecurityContext createSecurityContext(WithMockUserInfo annotation) {
        final SecurityContext securityContext = SecurityContextHolder.createEmptyContext();
        UserInfo userInfo = UserInfo.of(annotation.userId(), annotation.email());

        final UsernamePasswordAuthenticationToken authenticationToken = new UsernamePasswordAuthenticationToken(
            userInfo,
            "",
            List.of(new SimpleGrantedAuthority(annotation.role()))
        );

        securityContext.setAuthentication(authenticationToken);
        return securityContext;
    }
}

 

어노테이션을 바꾼 테스트

@DisplayName("미션 내용들을 받아 미션을 생성한다.")
@Test
@WithMockUserInfo(userId = 1, email = "user@daum.net")
void createMission() {
    // given
    User user = createUser("user@daum.net", "user1234!", SnsType.KAKAO, "010-1111-1111");
    Mission mission = createMission(user, "운동하기", CHECKED, LocalTime.of(0, 0));
    missionRepository.save(mission);

    MissionCreateServiceRequest request = MissionCreateServiceRequest.builder()
        .missionDescription("책 읽기")
        .alertStatus(CHECKED)
        .alertTime(LocalTime.of(23, 30))
        .build();

    // when
    MissionResponse missionResponse = missionService.createMission(request);

    // then
    assertThat(missionResponse)
        .extracting("missionDescription", "alertStatus", "alertTime")
        .contains("책 읽기", CHECKED, LocalTime.of(23, 30));

    List<Mission> missions = missionRepository.findAll();
    assertThat(missions).hasSize(2)
        .extracting("missionDescription", "alertStatus", "alertTime")
        .containsExactlyInAnyOrder(
            tuple("운동하기", CHECKED, LocalTime.of(0, 0)),
            tuple("책 읽기", CHECKED, LocalTime.of(23, 30))
        );
}

이렇게 하면 되겠다고 생각했는데 이건 너무 1차원적인 생각이라는 것을 다 바꾸고 깨달았다.. 애초에 이게 됐으면 처음에 (username = "1")도 됐어야 했다. 그리고 비즈니스 로직에서 email을 쓰지 않고 있어서 email을 추가할 필요도 없었던 것 같다.

---

테스트하기 어려운 영역을 분리하자 !

다른 접근의 개선 방향

우빈님의 테스트 강의에서 "테스트하기 어려운 영역을 분리하자"라는 말이 생각나서 적용해 봤다.

public MissionResponse createMission(MissionCreateServiceRequest request, int userId) {
    User user = userReadService.findByOne(userId);

    Mission mission = request.toEntity(user);
    Mission savedMission = missionRepository.save(mission);

    return MissionResponse.of(savedMission);
}

이렇게 테스트하기 까다로웠던 userId를 외부로 분리했다.

그에 맞게 컨트롤러 테스트(Presentation Layer 테스트)도 수정했다.

@DisplayName("신규 미션을 등록한다.")
@Test
@WithMockUser(roles = "USER")
void createMission() throws Exception {
    // given
    MissionCreateRequest request = MissionCreateRequest.builder()
        .missionDescription("운동하기")
        .alertStatus(CHECKED)
        .alertTime(LocalTime.of(18, 30))
        .build();

    given(securityService.getCurrentUserInfo())
        .willReturn(createUserInfo());

    // when // then
    mockMvc.perform(
            post("/api/v1/missions/new")
                .content(objectMapper.writeValueAsString(request))
                .contentType(APPLICATION_JSON)
                .with(csrf())
        )
        .andDo(print())
        .andExpect(status().isCreated())
        .andExpect(jsonPath("$.statusCode").value("201"))
        .andExpect(jsonPath("$.httpStatus").value("CREATED"))
        .andExpect(jsonPath("$.message").value("CREATED"));
}

...

private UserInfo createUserInfo() {
    return UserInfo.builder()
        .userId(1)
        .email("")
        .build();
}

• BDDMockito의 given을 이용해서 userId를 mocking해서 제어가능하게 만들었다.
• 그래서 더이상 재정의한 어노테이션을 사용할 필요가 없어졌다.

 

느낀 점

초반에 단위 테스트를 진행하면서 `@WithMockUser` 어노테이션의 필요성과 동작 방식에 대한 이해가 완전하지 않았던 것 같다. 실제로 서비스 레벨의 단위테스트에서는 `@WithMockUser`를 사용할 필요가 없으며, 해당 어노테이션은 그렇게 적용되지도 않았다.

 

이전에 테스트를 공부할 때, "테스트하기 어려운 영역을 분리하자"라는 말이 조금 추상적이고 이해가 잘 안 됐었는데 이번 케이스를 통해 그 개념에 대해 되돌아볼 수 있는 기회가 되었다. 실제 프로젝트의 경험은 때때로 이론적인 지식을 명확하게 해주는 좋은 리마인더가 될 때가 많다.

 

 

 

언제나 잘못된 설명이나 부족한 부분에 대한 피드백은 환영입니다🤍