Android Unit Test実務：JUnit 5とMockKによる堅牢化

Update:

モバイルアプリケーション開発において、機能の複雑化に伴うリグレッション（回帰）バグの増加は避けられない課題です。手動によるQAはコストが高く、フィードバックループも長期的になりがちです。本稿では、Android開発におけるユニットテスト（単体テスト）の技術的意義、JUnit 5とMockKを用いたモダンな実装戦略、そして保守可能なテストコードを維持するためのアーキテクチャ設計について、シニアエンジニアの視点から解説します。

1. テスト戦略とピラミッドモデルの再考

Googleが提唱する「テストピラミッド」は、テストの実行コスト、速度、信頼性のトレードオフを可視化したモデルです。多くの現場で見られるアンチパターンとして、E2E（UI）テストに過度に依存する「アイスクリームコーン型」が存在しますが、これはCI/CDパイプラインのボトルネックとなり、Flaky（不安定）なテストを量産する原因となります。

テスト種別 実行環境 実行速度 忠実度 (Fidelity) コスト
Unit Test JVM (Local) 極めて高速 (ms単位) 低い (Mock多用) 低
Integration Test JVM / Emulator 中程度 中 中
UI (E2E) Test Device / Emulator 遅い (分単位) 高い 高

エンジニアリングの観点では、ビジネスロジックの検証を可能な限りローカルJVM上で完結するユニットテストに寄せるべきです。Androidフレームワークへの依存（ContextやView）を排除し、ViewModelやUseCase層をPOJO（Plain Old Java Object）に近い形で設計することで、高速な検証サイクルを実現できます。

2. モダンなテスト環境の構築 (JUnit 5 & MockK)

長らくAndroidの標準はJUnit 4でしたが、現在はJUnit 5 (Jupiter)への移行が推奨されます。JUnit 5はパラメータ化テストやネストされたテストクラス、可読性の高いアノテーションを提供します。また、Kotlin開発においてはMockitoよりもMockKの方が親和性が高く、finalクラスのモック化やコルーチンのサポートにおいて優位性があります。

依存関係の設定

build.gradleにおける設定例は以下の通りです。JUnit 5を使用するには、Android Gradle Pluginの設定でuseJUnitPlatform()を有効にする必要があります。


android {
    // ...
    testOptions {
        unitTests.all {
            useJUnitPlatform() // JUnit 5ランナーを有効化
        }
    }
}

dependencies {
    // JUnit 5
    testImplementation "org.junit.jupiter:junit-jupiter-api:5.9.3"
    testRuntimeOnly "org.junit.jupiter:junit-jupiter-engine:5.9.3"

    // MockK (Kotlin専用モッキングライブラリ)
    testImplementation "io.mockk:mockk:1.13.5"

    // Truth (Google製アサーションライブラリ)
    testImplementation "com.google.truth:truth:1.1.5"

    // Coroutines Test
    testImplementation "org.jetbrains.kotlinx:kotlinx-coroutines-test:1.7.3"
}
Migration Note: 既存のJUnit 4テスト資産がある場合、junit-vintage-engineを追加することで、JUnit 4と5を同一プロジェクト内で共存させることが可能です。段階的な移行を計画する際に有用です。

3. 非同期処理とViewModelのテスト戦略

現代のAndroidアプリにおいて、ViewModelはUI状態のホルダーとして機能し、Repository層との非同期通信を仲介します。ここでは、Kotlin CoroutinesとFlowを用いたViewModelのテスト手法に焦点を当てます。

Main Dispatcherの差し替え

ユニットテスト環境（JVM）にはAndroidのメインスレッド（Main Looper）が存在しません。そのため、viewModelScopeなどでDispatchers.Mainが使用されているコードをテストする場合、テスト実行中のみDispatcherを差し替える必要があります。


@OptIn(ExperimentalCoroutinesApi::class)
class MainDispatcherRule(
    private val testDispatcher: TestDispatcher = UnconfinedTestDispatcher()
) : TestWatcher() {
    override fun starting(description: Description) {
        Dispatchers.setMain(testDispatcher)
    }

    override fun finished(description: Description) {
        Dispatchers.resetMain()
    }
}

ViewModelのテスト実装例

MockKを用いてRepositoryの挙動を定義し、ViewModelの状態遷移を検証します。Google Truthを用いることで、アサーションの可読性が向上します。


class UserViewModelTest {

    // JUnit 4のRule、またはJUnit 5のExtensionでDispatcherを差し替え
    @get:Rule
    val mainDispatcherRule = MainDispatcherRule()

    private val userRepository: UserRepository = mockk()
    private lateinit var viewModel: UserViewModel

    @Before
    fun setup() {
        viewModel = UserViewModel(userRepository)
    }

    @Test
    fun `fetchUser success updates uiState to Success`() = runTest {
        // Arrange (準備)
        val expectedUser = User(id = 1, name = "Test User")
        // coEvery: Coroutine対応のスタブ定義
        coEvery { userRepository.getUser(1) } returns Result.success(expectedUser)

        // Act (実行)
        viewModel.fetchUser(1)

        // Assert (検証)
        // StateFlowの現在値を検証
        assertThat(viewModel.uiState.value).isInstanceOf(UiState.Success::class.java)
        val successState = viewModel.uiState.value as UiState.Success
        assertThat(successState.user).isEqualTo(expectedUser)
        
        // 呼び出し確認
        coVerify(exactly = 1) { userRepository.getUser(1) }
    }
}
Warning: runTestは時間をスキップする仮想時間制御を提供しますが、UnconfinedTestDispatcherとStandardTestDispatcherの使い分けを誤ると、Flowのcollectタイミングなどで予期しない挙動を引き起こす可能性があります。基本的にはStandardTestDispatcherを使用し、明示的なadvanceUntilIdle()などで制御する方が安全です。

4. モックとスタブの設計原則

テストダブル（Mock, Stub, Spy）の乱用は、実装の詳細に結合した「壊れやすいテスト（Brittle Tests）」を生み出します。以下の原則を遵守してください。

  1. 入力値にはStub、出力/作用にはMock: データを返すだけのメソッドにはStub（every { ... } returns ...）を使用し、副作用（ログ送信、DB書き込みなど）の検証にのみMock（verify { ... }）を使用します。
  2. 過剰な検証を避ける: verify(exactly = 1)などは強力ですが、実装のリファクタリングを阻害する可能性があります。本当にそのメソッド呼び出し回数がビジネスロジック上重要である場合のみ検証します。
  3. ドメインロジックは実体を使う: Value ObjectやEntityなど、依存関係を持たない純粋なロジッククラスはモック化せず、実インスタンスを使用してテストする方が信頼性が高まります。

5. テスト容易性を高めるアーキテクチャ

ユニットテストが書きにくい場合、それはプロダクションコードの設計に問題があるというシグナルです。テスト容易性（Testability）を向上させるための設計指針を示します。

依存性の注入 (Dependency Injection)

HiltやKoinなどのDIコンテナを利用し、クラス内部で依存インスタンスをnew（生成）しないようにします。コンストラクタインジェクションを採用することで、テスト時にMockへの差し替えが容易になります。


// Bad Pattern: テスト時にRepositoryを差し替えられない
class BadViewModel {
    private val repository = UserRepository() 
}

// Good Pattern: コンストラクタ経由で依存を受け取る
class GoodViewModel @Inject constructor(
    private val repository: UserRepository
) : ViewModel() { ... }

ロジックの分離

Android Framework（Activity/Fragment）にロジックを書くと、Robolectricなどの重いライブラリが必要になります。ロジックをドメイン層（UseCase）やViewModelに移動させ、Viewは「状態の描画」と「イベントの伝播」のみに関心を持つように設計します。

Best Practice: Contextを必要とするロジック（例: リソース文字列の取得、SharedPreferences）は、適切な抽象化インターフェース（Wrapper）を作成し、ViewModelからはそのインターフェースに依存するようにします。これにより、テスト時はMock実装を渡すだけで済みます。

結論：品質への投資としてのテスト

ユニットテストは、単なるバグ発見ツールではなく、設計の質を保ち、将来的な変更コストを下げるための投資です。JUnit 5とMockK、そして適切なアーキテクチャを組み合わせることで、開発速度を落とすことなく、堅牢なAndroidアプリケーションを構築することが可能になります。

Android Testing Guide (Official)

Related Posts

Loading…

Post a Comment