[Kotlin Test] 1. mockK & lateinit

Damongsanga·2024년 10월 30일
kotlinmockk
1

kotlin 테스트 환경 구축하기

목록 보기
1/2

입사하면서 코틀린을 시작하여, 사용한지 2달밖에 되지 않아 어려움이 있지만, 그만큼 재미있게 배우고 있습니다 :)

사내에서 Java & Mybatis 에서 Kotlin & Jpa 전환을 진행하면서, 코틀린 테스트코드에 대한 기틀을 잡아가고 있습니다. 이 과정에서 코틀린 테스트 환경 구축을 주도적으로 하며, kotest + mockK + fixture 적용 가이드를 작성하였고, 배우고 적용했던 내용을 부서분들에게 공유하는 시간을 가졌습니다.

그 내용들을 나누어 올려볼까 합니다.

1. MockK

1.1. Mock vs MockK

  • Kotlin 프로젝트에서는 MockK를 사용하자!
  • MockK가 Kotlin 호환성이 높은 라이브러리
  • 특징
    • Kotlin에서 사용되는 다양한 기능 (Null-Safety, Extension Function, Coroutine, Data class) 지원
    • DSL (Domain Specific Language) 제공 (every, verify 등)
    • Mock보다 더 직관적
    • 높은 성능 (Kotlin의 Inline Function 및 Inline Class 기능을 사용하여 런타임 오버헤드를 최소화)

1.2. mockK() vs @MockK vs @MockKBean 차이점 정리

1. mockk()

: 독립적인 객체 모킹. Spring Context 외부에서 사용.

  1. 사용 예시 : private val userRepository: UserRepository = mockk(relaxed = true)

  2. relaxed = true 옵션

    1. mockk(relaxed = true) : primitive 값들은 기본값을 반환하도록 함 (0, false, “”)

    2. 만약 relaxed = true 옵션을 주지 않고 stub하지 않은 메서드를 호출하면 “목킹을 했으나 해당 목킹에 대한 반환값이 정해지지 않았다”는 에러 반환

    3. 언제 사용해야 하는가?
      - relaxed : 간단한 테스트나 빠른 테스트 개발이 필요할 때 → 기본값을 반환함으로서 유연하고 빠른 테스트 작업을 반환할 수 있음
      - default: 엄격한 테스트나 특정 동작을 명확하게 검증해야 하는 경우 → 실수로 잘못된 메서드를 호출했을 때 이를 인지하기 어려울 수 있음

2. @MockK

JUnit, Kotest 등의 테스트 프레임워크( Spring Context 외부) 에서 특정 객체를 모킹할 때 사용.

  1. @MockK lateinit var displayCommentService: DisplayCommentService

  2. mockk()처럼 동작하지만, 필드를 위한 모킹을 자동화. 클래스 필드에 mock 객체를 자동 주입

  3. 객체 초기화 필요: @MockK는 기본적으로 초기화되지 않으므로, 테스트 클래스에 @ExtendWith(MockKExtension::class)나 MockKAnnotations.init(this)를 호출하여 초기화해야

  4. @RelaxedMockK : relaxed = true 설정된 MockK임 (@MockK(relaxed=true) 와 동일)

  5. @MockK와 @RelaxedMockK과의 차이에 대해 더 자세히 알고 싶으면 해당 글 참고

@MockK 예시 코드

abstract class UnitTest {
    @Rule
    @JvmField
    val injectMocks = TestRule { statement, _ ->
        MockKAnnotations.init(this, relaxUnitFun = true)
        statement
    }
}

class SampleViewModelTest : UnitTest() {

    private lateinit var viewModel: SampleViewModel

    @MockK
    private lateinit var repository: SampleRepository

    @Before
    fun before() {
        viewModel = SampleViewModel(repository)
    }

    @Test
    fun test01_insert() {
        val sample = mockk<Sample>()

        viewModel.insert(sample)

        verify { repository.insert(sample) }
    }
}

코드 출처 : https://leveloper.tistory.com/199

3. @MockkBean

Spring Context 내에서 의존성을 모킹하여 주입. Spring 테스트에 적합.

  1. Spring Context 내에서 해당 빈의 실제 구현체 대신 모킹된 객체를 주입
  2. 보통 @WebMvcTest나 @SpringBootTest와 함께 사용 (컨트롤러, 서비스 테스트에 적합)

1.3. 딥다이브

1. mockK() vs @MockK 사용에 대한 갑론을박**

해당 stack overflow 글을 읽어보면 mockK()와 @MockK중 어느 것을 사용하는 것이 좋은지에 대한 토론이 있다.

요약해보면 아래와 같다

  • mockK() 사용하자

    • @InjectMockk 은 생각보다 우아하지 않다. 만약 mockito가 생성자, 필드, setter injection을 시도했으나 실패하면 에러를 뱉지 않기 때문에 제대로 mock이 들어갔는지 우리는 보장할 수 없다.
    • var 대신 val 사용할 수 있다.
    • 초기화 타이밍을 고민하지 않아도 된다.

  • @MockK 사용하자

    • @InjectMockk 사용하면 귀찮게 생성자를 만들어서 넣어줄 필요가 없어 코드가 간결해진다.
    • 클래스의 dependency가 변경되면 쉽게 변경해줄 수 있다.

2. @MockBean 또는 @MockkBean을 사용할 경우, ApplicationContext를 재활용하지 못하고 Spring Container는 매번 reloading된다?

모든 테스트에 @SpringBootTest에 @MockKBean 무지성 사용.. 참 편하다. 물론 우리는 통합테스트는 필요할 때만, 테스트 범위는 최소한으로, 필요한 것만 Spring 에서 가져와서 사용해야 하는 것을 알고있다.
그렇다면 @MockKBean은 편하게 막 사용해도 되는가? 이에 대한 답변을 아래 블로그에서 발췌해보았다.

The Spring test framework will cache an ApplicationContext whenever possible between test runs.
In order to be cached, the context must have an exactly equivalent configuration.
Whenever you use @MockBean, you are by definition changing the context configuration.

스프링 테스트 프레임워크는 테스트가 돌아가면서 ApplicationContext를 캐싱할 것이다.
캐시하기 위해서는 context가 반드시 동일한 configuration을 가져야한다.
@MockBean을 사용할때마다, context의 configuration은 변할 것이다.

음.. CI 시간을 무지막지하게 기다릴 수 있다면 사용하도록 하자

추가 학습

kotlin에서 테스트 코드를 보다보면서 lateinit이라는 키워드를 많이 보게 되었습니다.

    @Autowired
    private lateinit var redisTemplate: RedisTemplate<String, String>
    private lateinit var redisService: RedisService

어디서 어렴풋이 성능에 더 좋기 때문에 사용한다는 말을 들었는데 (결론부터 말씀드리면 아닙니다!), 이에 대해 더 자세히 알고 싶어 공부해 본 내용을 추가로 정리해봅니다.

1. lateinit

  • 테스트에서 사용하는 이유

    • 유연한 객체 초기화 : 각 테스트가 실행될 시점에 객체를 초기화 (주로 @Before 또는 beforeTest 메서드)

    • 간결한 코드 : 이후 초기화되더라도 nullable 타입을 사용하지 않을 수 있음 (사용할 때 초기화가 강제되기 떄문)

    • 성능 때문이 아님!! 초기화 시점을 제어할 수 있을 뿐, 메모리 할당이나 초기화 속도에서 이득이 없다.

      • 메모리 최적화를 위한 싱글턴, 불필요한 객체 생성 삭제를 방지하는 객체 풀링 등이 성능 향상의 전략이다

  • 즉 테스트에서 lateinit을 반드시 써야하는 것은 아니다!!

    • 사용하면 좋은 때

      • 지연 초기화가 필수적인 경우: 의존성 주입이 필요한 객체이지만, 테스트 환경에서 바로 초기화할 수 없거나 나중에 설정해야 하는 경우.

      • nullable을 피하고 싶은 경우: 변수 초기화를 나중으로 미루면서도 nullable 타입을 사용하고 싶지 않은 경우.

      • 객체가 반드시 초기화되어야 하는 경우: 테스트에서 반드시 값이 주입되거나 초기화되어야 하지만, 그 시점은 테스트 실행 중간에 이루어질 경우

    • 불필요한 때

      • 즉시 초기화할 수 있는 경우
      • null을 활용해야 하는 경우 → 이런 경우가 많을까?

  • 주의 사항

    • lateinit 변수는 사용 전 반드시 초기화 되어야 함. 안하면 컴파일 단계에서UninitializedPropertyAccessException 발생

    • primitive type 안되는 이유? : lateinit 내부구현에 null과 비교하는 구현이 있는데, primitive type은 null 자체를 못가지기 때문에 이를 사용 불가

    • val이 안되는 이유? : lateinit은 초기화 지연하기 때문에 선언 동시 초기화하는 구문이 없어 이후 setter로 값을 넣줘야 하는데 val은 java 디컴파일시 setter 없음.

  • 참조 : https://velog.io/@no1msh1217/Kotlin-lateinit-var%EC%97%90-%EA%B4%80%ED%95%98%EC%97%AC

2. Late Initialization (lateinit) vs Lazy Initialization (by lazy)

: 둘다 늦은 초기화에 사용되는 키워드

  • 늦은 초기화란?

    • 분명 변수 name을 사용할 것이나, name의 첫 상태를 정의하기 어려울 때 위험하게 null을 초기상태로 두지 않는 것이 좋다. 이는 kotlin 철학과도 반한다
      var name: String? = null // NO!

  • Lazy Initialization

    • var과 함께 사용 → 값 변경 가능
    • 초기화 후 값이 계속 바뀔 수 있을 때 사용
    • 늦은 초기화를 하지 않고 사용하면 컴파일 단계에서 UninitializedPropertyAccessException 에러 발생하여 잠재적 오류 방지
    • primitive 사용 불가

  • Late Initialization

    • val과 함께 사용 → 값 변경 불가
    • 초기화 후 수정 없이 read-only 이어야 할 때 사용
    • 선언 당시에는 초기화할 수 없으나, 이에 의존하는 값이 초기화된 이후에 값을 채워넣고 싶을 때 사용된다

  • 예시

    fun main() {
    lateinit var text: String
    val textLength: Int by lazy {
        text.length
    }

    text = "WEOLBU" // text 초기화됨. textLength도 따라서 초기화
    println(textLength) // 6
    text = "NEW_TEXT" // text는 바뀌었지만, textLength는 재계산되지 않음
    println(textLength) // 여전히 6
}

  • 만약 text가 바뀔 때마다 text.length도 바뀌게 하고 싶다면? → by Lazy 사용 X

    fun main() {
    lateinit var text: String
    val textLength: Int
        get() = text.length // 매번 text의 길이를 가져옴

    text = "WEOLBU"
    println(textLength) // 6
    text = "NEW_TEXT"
    println(textLength) // 8
}

  • 참조 : https://velog.io/@haero_kim/Kotlin-lateinit-vs-lazy-%EC%A0%95%ED%99%95%ED%9E%88-%EC%95%84%EC%84%B8%EC%9A%94

profile
Damongsanga
향유하는 개발자
다음 포스트

[Kotlin Test] 2. Fixture

2개의 댓글

comment-user-thumbnail
Denia
2025년 1월 8일

좋은 내용 잘 보고 갑니다!!

1개의 답글