본문 바로가기

Android/TDD(Test Driven Development, 테스트 주도 개발)

kotest Project Config 다른 모듈과 공유

반응형

Unit Test를 하다보면 Dispatchers.Main을 사용하는 코루틴과 문제가 발생하는 경우가 잦다.
kotest에서는 이를 다음과 같이 Project Config를 사용하여 해결한다.

object KotestConfig : AbstractProjectConfig() {

    private val testDispatcher = UnconfinedTestDispatcher()

    override suspend fun beforeProject() {
        super.beforeProject()
        Dispatchers.setMain(testDispatcher)
    }

    override suspend fun afterProject() {
        super.afterProject()
        Dispatchers.resetMain()
    }
}

해당 config는 따로 할당할 필요 없이 모듈 top-level에 존재하면 되고, AbstractProjectConfig를 상속한 Config가 여러 개 있다면 하나로 머지되어 적용된다. 단, config가 겹친다면 어떤 config가 적용될 지 모르니 주의하여야 한다.

https://kotest.io/docs/framework/project-config.html

 

Project Level Config | Kotest

Kotest is flexible and has many ways to configure tests, such as configuring the order of tests inside a spec, or how

kotest.io

멀티 모듈 프로젝트에서 매번 이러한 config를 작성하는 건 귀찮고, 실수가 발생할 여지가 있다. 하나의 파일을 공유할 수 있으면 best. 이를 위한 기능 중 하나로 gradle test fixtures를 사용할 수 있다.

https://docs.gradle.org/current/userguide/java_testing.html#sec:java_test_fixtures

 

Testing in Java & JVM projects

If you are developing Java Modules, everything described in this chapter still applies and any of the supported test frameworks can be used. However, there are some things to consider depending on whether you need module information to be available, and mo

docs.gradle.org

test fixtures 사용을 위해선 java-test-fixtures 플러그인을 적용하여야 하며, 이는 java-library만 지원하므로 com.android.library를 사용하는 안드로이드 모듈에서는 할 수 없다.

// test fixtures를 작성할 모듈의 build.gradle.kts (KotestConfig를 작성할 모듈, 편의상 :domain)
plugins {
    `java-library`
    `java-test-fixtures`
    // ...
}

// ...

dependencies {
    // ...
    testFixturesImplementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.0")
    testFixturesImplementation("io.kotest:kotest-runner-junit5:5.0.3")
}

다음으로 위 KotestConfig:domain 아래 src/testFixtures/kotlin/ 경로로 이동한다.

// test fixtures를 사용할 모듈의 build.gradle.kts (KotestConfig를 사용할 모듈, 편의상 :presentation)
// java-library든 com.android.library든 상관 없음
// ...

dependencies {
    // ...
    testImplementation(testFixtures(project(":domain")))
}

적용 끝.

+ 덧
testFixturesImplementation(...)testImplementation(testFixtures(project(":domain")))를 헷갈리면 안 된다... 전자는 testFixtures에서 사용할 라이브러리 의존성을 포함하는 코드고, 후자는 test에서 사용할 domain의 test fixtures를 포함하는 코드이다.

참고

https://bottom-to-top.tistory.com/58: 예시로 의존성 없는 객체를 사용하고 있어 아쉽다

 

Gradle TestFixtures 이용하여 테스트 코드 중복 줄이기

Gradle Test Fixture 사용해서 테스트 중복코드 줄이기 Gradle Test Fixture 테스트코드를 작성하다보면 테스트 코드에서도 중복된 코드가 굉장히 많이 발생하게 된다. 대표적인 예로 특정 도메인 객체를

bottom-to-top.tistory.com

https://kyucumber.github.io/posts/spring/gradle-test-fixtures-plugins: 예시로 의존성 없는 객체를 사용하고 있어 아쉽다22

 

Gradle test fixtures 플러그인을 통해 중복 코드 줄이기 - kyucumber

아래와 같은 멀티모듈 구조를 가진 프로젝트에서 module-library에 포함된 User라는 클래스와 연관된 테스트를 각각의 모듈에서 작성한다고 할 때 어떤 문제점이 있을까요? ├── module-one │ └──

kyucumber.github.io

https://emartynov.medium.com/android-gradle-plugin-with-test-fixtures-support-411383320980

 

Android Gradle plugin with Test Fixtures support

15 February 2022 UPDATE

emartynov.medium.com

 

kotest Project Config 관련해서 이런 고민을 한 사람이 없는 건지... 내가 못 찾는 건지... 레퍼런스 없으면 구현하는 게 참 쉽지 않다.

반응형