@WebMvcTest를 진행시 Header에 Authorization을 할당 할 경우 아래 처럼 SecurityRequirements는 다양한 형태로 생길 수 있다.

근데 똑같이 헤더 이름을 지정하고, 테스트용 토큰 문자열을 할당하는데, 어떻게 아래처럼 다양한 결과를 맞을 수 있을까?

 

일단 스웨거 UI에서 우측 상단 아래에 있는 버튼을 활성화하려면 JWT_BEARER이어야 한다.

그 외 OAUTH2 관련 스펙을 정의하는건 별도 설정을 통해서 가능한데,

우선 나는 활성화를 하고 싶은데 안되어서,

securityRequirements의 type을 결정하는건 대체 누가 해주나 싶어서 찾아 보았다.

 

결과는 아래와 같다.

 

토큰의 페이로드에 오는 데이터의 형태에 따라 결정된다고 보면 된다.

scope가 포함된 토큰을 사용시에는 OAUTH2로 형태가 지정되고,

그게 아닌 경우 JWT_BEARER,

토큰은 있으나, 형태가 불분명하면, null로 처리되더라.

jwt 토큰 검증 관련 테스트는 별개로 하고,

mvcTest의 테스트 코드에 jwt처리하는 부분을 모킹하고 아무 토큰이나 주워다 넣었는데,

하필 그게 OAUTH2 토큰이었고,

별거 아닌곳에서 헤매게 되었지만, 나름 기능상 중요한 사실을 알게된 시간.

OCP와 DIP를 지키기 위해
인터페이스와 구현체를 분리하고 다형성을 갖게끔 하는게 좋은 코드란건 알겠고,
결국 인터페이스를 상속받고 필요한 구현체만 구현하면 된다는걸 다들 알겠다고 한다.
 
근데 정작 사용을 어떻게 하는지 대부분 모르는 것 같다.
 
 
일단 개인적으로 그다지 좋지 않은 코드의 예시다.

    public interface PayService {

        void pay();
    }

    private class PayKakaoService implements PayService {

        @Override
        public void pay() {

        }
    }

    private class PaySamsungService implements PayService {

        @Override
        public void pay() {

        }
    }

    private class PayNaverService implements PayService {

        @Override
        public void pay() {

        }
    }

    private PayService payKakaoService;
    private PayService paySamsungService;
    private PayService payNaverService;

    @Getter
    @RequiredArgsConstructor
    public enum PayType {
        Kakao, Samsung, Naver;
    }

    @PostMapping("/payment")
    public ResponseEntity<?> pay(PayType payType) {

        if (payType == PayType.Kakao) {
            payKakaoService.pay();
        }

        if (payType == PayType.Samsung) {
            paySamsungService.pay();
        }

        if (payType == PayType.Naver) {
            payNaverService.pay();
        }

        return ResponseEntity.ok().build();
    }

    // 실행
    void callPayTest() {
        this.pay(PayType.Samsung);
    }

위 코드의 단점이 뭘까? 분명 인터페이스도 썻고, 필요에 따라 구현체도 만들었고,
근데 저기에 앱쁠페이를 추가한다면? 구현체를 만들지만

public ResponseEntity<?> pay(PayType payType)

요기 안에 있는 if문을 추가해야 하지 않겠는가?!
 
이거는 DIP에 위배 되는게 아닌가? 싶기도 하고, 

PayService ps = null;

if (payType == PayType.Kakao) {
    ps = payKakaoService;
}

if (payType == PayType.Samsung) {
    ps = paySamsungService;
}

if (payType == PayType.Naver) {
    ps = payNaverService;
}

ps.pay();

아님 뭐 메서드 내 필드를 이용해서 이렇게 바꿀까? 이것도 뭐 크게 다른건 없다고 느끼는데,
그렇다고 싱글톤 기반의 빈에서 클래스 필드를 맘대로 교체할 수도 없는 노릇이고,
 
좀 더 고차원 레이어에 영향이 안가는 방법의 코드를 작성 할 수는 없을까?
 
있다, Enum과 Provider를 사용하면 된다.
Spring Container는 등록된 모든 Bean에 대한 제어가 가능하다.
일단 등록되어 있으니 가져오는 것도 가능하다.
구조적으로는 위에 if문을 사용하는 것과 차이가 없지만,
 
적어도 인터페이스를 호출 하는 부분을 타입이나, 유형 때문에 바꿀 일은 없을 거다.
 
예시 코드 들어간다.
 
참고로 제 코드가 좋은 코드는 아닙니다용..제발...
 

    public interface PayService {

        void pay();
    }

    private class PayKakaoService implements PayService {

        @Override
        public void pay() {

        }
    }

    private class PaySamsungService implements PayService {

        @Override
        public void pay() {

        }
    }

    private class PayNaverService implements PayService {

        @Override
        public void pay() {

        }
    }

//    private PayService payKakaoService;
//    private PayService paySamsungService;
//    private PayService payNaverService;

    @Getter
    @RequiredArgsConstructor
    public enum PayType {
        Kakao(PayKakaoService.class), Samsung(PaySamsungService.class), Naver(
            PayNaverService.class);

        private final Class<? extends PayService> clazz;
    }

    public class PayServiceProvider {

        private static ApplicationContext applicationContext;
        private static Map<PayType, Class<? extends PayService>> payServiceMap = new HashMap<>();

        static {
            for (PayType payType : PayType.values()) {
                payServiceMap.put(payType, payType.getClazz());
            }
        }

        public static PayService service(PayType payType) throws Exception {
            Class<? extends PayService> payServiceClass = payServiceMap.get(payType);

            if (payServiceClass == null) {
                throw new Exception();
            }

            return applicationContext.getBean(payServiceClass);
        }
    }

    @PostMapping("/payment")
    public ResponseEntity<?> pay(PayType payType) throws Exception {

//        PayService ps = null;
//
//        if (payType == PayType.Kakao) {
//            ps = payKakaoService;
//        }
//
//        if (payType == PayType.Samsung) {
//            ps = paySamsungService;
//        }
//
//        if (payType == PayType.Naver) {
//            ps = payNaverService;
//        }
//
//        ps.pay();

        PayServiceProvider.service(payType).pay();

        return ResponseEntity.ok().build();
    }

    // 실행
    void callPayTest() throws Exception {
        this.pay(PayType.Samsung);
    }

일단, 해당 코드는 provider에서 사용하는 applicationContext에 대한 주입이 없긴하다.
요건 이제 @PostConstruct를 사용해서 주입하면 되긴합니다요.
물론 주입하는 함수도 provider에 static으로 만들어 줘야 합니다.
(대충 읽고 코드만 복붙하면 안되게 하려는 함정...)
 
대강 저런식이면, 앞으로 앱쁠페이든, 티머니든 추가되면 Enum과 구현체의 추가만으로 솔리드 뭐시기를 위배하지 않으면서 해결가능하지 않을까?
 
사실 Provider 구현하기 귀찮다.
유지 보수 측면에서는 좋긴하나, 처음 구현할때 걍 if else 쓰는게 백배 편하다.
시간 비용을 초기에 쓸거냐 나중에 쓸거냐 차이긴한데,
 
아래는 좀 더 편한 방법

private List<PayService> payServices;

@PostMapping("/payment")
public ResponseEntity<?> pay(PayType payType) throws Exception {

    payServices.stream().filter(payService -> payService.check(payType)).findFirst()
        .ifPresent(PayService::pay);
    return ResponseEntity.ok().build();
}

 
스프링은 주입시 배열로 필드를 선언하면 해당 인터페이스에 해당하는 빈들을 모두 가져 오는데요, 이걸 몰랐던건 아닌데, 이렇게 응용할 생각은 못 했네요. 멍청이...
 
아는분이 알려주신건데 아래 링크 통해 배우셨대요!
https://youtu.be/3MTf43_RcVM

 

+ Recent posts