회원: Controller 파라미터 인터페이스 및 Test 클래스 지원 인터페이스 지원 내용 및 사용법

[parksey]

회원 인터페이스 제공

회원을 사용하면서 필요한 빠른 개발과 편의성을 위해 인터페이스를 제공하고자 했습니다.

또한, 테스트에서도 어노테이션만 추가하시면 기존 테스트 코드에서 특별한 추가 없이 사용할 수 있습니다.

Overview

main source에는 @Auth AuthMember(이하 사용자 정보 어노테이션이라 한다.)을 사용하면 사용자의 ID, nickname 값을 사용할 수 있습니다.

또한, 각각의 controller test에 테스트에 대한 전반적인 변경 사항을 적용 시켜 놓았습니다.
ItemControllerTest에는 하나의 예시로 모두 적용하여 넣어 놓았으니 참고하시면 됩니다.

WithoutFilterSupporter클래스는 현재 작성된 모든 controller 테스트 코드에 적용하였으니 그대로 사용하면 되고, 추가로 Controller 테스트 클래스를 생성한다면 넣어주시면 됩니다.
이제 주의 점으로는 각 테스트 메서드를 작성하실 때 @WithMember만 추가해주시면 Controller에 작성된 사용자 정보 어노테이션에 값이 자동으로 바인딩이 됩니다.

회원 어노테이션 추가 (Source)

Usecase

@GetMapping("/test")
public void test(@Auth AuthMember authMember) {

}

• @Auth 와 AuthMember 를 같이 사용해야 받아올 수 있습니다.
• 사용자 정보 어노테이션은 파라미터에만 있으면 자동으로 값이 바인딩이 됩니다. 다만, 다른 곳에서 작성하신다면 값을 넣을 수 없습니다.
• 현재 AuthMember의 값은 AuthorizationThreadLocal에 존재하는데, 해당 값은 전항에 따라 따로 꺼낼 필요 없습니다.

Filter 기능 추가 (Source)

Usecase

@Bean
public PathResolver pathResolver() {
	PathResolver.Paths path = PathResolver.Paths.builder()
		.permitOne(
			PathResolver.Path.builder()
				.uri("/members")
				.build()
			)
		.permitOne(
			PathResolver.Path.builder()
				.uri("/members/login/*/oauth")
				.build()
			)
		.build();
		return new PathResolver(path);
	}

• WebConfig.java파일에 만약 filter를 건너뛰고 싶은 기능이 있다면 해당 pathResolver에 추가해주시면 됩니다.
• 즉, 위 기능은 API 중 인증 작업이 필요 없는 경우에 사용할 수 있습니다.
• 위 PathResolver에 path를 추가하게 된다면, 이후 해당 uri로 들어오는 값 들은 전부 filter를 거치지 않습니다.

---

[추가]

Path (Source)

기본적으로 모든 path는 필터를 거치게 하였습니다 따라서 uri 접근을 인증 없이 허용하고자 하면 permitAll이나 permitOne을 넣어야 합니다.

authentication또한 존재하는데, 추후에 admin과 같은 다른 인증 작업에 사용될 예정입니다.

Path.builder()
	.uri()
	.httpMethods()
	.httpMethod()
	.roles()
	.role()
	.build()

• uri: 적용하고자 하는 uri, Ex) "/members"
• httpMethods: 적용하고자 하는 HttpMethod
  • httpMethod: 하나의 메소드를 추가하고자 하면 httpMethods, httpMethod 둘 다 사용 가능
  • 설정 안 하면, 기본적으로 GET, POST, PUT, PATCH, DELETE 제공
• roles: 적용하고자 하는 Role
  • role: 하나의 role을 추가하고자 하면 roles, role 둘 다 사용 가능

Paths (Source)

위 Path를 관리하는 PathReslver와 연결해주는 클래스입니다.

PathResolver.Paths path = PathResolver.Paths.builder()
	.permitAll()
	.permitOne()
	.authentications()
	.authentication()
	.build();

• permitAll: 전체를 적용하고자 할 때 사용합니다.
• permitOne: 하나의 path에 대해서만 적용하고자 할 때 사용
• authentications & authentication: 추가 인증을 적용하고자 하는 작업에 사용예정

Supporter 클래스 (Test)

아래 클래스들은 테스트의 편의성을 위해 제공해드립니다.
이후, 모든 테스트 코드에서 헤더 or 쿠키에 인증 관련 토큰이나 값을 전달하지 않고 진행할 수 있습니다.

@WithMember (Test)

회원 어노테이션 클래스입니다. 이전에는 Filter에서 인증 작업을 진행한 후 인가 작업을 진행했지만, 통합 테스트에서 Filter를 제외하면서 따로 인가 작업을 넣어줘야 했는데, 위 @WithMember의 경우 자동으로 값을 넣어주는 역할을 진행하게 됩니다.
따라서 *Controller테스트를 진행하면서 ThreadLocal에 AuthorizationMember에 대한 값을 자동으로 저장하기 위한 어노테이션입니다.

위 기능을 통해, 테스트 메서드마다 ThreadLocal에 인가 정보를 넣어주고 mockMvc에서 controller의 파라미터로 값을 넣어주지 않아도 됩니다.

@WithMember를 사용할 때는 @ExtendWith(FilterProcessExtension.class)를 추가해주셔야 합니다.

Usecase

@WithMember
@Test
void only_withMember() {
	// given
	AuthMember authMember = AuthorizationThreadLocal.getAuthorizationMember();
}

@WithMember(id = 1, nickname = "PARK", role = Role.ADMIN)
@Test
void customizing_withMember() {
	// given
	AuthMember authMember = AuthorizationThreadLocal.getAuthorizationMember();
}

@DisplayName("")
@ParameterizedTest
@CsvSource({"string, 1"})
void with_parameter(String s, int b, @WithMember AuthMember authorizationMember) {
}

@DisplayName("")
@ParameterizedTest
@ValueSource(ints = {1, 2, 3})
void with_paramter_value_source(int b, @WithMember AuthMember authorizationMember) {
}

• @WithMember를 사용 가능하며, 값을 가지고 올 수 있습니다.
  • 정보 가져오기 : AuthorizationThreadLocal.getAuthorizationMember();
  • 파라미터로 가져오기 : @WithMember AuthMember
• 파라미터 사용 시 주의 점:
  • 파라미터에서 단일로 사용할 때는 상관 없음
  • 여러 파라미터를 같이 사용할 경우 마지막에 위치해야 합니다.

AuthorizationMember를 가지고 오지 않아도 사용 가능합니다.

AuthorizationMember를 json으로 변환하여 따로 넣지는 않았습니다.

Controller에서는 위와 같이 넣어주시고

테스트를 진행하면 위와 같이 값이 자동으로 바인딩이 됩니다.

Filter 적용 Support 클래스 (Test)

WithoutFilterSupporter, WithFilterSupporter 두 개의 클래스를 제공합니다.

제공 목적

통합 테스트에서 테스트를 진행할 때 Filter를 적용시키지 않고 테스트를 진행하거나 Filter를 포함한 통합테스트를 진행할 수 있도록 지원해주는 클래스입니다.
아마 WithoutFilterSupporter만 사용하시면 될 것 같습니다.

테스트 지원 클래스인 만큼 하나의 @SpringBootTest어노테이션과 @WebMvcTest어노테이션을 커스터마이징하여 processor를 만들어 하나의 어노테이션으로 모든 것이 되도록 지원할 예정이었나, 생각보다 코드가 방대해져서 @WithMember + WithoutFilterSupporter로 분할하여 제공해 드리는 점 양해 부탁 드립니다.

(재윤님이 말씀해주셨던 Test클래스에서 @SpringBootTest와 @WebMvcTest등이 보이지 않는 거에 대한 가독성 및 테스트 명확성 등에 대한 피드백 감사합니다!)

WithoutFilterSupporter

@WebMvcTest(controllers = ProductController.class)
class ProductControllerTest extends WithoutFilterSupporter {

• @WebMvcTest or @SpringBootTest어떤 걸 사용해도 상관 없습니다.
• WithoutFilterSupporter만 적용 시켜주면 됩니다.
• 이러면 Filter가 제외되게 되며, Controller에서사용자 정보 어노테이션에 값이 바인딩되기 위해서는 @WithMember를 추가해주셔야 합니다.

WithFilterSupporter

아마 사용하지 않을 거 같아서 자세하게 작성하지는 않겠습니다.

class ProductControllerTest extends WithFilterSupporter {

• WithFilterSupporter의 경우 @SpringBootTest를 같이 제공해주다 보니 따로 사용하면 안됩니다.
• 또한 MockMvc도 제공해 주므로 해당 MockMvc를 사용하셔야 합니다.

다시 한 번 강조

테스트에서 Filter없이 사용하여 통합 테스트를 할 경우

@WebMvcTest(controllers = ProductController.class)
class ProductControllerTest extends WithoutFilterSupporter{
    @Test
    @WithMember
    void test() {
    
    }
}

와 같이 WithoutFilterSupporter를 통해 filter를 없애고, @WithMember를 통해 Controller에 작성된 사용자 정보 어노테이션에 값이 자동으로 바인딩되게 됩니다.

@WithMember vs @CurrentMember

@WithMember의 경우 필터를 적용시키지 않는 테스트 코드에서 ThreadLcoal에 값을 넣어주는 역할을 자동으로 해주게 됩니다.
해당 어노테이션을 사용하면 테스트 코드에서 mockMvc에 AuthorizationMember에 대한 코드를 작성할 필요가 없게 됩니다.

@Auth 의 경우 Main source에서만 사용하면 됩니다.
위 기능은 Controller의 파라미터에 사용자 정보 어노테이션을 작성하게 되면 ThreadLocal에서 저장했던 인가 정보(ID, nickname)를 받겠다는 하나의 확인용 어노테이션이라고 생각하면 될 거 같습니다.
참고로, 인가 정보를 받기 위해서는 @CurrentMember와 AuthorizationMember 둘 다 필요합니다.

따라서 @WithMember와 @AuthMember둘 다 사용하는 의도가 유사할 수 있으나 다릅니다.

마무리

추가 적인 질문 사항이나 변경 요청 사항은 아래에 작성해주시면 될 거 같습니다.

사실 이렇게만 제공하려 했다면 좀 더 일찍 끝낼 수 있었는데, 어노테이션 하나에 집착하여 Processor를 시도하다 보니 조금 늦어진 점 죄송합니다.

[hongdosan]

1. 컨트롤러에 바인딩된다는 말이 많은데, 주어가 없어서 잘 이해가 가지 않습니다ㅠ @WithMember를 쓰면 인증된 사용자가 컨트롤러에 바인딩된다는 말인가요?!
2. 컨트롤러에 바인딩된다는 말이 스레드로컬에 인증된 사용자가 저장되고 스레드로컬에서 꺼내쓰면 된다는 말인가요??!
3. @WithMember와 @CurrentMember 차이가 궁금합니다..!
4. 인가 필터를 거치지 않고 싶은 API가 있다면, 직접 WebConfig에 추가하면 된다는 말로 이해하면 될까요?
5. WithFilterSupprter는 필터를 적용시키는 클래스라고 하셨는데, 사실 해당 필터를 상속받지 않아도, 통합테스트인 경우엔 이미 설정된 필터들이 적용될텐데 따로 만들어둔 이유가 궁금합니다!

[parksey]

1. 바인딩이 된다는 것은?

@WithMember는 테스트 코드에서 사용하는 어노테이션입니다.
@CurrentMember Authorization에 사용자 정보(ID, nickname)값을 바인딩 해줘야 하고, 이 바인딩을 위한 값은 ThreadLocal에 존재하게 됩니다. 하지만 ThreadLocal에 값을 넣는 과정은 Filter에서 진행하게 되는데, test코드에서는 filter를 제외하여 진행이 되므로 값을 수동으로 넣어줘야 하는 번거로움이 생기게 되는데, 이 번거로움을 해결하기 위해 @WithMember가 도입되었습니다.
@WithMember를 통해 ThreadLocal에 값이 저장되면, 이 값은 자동으로 @CurrentMember Authorization에 사용자 정보 값이 바인딩이 되게 됩니다.

따라서 컨트롤러에 사용자 정보 어노테이션이 있고, Filter를 적용하지 않는 테스트 코드를 진행한다면, @WithMember를 적용해 주시면 됩니다.

2. ThreadLocal에서 꺼내면 되는가?

먼저 Main Source에서는 ThreadLocal에 직접 접근할 필요가 없습니다. Controller에서 값을 가져와서 사용하면 되니까요

또한, 테스트 코드에서도 @WithMEmber를 사용한다면, mockMvc에서 content로 AuthorizationMember를 넣을 필요가 없고, 직접 꺼내와서 사용할 필요도 없습니다.
알아서 넣어주니 까요
다만, 테스트의 자유도를 높이기 위해 AuthorizationMember 값을 직접적으로 가져올 수 는 있도록 하였습니다. 그 방법으로 본문에서도 작성했던 @WithMember의 사용법을 확인해 주시면 감사합니다.

3. @WithMember와 @CurrentMember의 차이

본문에 추가하였습니다.
추가적인 설명이 필요하다면 말씀해주세요!

4. WebConfig에 추가하면 되는가?

네, 인증 작업을 거치고 싶지 않다면,
인증을 거치지 않게 하고 싶은 uri, role들, method들을 사용해 주시면 됩니다.

5. WithFilterSupporter를 제공하는 이유?

먼저 WithoutFilterSupporter만으로 모든 테스트가 가능합니다. 다만 filter를 추가한 테스트를 진행하고 싶은 경우도 존재할 수 있다 판단하여 추가하였습니다.
이렇게 하다 보니, Filter에서는 쿠키값을 확인하는 과정을 거치게 되는데, 매 테스트 코드에서 쿠키를 추가하는 것은 상당한 불편함을 감수해야 했습니다. 따라서 이 과정을 전부 생략해드리기 위해 mockMvc를 따로 만들어서 제공해 드렸습니다.

작성한 글이 좀 길고 답변도 길어서 읽기 힘드셨을텐데 감사합니다!

[hongdosan]

답변 정말 감사합니다!! 갑자기 이해안되던 부분들이 이해가 갔습니다! 세연님 체공~

[ymkim97]

오 확실히 개발하기 편하고 좋게 해주셨네요 감사합니다 세연님~!!!