@SpringBootTest와 @WebMvcTest의 차이점을 설명해 주세요.

1. @SpringBootTest

• 이 어노테이션은 통합 테스트를 수행할 때 사용된다.
• @SpringBootTest 어노테이션을 사용하면 전체 Spring ApplicationContext를 로드한다.
• 이는 모든 Bean들을 초기화하고 모든 구성을 로드한다는 것을 의미한다.
• 따라서 애플리케이션의 전체 동작을 테스트하려는 경우에 사용된다.
• 하지만 이는 상당한 시간과 자원을 필요로 한다.

@SpringBootTest
public class ApplicationTest {

    @Autowired
    private MyService myService;

    @Test
    public void contextLoads() {
        // 테스트 코드...
    }
}

2. @WebMvcTest

• @WebMvcTest 어노테이션은 웹 계층만을 테스트하는 데 사용된다.
• Spring MVC 인프라를 설정하고 웹 관련 빈들만 로드한다.
• 컨트롤러, 컨트롤러 어드바이스, 필터, 인터셉터 등과 같은 웹 관련 구성만 로드한다는 것을 의미한다.
• 이 어노테이션은 MockMvc 인스턴스를 자동으로 제공하여, HTTP 요청을 디스패처 서블릿에 보내고 그 결과를 검증할 수 있다.
• **@WebMvcTest**는 빠른 피드백을 제공하며, 컨트롤러 단위 테스트를 하는 데 유용하다.

@WebMvcTest(MyController.class)
public class MyControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void testMyController() throws Exception {
        this.mockMvc.perform(get("/"))
            .andExpect(status().isOk())
            .andExpect(content().string("Hello World"));
    }
}

따라서, @SpringBootTest와 @WebMvcTest의 주요 차이점은 테스트의 범위와 로드하는 ApplicationContext의 범위에 있다. @SpringBootTest는 전체 ApplicationContext를 로드하고, @WebMvcTest는 웹 계층에 관련된 부분만 로드한다.

SpringBoot에서 JUnit을 사용하여 테스트 코드를 작성할 때

@SpringBootTest 어노테이션을 자주 쓰게 되는데, 상황에 따라서는 @WebMvcTest를 쓰는게 좋을 때도 있다.

@SpringBootTest와 @WebMvcTest는 둘 다 Spring Boot 테스트를 위한 어노테이션입니다. 하지만 두 어노테이션은 사용되는 컨텍스트와 테스트의 범위에 따라 크게 다릅니다.

Junit이란 자바 개발자의 93%가 사용하는 단위 테스트 프레임워크이며 Java8 이상부터 지원한다.

JUnit5의 경우 2017년 10월에 공개

스프링부트의 경우 2.2버전부터 기본적으로 제공된다.

@SpringBootTest + @AutoConfigureMockMvc

• 프로젝트 내부에 있는 스프링 빈을 모두 등록하여 테스트에 필요한 의존성을 추가한다.
• 실제 운영 환경에서 사용될 클래스들을 통합하여 테스트한다.
• 단위 테스트와 같이 기능 검증을 위한 것이 아니라, Spring Framework에서 전체적으로 Flow가 제대로 동작하는지 검증하기 위해 사용한다.

장점

• 애플리케이션의 설정, 모든 Bean을 모두 로드하기 때문에 운영환경과 가장 유사한 테스트가 가능하다.

단점

• 테스트 단위가 크기에 디버깅이 까다로움
• 어플리케이션의 설정, 모든 Bean을 로드하기 때문에 시간이 오래 걸림

@SpringBoottest
@AutoConfugurMockMvc
class SenderControllerTest {

	@Autowited
	private MockMvc mockMvc;

	@Autowited
	private ObjectMapper objectMapper;

	@MockBean
	private SenderService senderService;
}

@WebMvcTest

• MVC를 위한 테스트, 컨드롤러가 예상대로 작동되는지 테스트하기 위해 사용된다.
• Web Layer만 로드하며, @WebMvcTest어노테이션을 사용시 아래의 항목들만 스캔하도록 제한하여 보다 빠르고 가벼운 테스트가 가능하다.

장점

• WebApllication과 관련된 Bean들만 등록하기 때문에 @SpringBootTest보다 빠르다.
• 통합테스트를 진행하기 어려운 테스트를 개별적으로 진행 가능

단점

• Mock을 기반으로 테스트하기 때문에, 실제 환경에서는 예상 밖의 동작오류가 발생할 수 있다.(참고: 위의 @SpringBootTest에는 @ExtendWith(SpringExtension.class)가 포함되어있음)
• @WebMvcTest()의 프로퍼티로 테스트를 원하는 컨트롤러 클래스를 넣어준다.

@ExtendWith(SpringExtension.class)
@WebMvcTest(SenderController.class)
class SenderControllerTest {

	@Autowited
	private MockMvc mockMvc;

	@Autowited
	private ObjectMapper objectMapper;

	@MockBean
	private SenderService senderService;

	@MockBean
	private AraClient araClient;
}

스트링 REST Client

스프링 부트가 REST 클라이언트 관련해서 직접적으로 기능을 제공하는 것은 아니다. REST 클라이언트는 Spring Framework에서 제공하는 것이고, 부트는 그걸 쉽게 사용할 수 있도록 빈을 등록해준다.

주의 할 것은 RestTemplate과 WebClient 두 타입의 빈을 등록해주는 것이 아니라, 빌더를 등록해준다. 그래서 우리는 빌더를 주입받아서 필요할 때마다 REST 클라이언트를 빌드해서 사용해야한다.

RESTful 웹 서비스를 소비하는 데 사용할 수 있는 몇 가지 방법이 있습니다. 주로 사용되는 두 가지 주요 도구는 **RestTemplate**과 **WebClient**이다.

1. RestTemplate:

• 이것은 Spring이 제공하는 동기식 HTTP 클라이언트이다.
• RESTful 서비스를 호출하는 데 사용되며, HTTP 메서드에 대한 템플릿 메서드를 제공한다.
• 예를 들어, GET, POST, PUT, DELETE 등의 메서드를 지원한다.
• 그러나 Spring 5.0 이후로는 RestTemplate이 deprecated되었으며, 대신 WebClient를 사용하는 것이 권장된다.

RestTemplate restTemplate = new RestTemplate();
String result = restTemplate.getForObject(url, String.class);

• Blocking I/O 기반의 Synchronous API
• RestTemplateAutoConfiguration
• 프로젝트에 spring-web 모듈이 있다면 RestTemplateBuilder를 빈으로 등록

예제로 이해하기

1) @RestController 구현

• 3초를 sleep하는 GetMapping
• 5초를 sleep하는 GetMapping

2) REST Client요청은 ApplicationRunner 구현 클래스에서 보내보자

@RestController
public class SampleController {

    @GetMapping("/hello")
    public String hello() throws InterruptedException {
    	Thread.sleep(3000L);
        return "hello";
    }

    @GetMapping("/sample")
    public String sample() throws InterruptedException {
    	Thread.sleep(5000L);
        return "sample";
    }
}

방법1. RestTemplateBuilder를 주입받아 RestTemplate 생성

• getForObject로 get요청 보내기
• blocking i/o : 호출된 함수가 자신의 작업을 모두 마칠 때까지 호출한 함수에게 제어권을 넘겨주지 않고 대기하게 만듬
• sync : 호출된 함수의 작업 완료 여부를 신경쓰기 때문에 작업을 마칠 때까지 기다린다.

@Component
public class RestRunner implements ApplicationRunner {

	@Autowired
	public RestTemplateBuilder restTemplateBuilder;

	@Override
	public void run(ApplicationArguments args) throws Exception {
          RestTemplate restTemplate = restTemplateBuilder.build();

          StopWatch stopWatch = new StopWatch();
          stopWatch.start();

          String helloResult = restTemplate.getForObject("<http://localhost:8080/hello>", String.class);

          String sampleResult = restTemplate.getForObject("<http://localhost:8080/sample>", String.class);

          stopWatch.stop();
          System.out.println(stopWatch.prettyPrint());
    }
}

해당 코드의 결과

• 5초 째에 "hello"를 출력하고, 8초 째에 "sample"을 출력한다.
• sync-blocking : /hello GET요청이 끝날 때까지 기다리고, /sample GET요청이 끝날 때까지 기다림
• 따라서 두 요청이 모두 끝나려면 8초가 걸린다.

2. WebClient

• Spring 5에서 도입된 비동기, non-blocking, reactive 웹 클라이언트이다.
• Project Reactor를 기반으로 하며, 비동기 처리와 백프레셔(Backpressure)를 지원한다.
• RestTemplate보다 더 효율적인 리소스 사용이 가능하며, 대량의 요청을 처리하는데 적합하다.
• RestTemplate이 deprecated된 이후, WebClient가 RESTful 서비스를 호출하는 주요 도구가 되었다.

WebClient webClient = WebClient.create();
Mono<String> result = webClient.get()
        .uri(url)
        .retrieve()
        .bodyToMono(String.class);

• Non-Blocking I/O 기반의 Asynchronous API
• WebClientAutoConfiguration
• 프로젝트에 spring-webflux 모듈이 있다면 WebClient.Builder를 빈으로 등록

방법2. WebClient.Builder를 주입받아 WebClient 생성

• get().uri().retrieve().bodyToMono(String.class)로 GET요청 보내기
• Stream API를 사용하기 때문에 subscribe()로 결과를 반환해야 함
• non-blocking i/o : 호출된 함수가 바로 결과를 반환하여, 호출한 함수에게 제어권을 바로 넘겨준다.
• async : 호출된 함수의 작업 완료 여부를 신경쓰지 않기 때문에, 작업 완료 시 호출된 함수는 전달받은 콜백을 실행하기만 한다.

cf) subscribe()는 Javascript의 .then()을 생각하면 될 듯!

Promise 객체가 fulfilled되도 then을 쓰지 않으면 resolve()의 인자값을 꺼낼 수 없는 것처럼

내가 보냈던 요청에 대한 응답 이벤트를 받을 때, 어떤 행동을 수행할 것인지 이벤트 핸들러를 정의해주는 일이다.

@Component
public class RestRunner implements ApplicationRunner {

    @Autowired
    WebClient.Builder webClientBuilder;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        WebClient webClient = webClientBuilder.build();

        StopWatch stopWatch = new StopWatch();
        stopWatch.start();

        Mono<String> helloResult = webClient.get().uri("<http://localhost:8080/hello>")
                                        .retrieve()
                                        .bodyToMono(String.class);
        helloResult.subscribe(result -> {
            System.out.println(result);

            if (stopWatch.isRunning()){
                stopWatch.stop();
            }

            System.out.println(stopWatch.prettyPrint());
            stopWatch.start();
        });

        Mono<String> worldResult =  webClient.get().uri("<http://localhost:8080/sample>")
                                        .retrieve()
                                        .bodyToMono(String.class);
        worldResult.subscribe(result -> {
            System.out.println(result);

            if (stopWatch.isRunning()){
                stopWatch.stop();
            }

            System.out.println(stopWatch.prettyPrint());
            stopWatch.start();
        });
    }
}

• 3초 째에 "hello"를 출력하고, 5초 째에 "sample"을 출력한다.
• async-nonblocking : /hello GET요청과 /sample GET요청이 병렬적으로 수행된다.
• 따라서 두 요청이 모두 끝나려면 5초가 걸린다.

스프링 REST Client 커스터마이징

WebClient 커스터마이징

1. webClientBuilder.build()로 빌드하기 전에 필요한 설정 가능
   • baseUrl("http://localhost:8080")
   • defaultCookie( )
   • defaultHeader( )
2. 글로벌 WebClient 객체 사용하기
   • WebClientCustomizer 빈 재정의
   • ApplicationContext에서 전역적으로 적용한다.

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(Application.class);
        app.run(args);
    }

    @Bean
    public WebClientCustomizer webClientCustomizer(){
        return new WebClientCustomizer() {
            @Override
            public void customize(WebClient.Builder webClientBuilder) {
                webClientBuilder.baseUrl("<http://localhost:8080>");
            }
        };
    }
}

RestTemplate 커스터마이징

1. RestTemplateBuilder 빈 재정의
   • org.apache.httpcomponents:httpclient 의존성 추가 필요
   • 마찬가지로 ApplicationContext에서 전역적으로 정의

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication app = new SpringApplication(Application.class);
        app.run(args);
    }

    @Bean
    public RestTemplateCustomizer restTemplateCustomizer() {
        return new RestTemplateCustomizer() {
            @Override
            public void customize(RestTemplate restTemplate) {
                restTemplate.setRequestFactory(new HttpComponentsClientHttpRequestFactory());
            }
        };
    }
}

스프링 컨테이너(Spring Container)에 대해 설명해주세요.

스프링 컨테이너(Spring Container)

스프링 컨테이너는 스프링 프레임워크의 핵심 컴포넌트이다.

스프링 컨테이너는 자바 객체의 생명 주기를 관리하며, 생성된 자바 객체들에게 추가적인 기능을 제공한다.

스프링에서는 자바 객체를 빈(Bean)이라 한다.

즉, 스프링 컨테이너는 내부에 존재하는 빈의 생명주기를 관리(빈의 생성, 관리, 제거 등)하며, 생성된 빈에게 추가적인 기능을 제공하는 것이다.

스프링 컨테이너는 XML, 어노테이션 기반의 자바 설정 클래스로 만들 수 있다.

스프링 부트(Spring Boot)를 사용하기 이전에는 xml을 통해 직접적으로 설정해 주어야 했지만, 스프링 부트가 등장하면서 대부분 사용하지 않게 되었다.

스프링 컨테이너의 종류

스프링 컨테이너는 Beanfactory와 ApplicationContext 두 종류의 인터페이스로 구현되어 있다.

빈 팩토리는 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트이고, 빈 팩토리를 좀 더 확장한 것이 애플리케이션 컨텍스트이다.

애플리케이션 컨텍스트는 IoC 방식을 따라 만들어진 일종의 빈 팩토리로 둘 다 동일한 개념이라 생각하면 된다.

주로 사용되는 스프링 컨테이너는 애플리케이션 컨텍스트이다.

BeanFactory

가장 기본적인 컨테이너로, 빈의 생성과 관리, 빈 간의 의존성 해결 등을 담당

빈 팩토리(BeanFactory)는 스프링 컨테이너의 최상위 인터페이스이다.

BeanFactory는 빈을 등록, 생성, 조회 등의 빈을 관리하는 역할을 하며, getBean() 메서드를 통해 빈을 인스턴스화 할 수 있다.

@Bean 어노테이션이 붙은 메서드의 이름을 스프링 빈의 이름으로 사용하여 빈 등록을 한다.

ApplicationContext

애플리케이션 컨텍스트(ApplicationContext)는 BeanFactory의 기능을 상속받아 제공한다.

BeanFactory의 모든 기능을 포함하며, 이외에도 메시지 소스 처리(국제화 지원), 이벤트 발행, 애플리케이션 계층에 특화된 다양한 기능을 제공

따라서, 빈을 관리하고 검색하는 기능을 BeanFactory가 제공하고, 그 외의 부가 기능을 제공한다.

• 부가 기능
  • MessageSource : 메시지 다국화를 위한 인터페이스
  • EnvironmentCapable : 개발, 운영, 환경변수 등으로 나누어 처리하고, 애플리케이션 구동 시 필요한 정보들을 관리하기 위한 인터페이스
  • ApplicationEventPublisher : 이벤트 관련 기능을 제공하는 인터페이스
  • ResourceLoader : 파일, 클래스 패스, 외부 등 리소스를 편리하게 조회

스프링 컨테이너의 기능

빈의 생성 및 관리: 인스턴스화, 구성, 전체 생명 주기 및 제거까지 관리한다.

• 스프링 컨테이너는 설정 파일이나 애노테이션을 통해 지정된 빈을 생성하고 관리합니다.
• 컨테이너는 개발자가 정의한 빈을 객체로 만들어 관리하고 개발자가 필요로 할 때 제공한다.

의존성 주입(Dependency Injection, DI): 애플리케이션의 컴포넌트를 관리할 수 있다.

• 컨테이너는 각 빈 간의 의존성을 관리하며, 필요에 따라 의존성 주입을 수행합니다.

스프링 컨테이너 : 스프링 컨테이너를 통해 원하는 만큼 많은 객체를 가질 수 있다.

• 서로 다른 빈을 연결하여 애플리케이션 빈을 연결하는 역할을 한다.
• 개발자는 모듈 간에 의존 및 결합으로 인해 발생하는 문제로부터 자유로울 수 있다.
• 메서드가 언제 어디서 호출되어야 하는지, 메서드를 호출하기 위해 필요한 매개 변수를 준비해서 전달하지 않는다.

생명주기 관리: 스프링 컨테이너는 빈의 생명주기를 관리하며, 초기화 및 소멸과 같은 라이프사이클 이벤트에 대한 콜백 인터페이스를 제공합니다.

프록시 및 AOP 지원: 스프링 컨테이너는 프록시 생성 및 AOP(Aspect-Oriented Programming) 기능을 지원하여 관점 지향 프로그래밍을 가능하게 합니다.

스프링 컨테이너를 사용하는 이유

먼저, 객체를 생성하기 위해서는 new 생성자를 사용해야 한다. 그로 인해 애플리케이션에서는 수많은 객체가 존재하고 서로를 참조하게 된다.

객체 간의 참조가 많으면 많을수록 의존성이 높아지게 된다.

이는 낮은 결합도와 높은 캡슐화를 지향하는 객체지향 프로그래밍의 핵심과는 먼 방식이다.

따라서, 객체 간의 의존성을 낮추어(느슨한 결합) 결합도는 낮추고, 높은 캡슐화를 위해 스프링 컨테이너가 사용된다.

또한, 기존의 방식으로는 새로운 기능이 생기게 되면 변경 사항들을 수작업으로 수정해야 한다.

프로젝트가 커질수록 의존도는 높아질 것이고, 그에 따라 코드의 변경도 많아질 것이다.

하지만, 스프링 컨테이너를 사용하면 구현 클래스에 있는 의존성을 제거하고 인터페이스에만 의존하도록 설계할 수 있다.

스프링 컨테이너의 생성 과정

주로 사용하는 설정 방식은 Java의 어노테이션 기능을 통해 설정하게 된다.

하지만 기존 방식인 XML 방식에 대해서도 알아야 한다.

기본적으로 스프링 컨테이너는 Configuration Metadata를 사용한다.

또한, 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용하여 스프링 빈을 등록한다.

스프링 컨테이너를 만드는 다양한 방법은 ApplicationContext 인터페이스의 구현체이다.

AppConfig.class 등의 구성 정보를 지정하여 스프링 컨테이너를 생성할 수 있다.

애플리케이션 클래스는 구성 메타데이터와 결합되어 ApplicationContext를 생성하고 초기화된다.

이후 실행 가능한 시스템 또는 애플리케이션을 갖게 된다.

만약, 스프링 빈 조회에서 상속관계가 있을 시에는 부모 타입으로 조회하면 자식 타입도 함께 조회된다. 즉, Object 타입으로 조회하게 되면 모든 스프링 빈을 조회할 수 있다.

스프링 컨테이너 생성과 등록

아래 코드는 자바 어노테이션을 기반으로 컨테이너를 구성하고 스프링 컨테이너에 등록하는 예시이다.

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

아래 코드는 어노테이션 기반으로 위 코드에서 구성한 스프링 컨테이너를 생성하는 방법이다.

public class MemberApp {
    public static void main(String[] args) {
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class)
    }
}

@ApplicationContext(AppConfig.class)

ApplicationContext를 스프링 컨테이너라고 하며, 인터페이스로 구현되어 있다.

• 다형성이 적용이 되어 있으며, 다양한 구현체가 존재

AnnotationConfigApplicationContext는 ApplicationContext 인터페이스의 구현체 중 하나이다.

@Configuration

스프링 컨테이너가 해당 어노테이션이 붙은 클래스를 설정 정보로 사용한다.

클래스 내부에 @Bean 어노테이션이 적힌 메서드를 모두 호출하여 얻은 객체를 스프링 컨테이너에 등록하게 된다.

스프링 컨테이너에 등록된 객체를 **스프링 빈(Bean)**이라 한다.

applicationContext.getBean(”이름”, 타입);

스프링 빈은 getBean() 메서드를 이용하여 얻을 수 있다.

ApplicationContext 인터페이스의 구현체

ApplicationContext 인터페이스에는 수많은 구현체가 존재한다.

이러한 다양한 구현체를 통해 스프링 컨테이너를 다양한 방법으로 생성할 수 있다.