[Spring] 스프링 테스트 - 테스트 컨텍스트 캐싱, @SpringBootTest, @WebMvcTest

🌱 들어가기 전

이전 포스팅과 마찬가지로 스터디에서 맡은 '테스트' 파트에 대해서 블로그에 정리해보고자 한다 😊

테스트 쪽은 공식 문서도 생각보다 가독성이 너무 안 좋아서 최대한 간략하게만 훑어보았다.

아직 모르는 게 정말 많은 것 같다 ㅎㅎ

---

 

🌱 통합 테스트 vs 인수 테스트

통합 테스트는 특정 작업을 수행하기 위해, 외부 작업들과 연관되어 있다면 해당 외부 작업들을 포함하여 구성 요소가 잘 돌아가는지 테스트하는 방법으로, @SpringBootTest 어노테이션을 활용하여 진행하는 방법이 많다. (관련된 모든 빈을 가져와서 테스트 하는 느낌)

 

반면, 인수 테스트의 경우 사용자의 시나리오에 맞춰 수행하는 테스트이다.

인수 테스트의 방법론으로 E2E 테스트를 통해 주어진 시나리오에 따라 애플리케이션의 모든 계층이 서로 잘 동작하는지 확인할 수 있다.

RestAssured를 활용해서 테스트 코드를 작성하는 방식을 많이 보았다.

 

사실 인수 테스트와 E2E 테스트가 동일한 것이라고 생각했었는데, E2E 테스트가 조금 더 큰 범위라고 생각할 수 있을 것 같다.

인수 테스트는 사용자의 시나리오에 맞추기 때문에, 그게 단위 테스트이든, 통합 테스트이든 사용자의 요구사항에 맞춘다면 다 인수 테스트라고 할 수 있기 때문이다.

 

---

 

🌱 테스트 프레임워크

스프링은 테스트에 사용되는 애플리케이션 컨텍스트를 생성하고 관리하고, 테스트에 적용해주는 기능을 가진 ‘테스트 프레임워크’를 제공한다. 그리고 이를 ‘테스트 컨텍스트 프레임워크’라고 부른다.

테스트 대상 메서드에 @Test를 붙이면 해당 메서드가 속한 클래스는 ‘테스트 클래스’로서 동작하며, 각 메서드는 독립적인 테스트가 된다.
하지만, 테스트마다 테스트 컨텍스트를 매번 새로 생성하게 된다면 오버헤드가 크기 때문에 전체 테스트의 실행 속도가 느려져셔 개발자의 생산성이 떨어진다. 이때문에 테스트 컨텍스트는 자신이 담당하는 테스트 인스턴스에 대한 컨텍스트 관리 및 캐싱 기능을 제공한다!

 

그래서 테스트를 할 때 특정 애플리케이션 컨텍스트를 구성하고 싶다면, 클레스 레벨에 @ContextConfiguration 어노테이션을 선언함으로서 구성 정보를 주입해줄 수 있다.

 

💡 페어가 @Import 어노테이션이랑 다른 거냐고 물어봤는데, 내부적으로 조금 까보니까 등록되는 빈이 조금 다르다.
@Import의 경우 importsCleanupPostProcessor라는 빈이 추가로 등록되는 거를 확인했다.
또한, @Import의 경우 기존 ApplicationContext에 해당 Component를 추가한다는 것이고, @ContextConfiguration의 경우는 어떤 애플리케이션 컨텍스트를 사용할지, 그리고 XML 같은 걸로 설정도 할 수 있다는 점이 있을 것 같다.
사실 명확하게 둘의 차이를 이해하기는 어렵지만... 유스케이스가 다른 것 같다.

 

 

💬 컨텍스트 설정 정보 주입하기

@ExtendWith(SpringExtension.class) 
@ContextConfiguration(classes = {AppConfig.class, TestConfig.class}) 
class MyTest {

}

💡 @ExtendWith 어노테이션의 경우 스프링 프레임워크와 Junit5를 연동해주는 역할으로서, @Test 같은 어노테이션을 사용하기 위해서는 붙여줘야 한다. (Junit4에서는 @RunWith(SpringRunner.class)을 사용했었음)

 

@ContextConfiguration 어노테이션을 활용하여 어떤 설정 정보 파일을 구성할지 설정할 수 있다.

여기서 classes 인자로 준 AppConfig.class와 TestConfig.class에 등록된 빈 정보를 바탕으로 ApplicationContext가 구성되며, 이때 각각의 Configuration 클래스의 경우 @Configuration 어노테이션 (스프링 부트라면 @TestConfiguration도 가능)이 붙어 있거나, @Component, @Service, @Repository 같은 스테레오 타입 어노테이션이 붙어있는 클래스면 가능하다.

 

@Configuration
public class Hello {
    @Bean
    public Nested nested() {
        return new Nested();
    }

    static class Nested {

    }
}

위와 같이 static nested class로 선언되어 있는 빈을 등록한다고 생각해보자.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {Hello.class})
public class Sample {

    @Autowired
    private Nested nested;

    @Test
    void test() {

    }
}

그럼 위와 같이 Hello라는 설정 정보 클래스를 @ContextConfiguration으로 불러오게 되면, Hello라는 Configuration 클래스에 대한 정보를 읽어서 등록되어 있는 Nested라는 빈에 대해 의존관계를 주입받을 수 있게 된다.

 

만약, @ContextConfiguration 어노테이션을 제거하게 되면 아래와 같이 컴파일 오류가 발생한다.

---

 

🌱 지금까지 나는 컨텍스트 정보를 지정한 적이 없는데...?

하지만, 나는 지금까지 @ContextConfiguration이라는 친구를 한 번도 테스트 코드에서 사용한 적이 없었다.

근데 어떻게 테스트가 정상적으로 동작을 했었던 것일까?

Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test

기본적으로는 @ContextConfiguration이나 @SpringBootTest 어노테이션을 지정해달라는 오류가 발생한다.

 

하지만, 만약 ⭐️ 스프링 부트 ⭐️ 를 사용하고, @SpringBootApplication 어노테이션이 붙은 클래스가 존재하는 패키지의 하위 패키지에 테스트 클래스를 두었다면, 알아서 적절한 정보를 찾게 된다. (보통 최상단 패키지에 @SpringBootApplication을 두는 이유가 여기서 나온다)

Found @SpringBootConfiguration com.example.study.StudyApplication for test class com.example.study.hi.Sample

테스트 코드를 돌려보면 위와 같이 @SpringBootConfiguration이라는 어노테이션을 찾았다는 것을 볼 수 있는데, 이는 @SpringBootApplication 어노테이션이 존재하는 클래스를 찾으면서 내부적으로 중첩되어 있는 어노테이션인 @SpringBootConfiguration을 찾을 수 있었기 때문이다.

위와 같이 @SpringBootApplication 어노테이션의 경우 중첩으로 @SpringBootConfiguration이라는 어노테이션을 가지고 있다. (@Configuration 어노테이션이랑 거의 동일하게 동작한다고 생각하면 된다.) 덕분에 별도의 컨텍스트 정보를 지정하지 않더라도 알아서 해당 어노테이션이 붙은 클래스를 중심으로 하위 클래스들의 설정 정보를 자동으로 찾아서 등록하게 된다. 

 

---

 

🌱 Context Caching

테스트 컨텍스트 프레임워크는 테스트에 대한 ApplicationContext를 로드하면, 해당 컨텍스트가 캐싱되어 동일한 테스트 컨텍스트 구성을 사용하게 되면 해당 컨텍스트를 재사용하게 된다. 보통 ApplicationContext의 경우 이를 로드하기 위한 configuration parameter의 조합을 통해 고유하게 식별이 가능하다.

 

configuration parameter로는 다음과 같은 정보들을 사용한다.

 

locations	@ContextConfiguration 어노테이션의 인자
classes	@ContextConfiguration 어노테이션의 인자
contextInitializerClasses	@ContextConfiguration 어노테이션의 인자
contextCustomizers	ContextCustomizerFactory로부터 로드
contextLoader	@ContextConfiguration 어노테이션의 인자
parent	@ContextHierarchy
activeProfiles	@ActiveProfile
propertySourceLocations	@TestPropertySource
propertySourceProperties	@TestPropertySource
resourceBasePath	@WebAppConfiguration

 

테스트 컨텍스트 프레임워크는 애플리케이션 컨텍스트를 정적 변수로 저장하며, 만약 테스트 자체가 별도의 프로세스에서 실행되는 경우 각 테스트 실행 사이의 정적 캐시가 지워지기 때문에 캐싱 작업 역시 함께 비활성화 된다.

기본적으로 컨텍스트 캐시의 크기는 32로 제한되어 있으며, 최대 크기에 도달하게 되면 LRU 알고리즘에 따라 가장 오래된 컨텍스트를 제거한다. 

 

실제로 코드를 통해 확인해보자. 위에서 선언했던 Sample 클래스에 동일한 설정 정보를 가진 Sample2 클래스를 생성해주었다.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {Hello.class})
public class Sample {

    @Autowired
    private Nested nested;

    @Autowired
    ApplicationContext ac;

    @Test
    void test() {
        System.out.println("test1 = " + ac);
    }
}

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {Hello.class})
public class Sample2 {

    @Autowired
    private Nested nested;

    @Autowired
    ApplicationContext ac;

    @Test
    void test() {
        System.out.println("test2 = " + ac);
    }
}

둘 다 GenericApplicationContext@75437611이라는 동일한 applicationContext 객체를 사용하는 것을 볼 수 있다.

 

@ContextConfiguration 어노테이션 대신에 @SpringBootTest를 사용하는 테스트 클래스를 하나 더 추가해보자.

@SpringBootTest
@ExtendWith(SpringExtension.class)
public class Sample3 {

    @Autowired
    private Nested nested;

    @Autowired
    ApplicationContext ac;

    @Test
    void test() {
        System.out.println("test3 = " + ac);
    }
}

 

확인해보면 @SpringBootTest를 사용한 test3만 다른 ApplicationContext 객체를 사용하는 것을 볼 수 있다.

 

💡 만약 @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)을 사용하게 된다면 실제 웹 환경이 구성되기 때문에 다른 컨텍스트 정보를 지정하게 되면 다른 웹 서버가 띄워지게 된다. 

 

---

 

🌱 컨텍스트 강제 초기화하기 - @DirtiesContext

만약 강제로 컨텍스트를 제거하고 싶다면 클래스, 혹은 메서드 레벨에 @DirtiesContext 어노테이션을 추가하면 된다.

이러면 동일한 애플리케이션 컨텍스트를 사용하더라도 테스트 실행 전에 강제적으로 기존 컨텍스트를 제거하고 새로운 컨텍스트를 실행해준다.

 

 

💬 새로운 스프링 컨테이너에서 테스트를 실행하고 싶은 경우 

// 현재 테스트 클래스 이전에 컨텍스트를 더티 처리
@DirtiesContext(classMode = BEFORE_CLASS) 
class FreshContextTests {
}

// 각각의 테스트 메서드 전에 컨텍스트를 더티 처리
@DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD)
class FreshContextTests {
}

// 현재 테스트 메서드 이전의 컨텍스트를 더티 처리
@DirtiesContext(methodMode = BEFORE_METHOD) 
@Test
void testProcessWhichRequiresFreshAppCtx() {
}

 

💬 스프링 컨텍스트를 더럽히는 동작을 내부적으로 수행할 것 같을 때

// 현재 클래스 이후에 컨텍스트를 더티 처리
@DirtiesContext 
class ContextDirtyingTests {
}

// 각각의 테스트 메서드 후에 컨텍스트를 더티 처리
@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
class ContextDirtyingTests {
}

// 현재 테스트 메서드 이후의 컨텍스트를 더티 처리
@DirtiesContext 
@Test
void testProcessWhichDirtiesAppCtx() {
}

 

💡 페어랑 얘기하면서 언제 @DirtiesContext를 사용할 수 있을지 이야기를 나누어보았다.

다른 분들은 데이터베이스 초기화를 위해서 사용하신다고 말씀하셨는데, 사실 @DirtiesContext의 경우 새로운 서버를 띄우면서 (기존의 서버를 닫고) 인메모리 데이터베이스를 새롭게 띄우게 되다 보니까 데이터베이스가 초기화된다고 생각했다. 그렇다면 만약 서버를 띄워도 초기화되지 않는 데이터베이스를 사용한다면 (프로파일별로 다른 DB를 사용할 경우...) @DirtiesContext을 사용하더라도 초기화가 안 될 것 같다고 생각했다.

벨덩 같은 글을 보면 싱글톤 빈이 상태를 가지고 있는 경우 내부적으로 해당 빈을 조작했을 때 applicationContext를 강제적으로 초기화하려면 사용하라는 말이 있었는데, 애초에 싱글톤 빈이 상태를 가지고 있는 것 자체가 잘못된 설계라는 생각도 들고... 어렵다 🥲 앞으로 사용할 일이 있을까?... 모르겠다.

 

---

 

🌱 스프링 부트와 테스트

사실 위에서 언급한 내용은 단순히 '스프링 프레임워크'를 사용했을 때의 일이다.

하지만, 스프링 부트에서는 애플리케이션 테스트 시 도움이 되는 다양한 유틸리티와 어노테이션을 지원한다.

특히, spring-boot-starter-test dependency를 사용하게 되면 Junit, AssertJ 같은 유용한 라이브러리들도 함께 사용할 수 있다!

 

 

💬 @SpringBootTest

위에서 언급했던 스프링 프레임워크 표준 어노테이션인 @ContextConfiguration 대신 @SpringBootTest 어노테이션을 활용할 수 있다. @SpringBootTest 애노테이션의 경우 기본적으로는 서버를 시작하지 않지만, webEnvironment 옵션을 통해서 어떤 식으로 테스트 환경을 조성할지 설정할 수 있다.

MOCK (기본값)

: ApplicationContext을 로드라고 가짜 웹 환경을 구성한다. 내장 서버가 시작되지 않으며, mock-based의 웹 애플리케이션의 테스트를 하기 위해서 @AutoConfigureMockMvc 또는 @AutoConfigureWebTestClient와 함게 사용할 수 있다.

RANDOM_PORT

WebServerApplicationContext를 로드하고, 실제 웹 환경을 제공한다. 내장 서버가 실행되고, 임의의 포트에서 실행된다.

- 만약, 사용한 포트 정보가 궁금하다면 @LocalServerPort 어노테이션을 통해서 해당 포트 정보를 얻어올 수 있다. (@Value("${local.server.port}")와 완전히 동일한 역할을 한다.)

 

DEFINED_PORT

WebServerApplicationContext를 로드하고 실제 웹 환경을 제공하며, 내장 서버가 실행되지만 application.yml에 지정한 포트나 기본 포트인 8080을 사용한다.

 

NONE

ApplicationContext를 로드하지만 웹 환경을 구축하지 않는다.

 

⭐️ 만약, @Transactional을 테스트 메서드에 적용할 경우, 각 테스트 메서드가 끝날 때 롤백된다. 하지만 RANDOM_PORT, DEFINED_PORT를 통해 실제 웹 환경을 사용하게 되면 트랜잭션이 잡힌 테스트 메서드의 스레드와 웹 서버의 스레드가 다르기 때문에 별도의 트랜잭션에 실행되어 테스트 메서드에서 실행된 메서드의 경우 트랜잭션 롤백이 되지 않는다.

 

 

💬 @WebMvcTest

Spring MVC 인프라를 자동을 구성하고, 웹 계층에서 사용하는 컴포넌트들을 스캔한다.

이때 스캔되는 컴포넌트는 @Controller, @ControllerAdvice, @JsonComponent, Converter, GenericConverter, Filter, HandlerInterceptor, WebMvcConfigurer, WebMvcRegistrations 및 HandlerMethodArgumentResolver 등이 사용되며, 우리가 흔히 사용하는 @Service, @Component, @Repository가 붙은 클래스들은 스캔 대상이 아니다.

 

이게 무슨 소리인지 이해하기 어려울 수 있다. 코드를 통해 확인해보자.

@Controller
public class SampleController {
    void test() {

    }
}

테스트용 컨트롤러이다. 그리고, 해당 컨트롤러를 테스트하기 위한 테스트용 메서드를 생성해보자.

@WebMvcTest
class SampleControllerTest {

    @Autowired
    private SampleController sampleController;

    @Test
    void test() {

    }
}

단순히 @WebMvcTest만 생성하고, @Autowired를 통해 주입받으면 아무 오류 없이 잘 동작한다.

 

하지만, SampleController 클래스의 어노테이션을 @Service로 만들어보자.

@Service
public class SampleController {

    void test() {

    }
}

 

Error creating bean with name 'com.example.study.SampleControllerTest': Unsatisfied dependency expressed through field 'sampleController': No qualifying bean of type 'com.example.study.SampleController' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}

그러면 위와 같이 적절한 빈이 없다는 오류 메시지가 나온다.

즉, @Service의 경우 스캔 대상이 아니기 때문에 빈으로 생성되지 않아 의존 관계를 주입받을 수 없는 것이다.

 

그래서 나는 위와 같은 경우에 보통 2가지 솔루션을 사용하였다.

 

1. 인자로 대상 클래스를 지정해주기

@WebMvcTest(SampleController.class)
class SampleControllerTest {

    @Autowired
    private SampleController sampleController;

    @Test
    void test() {
    }
}

 

2. Mock 객체로 선언해주기

@ExtendWith(MockitoExtension.class)
class SampleControllerTest {

    @InjectMocks
    private SampleController sampleController;

    @Test
    void test() {
    }
}

개인적으로 미션을 진행하면서 페어에게 @WebMvcTest의 경우 컨트롤러 계층을 테스트할 때 사용하는 게 좋을 것 같다는 이야기를 들었어서, 두 번째 방법으로 서비스 레이어를 테스트하곤 했다.

 

 

💬 @JdbcTest

@JdbcTest 어노테이션의 경우 기본적으로 내당 데이터베이스 및 JdbcTemplate 빈을 구성한다.

DB 레이어를 테스트할 때 많이 사용하며, 내부적으로 @Transactional 어노테이션이 선언되어 있기 때문에 클래스 레벨에 붙이면 각 테스트 메서드가 종료될 때 함께 롤백된다.

여기서 @AutoConfigureJdbc 어노테이션을 통해서 Jdbc 와 관련된 빈들만 컨텍스트로 등록된다.

 

또한, @AutoConfigureTestDatabase 어노테이션 덕분에 인메모리 데이터베이스를 사용할 수 있게 된다.

참고로, 이 어노테이션의 경우 replace 옵션에 따라서 인메모리 데이터베이스를 사용할지 말지 결정할 수 있다.

 

@JdbcTest
@AutoConfigureTestDatabase
class SampleControllerTest {

    @Test
    void test() {
    }
}

간단하게 살펴보자. 해당 어노테이션을 사용한 결과이다. (사용하지 않은 경우에도 @JdbcTest에 의해서 지정된 것과 같은 효과)

- 참고로, Replace 옵션은 기본적으로 Any이다. Any의 경우 자동으로 구성된 정보를 사용하거나, 혹은 수동으로 구성된 정보를 사용한다.

확인해보면 다른 인메모리 데이터베이스를 사용하는 것을 볼 수 있다.

 

@JdbcTest
@AutoConfigureTestDatabase(replace = Replace.NONE)
class SampleControllerTest {

    @Test
    void test() {
    }
}

반면에, Replace를 NONE으로 해보자.

이때는 application.yml에 정의한 database를 사용하게 된다.

 

 

 

💬 @DataJdbcTest

@DataJdbcTest의 경우 @JdbcTest와 거의 비슷하긴 하다.

하지만 딱 한 가지 다른 점이 있는데, @AutoConfigureDataJdbc라는 어노테이션이다.

이는 Spring Data JDBC repositories를 사용하는 테스트에서 사용한다.

사용해본 적이 없어서 좀 찾아봤는데, JPA랑 문법이 거의 비슷한 것 같다. 

알아보고 싶다면 공식 문서를 보는 것도 좋을 것 같다.

 

---

 

테스트 쪽은 파고 팔수록 내용이 너무 많아서 자르기가 힘들다 ㅠ_ㅠ

그래도 기술 부채 중 하나였는데 가볍게 잘 보고 넘어가는 것 같다!