본문 바로가기
Lecture/토비의 스프링 부트 - 이해와 원리

토비의 스프링 부트 - DI와 테스트, 디자인 패턴

by Soono991 2023. 2. 8.

💡이 포스팅은 토비님의 인프런 강의인 토비의 스프링 부트 - 이해와 원리를 수강하고 학습한 내용을 정리한 포스팅입니다.

 

토비님의 강의를 수강하며 정리한 GitHub Repository 입니다.

 

GitHub - kiekk/inflearn-toby-spring-boot

Contribute to kiekk/inflearn-toby-spring-boot development by creating an account on GitHub.

github.com

 

이번 챕터에서는 단위 테스트와 DI를 이용한 Decorator, Proxy 패턴에 대해 학습합니다.

 

Test 코드에서 HTTP 요청

 

테스트 코드를 작성할 때 HTTP 요청을 위해 TestRestTemplate, Mock 객체를 사용하는데, 테스트 코드를 많이 작성해보지 않았고 공부를 깊이 해보지 않아 두 객체에 대해 궁금증이 생겼습니다.

 

추후 관련해서 정리하게 되면 링크를 남겨놓도록 하겠습니다.

 

Assertions

위와 같이 assertjjunit에서 각각 Assertions 객체를 제공하는데, 토비님은 강의에서 assertjAssertions를 사용했습니다.

 

assertjjunitAssertions이 각각 어떤 차이가 있는지 어떤 장단점을 가지고 있는지에 대해서도 추후 정리하게 되면 링크를 남겨놓도록 하겠습니다.

 

Decorator, Proxy 패턴

 

Decorator, Proxy 패턴은 프록시를 사용하는 디자인 패턴들입니다.

 

 

프록시 패턴

/ 디자인 패턴들 / 구조 패턴 프록시 패턴 다음 이름으로도 불립니다: Proxy 의도 프록시는 다른 객체에 대한 대체 또는 자리표시자를 제공할 수 있는 구조 디자인 패턴입니다. 프록시는 원래 객체

refactoring.guru

 

데코레이터 패턴

/ 디자인 패턴들 / 구조 패턴 데코레이터 패턴 다음 이름으로도 불립니다: 래퍼(Wrapper), Decorator 의도 데코레이터는 객체들을 새로운 행동들을 포함한 특수 래퍼 객체들 내에 넣어서 위 행동들을

refactoring.guru

 

Spring에서 이 디자인 패턴들을 사용하는 기술 중 가장 대표적인 기술이 바로 AOP입니다.

Decorator, Proxy 패턴은 프록시를 사용하는 것은 동일하지만 목적에 따라서 각각의 디자인 패턴으로 구분합니다.

프록시를 적용하고 싶은 클래스를 타깃이라고 부르는데,

타깃에 접근할 수 있는지 없는지를 판별하는 것처럼 접근 제어의 목적을 가지고 있다면 Proxy 패턴

타겟에 부가적인 기능을 추가하는 목적을 가지고 있다면 Decorator 패턴으로 구분합니다.

 

Decorator, Proxy 패턴을 사용할 때 조심할 점은 두 패턴을 적용하기 위해서는 Decorator, Proxy 패턴에 사용될 객체가 실제 타깃과 같은 타입이어야 한다는 점입니다.

 

위와 같이 HelloService가 있을 때 SimpleHelloServiceDecorator, Proxy 패턴을 적용하기 위해 HelloDecorator 클래스를 작성했습니다.

 

이때 HelloDecorator는 실제 타깃인 SimpleHelloService와 같은 타입이어야 하기 때문에 HelloService를 구현해야 하며,

이렇게 했을 때 HelloService 타입으로 HelloDecorator, SimpleHelloService 두 개의 빈이 생성되기 때문에 에러가 발생합니다.

 

따라서 위와 같이 HelloDecorator 클래스에 @Primary 애노테이션을 사용하여 HelloDecorator가 빈으로 등록될 수 있도록 합니다.

 

지금은 간단하게 테스트를 위해 이렇게까지만 작성했는데, 사실 위와 같이 사용했을 때는 여러 가지 문제가 존재합니다.

 

  1. Decorator, Proxy 없이 SimpleHelloService에 바로 접근할 수 없습니다.
  2. Decorator, Proxy를 여러 개 적용할 때 각각의 우선순위를 정해야 하는 등의 추가 작업이 필요한데 이 작업이 그렇게 쉽지 않습니다.
  3. 개발자가 HelloDecorator를 직접 알고 있어야 합니다. naming 이슈가 있어서 HelloDecoratorSimpleHelloService와 같은 이름으로 빈을 등록할 수 없습니다.

위와 같은 문제들을 AOP에서 모두 해결했기 때문에, AOP를 사용할 때는 사실 위와 같은 문제를 걱정할 필요는 없습니다.

 

이와 관련해서 더 궁금하신 분들은 AOP를 찾아보시는 것을 추천드립니다.

아무래도 이번 토비님의 강의가 스프링 부트에 초점을 맞추고 있기 때문에 테스트나 AOP 같은 부분은 가볍게 짚고 넘어가는 느낌이 들었습니다.

 

하지만 그렇다고 해서 테스트, AOP가 중요하지 않다는 뜻은 아니기 때문에 시간을 내서라도 관련 내용들을 추가로 학습하는 것이 좋다고 생각합니다.

 

개인적으로는 앞서 설명했듯이 테스트 관련 개념이나 지식이 매우 얕기 때문에 빠른 시일 내에 시간을 내서 테스트에 대해 학습해 볼 생각입니다.

댓글