[Spring] 통합 테스트 환경에서 로직의 일부를 stubbing 하기

 

🌱 들어가기 전

통합 테스트를 하다 보면, 실제 빈 중에 일부만 stubbing을 하고 싶은 상황이 생긴다.
예를 들어, 외부 API를 통신하거나 외부 시스템을 활용하게 되면 테스트에서 그대로 활용하기 어려운데, 해당 부분에 대해서만 우리가 원하는 시나리오를 제공하여 우리 애플리케이션이 잘 동작하는지 확인하고 싶을 수 있다. 하지만, 보통 Spring Context에서는 동일한 이름을 가진 빈을 그대로 등록하게 되면 오류가 발생하기 때문에, 몇 가지 특별한 조치를 해주어야 하는데 한 번 살펴보자.

 

 

☁︎ 테스트 시나리오

 - 사용자가 상품을 구매하게 되면, 외부 API를 호출하여 재고가 존재하는지 확인한다.
  - 만약 재고가 존재하면 외부 API는 ‘SUCCESS’라는 응답을, 재고가 존재하지 않으면 ‘FAIL’이라는 응답을 반환한다.
- 우리는 여기에서 ‘외부 API가 SUCCESS 혹은 FAIL’이라는 응답을 반환하는 부분에 대해서 stubbing을 진행할 것이다.

 

위의 시나리오를 만들기 위한 간단한 코드를 작성해보자.
본 글에서는 아키텍처나 세부 코드에 대한 구현은 중요하지 않기 때문에 가장 기본적인 코드로 작성하였다.

 

✔️ 기본 코드

@RestController
class OrderController(
    private val orderService: OrderService,
) {

    @PostMapping("/order")
    fun order(
        @RequestBody request: OrderRequest
    ) {
        orderService.order(request.productId)
    }
}

data class OrderRequest(
    val productId: Long,
)

@Service
class OrderService(
    private val externalStockCheckApi: ExternalStockCheckApi
) {

    fun order(productId: Long) {
        val result = externalStockCheckApi.check(productId)
        if (result == StockStatus.FAIL) {
            throw OutOfStockException("재고가 없습니다.")
        }
        otherLogic()
    }

    private fun otherLogic() {
        // do something...
    }
}

class OutOfStockException(
    override val message: String
) : RuntimeException(message) {
}

여기에서 otherLogic의 경우 매우 복잡한 비즈니스 로직을 담는다고 가정한다.

실패의 케이스에 대해서도 복잡한 경우가 포함되지만, 여기에서는 간단하게 예외만 발생시키도록 제어를 해두었다.

@Component
class ExternalStockCheckApi {
    fun check(productId: Long): StockStatus {
        return callExternalApi(productId)
    }

    private fun callExternalApi(productId: Long): StockStatus {
        // call external api...
        if (Random().nextInt() % 2 == 0) {
            return StockStatus.SUCCESS
        }
        return StockStatus.FAIL
    }
}

enum class StockStatus {
    SUCCESS,
    FAIL
}

ExternalStockCheckApi 의 경우, 실제로는 외부 API와 통신하는 구간이다.

현재 우리의 코드에서는 해당 부분은 중요하지 않기 때문에 제외하고, 그냥 랜덤한 값에 따라서 성공과 실패에 대해서 반환하도록 수정하였다.

우리는 위와 같은 코드가 있을 때, `ExternalStockCheckApi`의 결과를 제어하여 우리의 애플리케이션이 의도하는대로 잘 동작하는지를 확인해볼 예정이다. 또한, 단위 테스트가 아닌 통합 테스트를 활용할 예정이다. 물론, 테스트의 방법에는 여러 가지가 있고, 단위 테스트를 활용해서 우리의 애플리케이션을 검증하는 것도 가능하다.

 

그러나, 실제로 복잡한 비즈니스를 가지고 있는 경우에는 상당히 많은 빈들이 서로 협력하여 동작하게 된다. 모든 빈에 대해서 단위 테스트를 작성하여 각각의 컴포넌트들에 대한 정상적인 동작을 판단할 수도 있지만, 해당 컴포넌트들의 단위 테스트가 작성되지 않은 상황이거나 각 컴포넌트들간의 정상적인 협력 관계가 잘 동작하고 있는지 판단하고 싶을 때는 통합 테스트가 좋은 방법이 될 수 있다.

 

그렇다면, ‘테스트 환경에서도 실제 외부 API를 호출하면 되지 않는가?’ 라고 생각할 수 있다. 그러나, 만약 외부 API가 일시적으로 장애가 발생했어서 늘 통과하던 테스트가 갑자기 통과하지 않는다면 어떻게 될까? 테스트의 경우 늘 일관적인 시나리오로 동작해야 하기 때문에 이에 대해 위배하게 된다. (FIRST 원칙, 물론 이는 단위 테스트에 대한 원칙이지만 그래도 살짝 인용하자면 그렇다.)

 

또한, 사업적인 관점으로 봤을 때 외부 API에 대한 호출 비용을 받는 곳이라면? 테스트 할 때마다 비용 지출이 발생할 수 있기 때문에 어느 정도의 stubbing은 필요한 상황이다. (실제로 사내에서 동일한 케이스가 있어서, 테스트 환경에서는 아예 dummy 값을 내려주도록 처리하는 부분도 존재한다.)

 

아무튼, 위의 시나리오를 판단하기 위한 간단한 테스트 코드를 작성해보자. RestAssured를 활용하여 작성해주었다.

테스트 설정 방법에 대해서는 다음 포스팅에서 조금 더 다루어보고자 한다.

 

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
class OrderControllerTest() {

    @LocalServerPort
    private var port: Int = 0

    @BeforeAll
    fun setUp() {
        RestAssured.port = port
    }

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }

    @Test
    fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
        val result = callOrderApi(2L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
    }

    private fun callOrderApi(
        productId: Long
    ): ExtractableResponse<Response> {
        return RestAssured.given()
            .given().log().all()
            .contentType("application/json")
            .body(
                mapOf("productId" to productId)
            )
            .`when`()
            .post("/order")
            .then().log().all().extract()
    }
}

우리가 원하는 시나리오는 위와 같은 2가지 상황을 테스트 할 수 있다.
- 재고가 존재하는 경우 아무 오류도 발생하지 않음
- 재고가 존재하지 않는 경우 예외가 발생함

 

당연히 현재의 테스트 코드는 깨지는 것이 맞다.

---

🌱 @MockBean을 활용하여 재정의하기

 

☁︎ @MockBean이 무엇일까?

먼저, 첫 번째 방법으로는 @MockBean을 활용하여 `ExternalStockCheckApi` 에 대해 재정의를 할 수 있다.

@MockBean의 경우 Spring 1.4에서 추가된 테스트 서포팅용 어노테이션으로, 스프링의 ApplicationContext에 mocking 된 객체를 추가하는데 사용하는 어노테이션이다. 빈의 타입이나 이름으로 등록이 가능하며, 기존의 컨텍스트에서 일치하는 빈에 대해서 mock 빈으로 대체하게 만들어준다. 만약 기존에 빈이 존재하지 않는다면 새로운 빈으로 추가하여 등록해준다.

Junit4를 사용한다면 `@RunWith(SpringRunner.class)`와 함께, Junit5를 사용한다면 `@ExtendWith(SpringExtension.class)` 와 함께 사용할 수 있다. 나는 @SpringBootTest 어노테이션을 사용할 예정이기 때문에 따로 붙여주지는 않았다.

참고로, 이러한 @MockBean의 경우 `MockitoTestExecutionListener` 에 의해서 처리되고 있다.

`MockitoTestExecutionListener` 의 경우 `AbstractTestExecutionListener` 을 상속받았으며, 테스트 컨텍스트를 활용하여 테스트 코드 수행 시 어떤 전처리 / 후처리를 진행할지 정해줄 수 있다.

 

public class MockitoTestExecutionListener extends AbstractTestExecutionListener {

    @Override
    public void prepareTestInstance(TestContext testContext) throws Exception {
        closeMocks(testContext);
        initMocks(testContext);
        injectFields(testContext);
    }
}

private void initMocks(TestContext testContext) {
    if (hasMockitoAnnotations(testContext)) {
        testContext.setAttribute(MOCKS_ATTRIBUTE_NAME, MockitoAnnotations.openMocks(testContext.getTestInstance()));
    }
}

private void injectFields(TestContext testContext) {
    postProcessFields(testContext, (mockitoField, postProcessor) -> postProcessor.inject(mockitoField.field,
    mockitoField.target, mockitoField.definition));
}

private void postProcessFields(TestContext testContext, BiConsumer<MockitoField, MockitoPostProcessor> consumer) {
    DefinitionsParser parser = new DefinitionsParser();
    parser.parse(testContext.getTestClass());

    if (!parser.getDefinitions().isEmpty()) {
        MockitoPostProcessor postProcessor = testContext.getApplicationContext()
            .getBean(MockitoPostProcessor.class);

        for (Definition definition : parser.getDefinitions()) {
            Field field = parser.getField(definition);
            if (field != null) {
                consumer.accept(new MockitoField(field, testContext.getTestInstance(), definition), postProcessor);
            }
        }
    }
}

testContext를 활용하면 테스트 코드에 선언된 어노테이션 정보를 읽어올 수 있기 때문에, mockito 기반 어노테이션들을 찾아서 mock field로 주입해주는 것을 확인할 수 있다.

 

☁︎ 실제로 적용해보기

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
class OrderControllerTest(
    @MockBean
    private val externalStockCheckApi: ExternalStockCheckApi
) {

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        Mockito.`when`(
            externalStockCheckApi.check(anyLong())
        ).thenReturn(StockStatus.SUCCESS)

        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }

    @Test
    fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
        Mockito.`when`(
            externalStockCheckApi.check(anyLong())
        ).thenReturn(StockStatus.FAIL)

        val result = callOrderApi(2L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
    }
}

Mockito.when().thenReturn()을 사용하면 mockBean으로 등록된 mock 객체에 대해서 쉽게 stubbing을 진행할 수 있다.

when절에는 우리가 스터빙을 진행하고 싶은 메서드를 입력하고, then 절에는 해당 상황에서 어떤 값을 반환하면 좋을지 작성해주면 된다. thenReturn 외에도 thenThrow, thenAnswer 등으로 더 유연한 테스트 코드를 작성할 수 있다.

 

 

☁︎ 단점은 없을까?

아쉽게도, @MockBean을 활용하게 되면 스프링 컨텍스트를 재사용할 수 없는 문제가 발생한다.

우선, @MockBean을 사용하게 되면 테스트 클래스를 수행할 때마다 Spring Context에 대해 refresh를 진행하는데, 이는 위에 첨부해둔 `postProcessFields()` 함수의 다음과 같은 부분을 살펴보면 알 수 있다.

// postProcessFields 
if (!parser.getDefinitions().isEmpty()) {
    MockitoPostProcessor postProcessor = testContext.getApplicationContext()
        .getBean(MockitoPostProcessor.class);
}

// DefaultTestContext.getApplicationContext
@Override
public ApplicationContext getApplicationContext() {
    ApplicationContext context = this.cacheAwareContextLoaderDelegate.loadContext(this.mergedConfig);
    ...
}

// DefaultCacheAwareContextLoaderDelegate.loadContext
@Override
public ApplicationContext loadContext(MergedContextConfiguration mergedConfig) {
    ...
    synchronized (this.contextCache) {
        ApplicationContext context = this.contextCache.get(mergedConfig);
        ...
        context = loadContextInternal(mergedConfig);
        ...
    }


    protected ApplicationContext loadContextInternal(MergedContextConfiguration mergedConfig) throws Exception {
        ContextLoader contextLoader = getContextLoader(mergedConfig);
        if (contextLoader instanceof SmartContextLoader smartContextLoader) {
            return smartContextLoader.loadContext(mergedConfig);
        }
        ...
    }

    // SpringBootContextLoader.loadContext
    private ApplicationContext loadContext(MergedContextConfiguration mergedConfig, Mode mode,
        ApplicationContextInitializer<ConfigurableApplicationContext> initializer) throws Exception {
        ...
        return hook.run(() -> application.run(args));
    }

    // SpringApplication.run
    public ConfigurableApplicationContext run(String... args) {
    refreshContext(context);
}

여기에서 테스트 컨텍스트 내에 있는 applicationContext를 꺼내오는 것을 알 수 있는데, 내부로 타고 들어가게 되면 context에 대해 refresh를 하는 것을 볼 수 있다.
코드의 중간 부분을 보면 스프링에서는 최대한 캐시된 테스트 컨텍스트를 사용하려고 하지만 (contextCache 같은 필드들이 존재하는 걸 볼 수 있다), @MockBean을 사용하게 되면 해당 빈 뿐만 아니라 해당 빈을 사용하는 다른 친구들도 모두 교체해줘야 하기 때문에 캐시를 하지 않고 아예 refresh를 해주는 것을 볼 수 있다.

 

class A(val b: B) 와 같은 코드가 있을 때, B가 mockBean이라면 자연스럽게 B를 의존하고 있는 A 역시 mocking된 B를 사용할 수 있도록 교체 작업이 필요해진다. 만약 빈끼리 더 복잡한 의존 관계를 가지고 있다면 자연스럽게 더 많은 빈들에 대해서 교체하는 작업이 필요해질 것이다.

 

참고로, 기본적으로 스프링의 context caching의 경우 다음과 같은 상황에 대해서 발생한다.
  - 동일한 bean의 조합을 사용했을 때
  - 이전의 테스트에서 applicationContext가 오염되지 않은 경우
  - @DirtyContext 를 활용하지 않는 경우

---

🌱 @Profile 설정을 통해서 테스트용 빈을 분리하기

만약, 위와 같은 spring context refresh가 싫다면, 테스트에서 사용할 프로파일을 지정해주고 해당 프로파일에서는 다른 동작을 하도록 만들어 줄 수 있다. 하지만, 스프링에서는 기본적으로 동일한 이름을 가진 빈을 2개 띄울 수 없다. 이를 위해 `ExternalStockCheckApi`를 인터페이스로 분리해주는 작업을 진행해주자. 인터페이스의 경우 구체적인 행위가 들어나지 않도록, 재고를 확인하는 용도의 기능 정도만 나타내 줄 수 있도록 만들었다.

 

interface CheckStockPort {
    fun check(productId: Long): StockStatus
}

 그리고, @Profile 어노테이션을 활용하여 profile 별로 다른 코드가 동작할 수 있도록 만들어주자.

@Component
@Profile("!test")
class ExternalStockCheckApi: CheckStockPort {
    override fun check(productId: Long): StockStatus {
        return callExternalApi(productId)
    }
}

@Component
@Profile("test")
class TestStockCheckApi: CheckStockPort {
    override fun check(productId: Long): StockStatus {
        if (productId == 1L) {
            return StockStatus.SUCCESS
        }
        return StockStatus.FAIL
    }
}

기존의 ExternalStockCheckApi 에 대해서 CheckStockPort 을 오버라이드 하도록 만들고, 특정 Test 프로파일에 대해서는 TestStockCheckApi 가 동작하도록 만들었다.

그리고, 우리의 테스트 시나리오에 맞춰 productId 별로 다른 결과가 나타날 수 있도록 만들었다.

기존에 ExternalStockApi를 의존하던 서비스 코드 역시 인터페이스를 의존하도록 변경해주자.

 

@Service
class OrderService(
    private val checkStockPort: CheckStockPort,
) {

    fun order(productId: Long) {
        val result = checkStockPort.check(productId)
        ...
    }
}

 

그리고, 다시 테스트 코드로 돌아가서 ‘test’라는 profile을 가질 수 있도록 @ActiveProfiles 어노테이션을 추가해주도록 하자.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@ActiveProfiles("test")
class OrderControllerTestV2 {

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }

    @Test
    fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
        val result = callOrderApi(2L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
    }
}

이러면 @MockBean을 사용하지 않더라도 깔끔하게 테스트 코드를 작성할 수 있으며, 테스트 시나리오에 따라서 테스트용 빈이 어떤 행위를 수행할지 설정해준다면 동일한 컨텍스트를 가지도록 재사용도 할 수 있기 때문에 테스트 성능 역시 올릴 수 있다.

 

---

 

🌱 @TestConfiguration 활용해주기

위와 같이 Profile 어노테이션을 활용하는 방법도 있지만, @TestConfiguration 을 활용해서도 다른 빈을 사용하도록 제어할 수 있게 된다. 만약, 운영 코드와 테스트 코드를 완전히 분리하고 싶다면 테스트용 빈을 등록해주도록 하자.

 

기존의 코드의 경우 운영 코드에서 컴포넌트 스캔으로 인해서 `TestStockCheckApi` 가 빈으로 등록이 되었었는데, 테스트 컨텍스트 내에서만 빈으로 등록하도록 만들어보자. 먼저, @TestConfiguration을 활용하여 테스트용 빈을 선언해주자.

 

@TestConfiguration
class TestConfig {

    @Bean
    fun checkStockPort() : CheckStockPort {
        return TestStockCheckApi()
    }
}

class TestStockCheckApi: CheckStockPort {
    override fun check(productId: Long): StockStatus {
        if (productId == 1L) {
            return StockStatus.SUCCESS
        }
        return StockStatus.FAIL
    }
}

만약 동일한 타입의 빈을 등록해줄 일이 있다면 @Primary를 활용하여 적절하게 조절하자.

그리고, 테스트 코드에서 @Import를 통해서 (혹은 @ContextConfiguration을 활용해도 된다) 해당 Configuration 에 대해 로드를 해준다.

 

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
//@ContextConfiguration(classes = [TestConfig::class])
@Import(TestConfig::class)
class OrderControllerTestV3 {

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }

    @Test
    fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
        val result = callOrderApi(2L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
    }
}

이렇게 하면 @Profile 어노테이션과 동일하게 테스트용 checkStockPort 을 사용할 수 있게 된다.

 

☁︎ @ConditionalOnProperty 활용하기

또한, @TestConfiguration과 @ConditionalOnProperty 2가지의 어노테이션을 조합해서 다음과 같이 코드를 구성해볼 수도 있다. 대신 조금 더 복잡도가 높아지기 때문에 그냥 이런 방법도 있다는 정도만 넘어가도 될 것 같다.
먼저, 운영 코드에서 다음과 같이 `@ConditionalOnProperty` 를 활용하여 특정 프로퍼티가 존재할 때 해당 빈을 사용할 수 있도록 수정해주자.

@Component
@ConditionalOnProperty(name = ["check-stock.test"], havingValue = "false")
class ExternalStockCheckApi: CheckStockPort {
    override fun check(productId: Long): StockStatus {
        return callExternalApi(productId)
    }
}

여기에서는 `check-stock.test` 라는 프로퍼티가 false인 경우에 운영 코드가 동작할 수 있도록 설정해주었다.

 

그리고, 테스트 코드를 조금 수정해주자. 우선, 프로퍼티 값을 사용하는 김에 해당 프로퍼티 값에 따라서 success를 응답하는 외부 API와 fail을 응답하는 외부 API 빈으로 분리하고자 한다. 이를 위해 Conditional 인터페이스를 활용해줄 수 있다.

class CheckStockSuccessCondition : Condition {
    override fun matches(context: ConditionContext, metadata: AnnotatedTypeMetadata): Boolean {
        val environment = context.environment
        val checkStockTest = environment.getProperty("check-stock.test") == "true"
        val checkStockResultSuccess = environment.getProperty("check-stock.result-success") == "true"
        return checkStockTest && checkStockResultSuccess
    }
}

class CheckStockFailCondition : Condition {
    override fun matches(context: ConditionContext, metadata: AnnotatedTypeMetadata): Boolean {
        val environment = context.environment
        val checkStockTest = environment.getProperty("check-stock.test") == "true"
        val checkStockResultFailure = environment.getProperty("check-stock.result-success") == "false"
        return checkStockTest && checkStockResultFailure
    }
}

 

`check-stock.test` 프로퍼티가 true이면서, `check-stock.result-success` 프로퍼티가 true인지 false인지에 따라서 Condition을 검증하는 로직이다. 그리고, 다음과 같이 빈을 등록해주자.

@TestConfiguration
class TestConfigV2 {

    @Bean(name = ["checkStockPort"])
    @Conditional(CheckStockSuccessCondition::class)
    fun checkStockPortReturnSuccess(
        environment: Environment
    ): CheckStockPort {
        return object : CheckStockPort {
            override fun check(productId: Long): StockStatus {
                return StockStatus.SUCCESS
            }
        }
    }

    @Bean(name = ["checkStockPort"])
    @Conditional(CheckStockFailCondition::class)
    fun checkStockPortReturnFail(
        environment: Environment
    ): CheckStockPort {
        return object : CheckStockPort {
            override fun check(productId: Long): StockStatus {
                return StockStatus.FAIL
            }
        }
    }
}

 둘 다 ‘checkStockPort’ 라는 이름으로 빈 등록이 될 수 있게 네임 지정을 해주고, 각각의 조건이 true일 때 해당 빈을 활용할 수 있도록 @Conditional 어노테이션을 활용해주었다.

마지막으로, 테스트에서 해당 빈 정보를 활용할 수 있도록 import 하고, 프로퍼티를 주입해주자. 프로퍼티 주입을 위해서 여러 방법이 있겠지만, 나는 @SpringBootTest가 제공하는 프로퍼티 속성을 활용하여 주입해주었다.

다만, 이러다 보니까 실패와 성공 케이스에 대해 각각 테스트 클래스를 분리하였다. 이런 방법도 있을 뿐이지, 실제로 활용하기에는 효용이 좋을지는 잘 모르겠다. (정말 이런 방법이 있기만 하다는 것 정도만 인지하자!)

@SpringBootTest(
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
    properties = ["check-stock.test=true", "check-stock.result-success=true"]
)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@Import(TestConfigV2::class)
class OrderControllerTestV4_success {

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }
}

@SpringBootTest(
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
    properties = ["check-stock.test=true", "check-stock.result-success=false"]
)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@Import(TestConfigV2::class)
class OrderControllerTestV4_fail {
    ...
}

 

---

🌱 mock 객체를 활용하기

다음으로, 만약 테스트 상황에 따라 여러 시나리오를 반환하고 싶을 때 사용할 수 있는 방법이 있다.

이때는 테스트용 빈을 등록할 때 테스트 클래스가 아닌, mock 객체를 반환해주면 된다.

@TestConfiguration
class TestConfigV3 {

    @Bean
    fun checkStockPort() : CheckStockPort {
        return Mockito.mock(CheckStockPort::class.java)
    }
}

 

만약 kotest를 활용한다면 mockk<CheckStockPort> 를 활용하여 반환해줄 수 있다.
그리고, 테스트 코드에서 checkStockPort를 주입해주자. 이러면 위에서 선언한 mock 객체가 반환된다.

 

@SpringBootTest(
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@Import(TestConfigV3::class)
class OrderControllerTestV5(
    private val checkStockPort: CheckStockPort,
) {

}

이 상황에서 그냥 테스트를 돌리면 어떻게 될까?

mocking된 객체에 대해서 하는 일을 지정해주지 않았기 때문에 결과로 null을 반환하게 되며, 당연하게도 테스트도 실패한다.
이를 위해, 각 테스트 시나리오에 맞춰 어떤 행위를 할지 지정해주도록 하자.

@Test
fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
    Mockito.`when`(
        checkStockPort.check(Mockito.anyLong())
    ).thenReturn(StockStatus.SUCCESS)

    val result = callOrderApi(1L)
    assertThat(result.statusCode())
        .isEqualTo(HttpStatus.OK.value())
}

@Test
fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
    Mockito.`when`(
        checkStockPort.check(Mockito.anyLong())
    ).thenReturn(StockStatus.FAIL)

    val result = callOrderApi(2L)
    assertThat(result.statusCode())
        .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
}

Mockito의 When, ThenReturn 절을 활용하면 어떤 행위를 할지 지정해줄 수 있으며, 만약 kotest를 사용 중이라면 every - returns를 사용하여 해주면 된다.

 

---

🌱 마무리

요즘 회사에서 통합 테스트를 자주 짜려고 노력 중인데, 한 번 구축하고 나니까 다음 번에 테스트를 짤 때 더 금방 짤 수 있는 것 같다.
개인적으로는 위 4가지 방법 중에서 2번과 4번을 많이 쓰고 있다.
2번은 슬랙 메시지나 금원 지급, 외부 API를 호출해야 하는 상황 등등, 테스트에서 반드시 호출이 되지 않을 필요가 있거나 고정된 특정한 응답이 필요한 경우 사용하고, 4번은 외부 API이지만 해당 API가 어떤 응답을 내려주는지에 따라서 핵심 비즈니스 로직이 달라지는 경우 시나리오별로 정의하기 위해서 사용하고 있다.

 

요즘 테스트 속도에 대해서도 고민이 많아서, 아예 테스트용 빈을 관리하는 @TestConfiguration 클래스를 생성한 다음에, 모든 클래스에서 재사용할 수 있도록 만들어서 속도를 개선해볼까도 고민 중이다. 또한, 개인적으로는 kotest를 선호하는 편이라서 mockk와 함께 조합해서 많이 사용하고 있다.

 

오랜만에 블로그 글을 작성해서 어색한데, 얼른 다른 글도 작성할 수 있도록 노력해야겠다... 끝!