MockK: その概要、主要概念、構文

MockKとは？

MockKはモックオブジェクトを作成するためのライブラリで、Kotlinで書かれ、その構文に最適化されています。Mockitoと同じ問題（依存関係からテスト対象コードを隔離する）を解決しますが、ラムダ、DSL、reified generics、suspend関数といったKotlin固有の構文を使用します。

移植されたソリューションに対するMockKの主な利点はネイティブのKotlinサポートです。Mockitoではfinalクラスのモック化にopt-in（mockito-inline）が必要で、静的メソッドにはmockStaticが必要です。MockKはデフォルトでこれをサポートしています。なぜならKotlinクラスはデフォルトでfinalであり、この制限を回避することはライブラリのアーキテクチャに組み込まれているからです。

バージョン1.13.12（2024年）は安定版リリースで、Kotlin 2.0、K2コンパイラ、マルチプラットフォームプロジェクト（KMP）をサポートしています。MockKはKotlin/NativeやKotlin/JSでも動作し、MockitoもEasyMockも適用できないKMPプロジェクトでは唯一の選択肢となっています。

MockKはKotlinの特性を考慮して設計されており、パフォーマンスを犠牲にすることなく、簡潔で型安全なAPIを提供するために、reified generics、ラムダを用いたDSL、インライン関数といった言語機能を活用しています。

MockKの仕組み

MockKのメカニズムは、ByteBuddyライブラリ（Mockitoと同様）によるバイトコード計装に基づいていますが、それをKotlinフレンドリーなDSLでラップしています。when().thenReturn()チェーンの代わりに、MockKはラムダブロックevery { }とcoEvery { }を使用し、これらは言語の自然な拡張のように見えます。内部では、MockKはラムダ内の呼び出しをインターセプトし、リフレクションでメソッドと引数を分析し、記録されたスタビングルールと照合します。

MockKの基本構文

ブロックevery { mock.method() } returns valueは「メソッドが呼び出されるたびに値を返す」と読みます。この宣言的な構文はKotlinスタイルに近く、when()での引数の順序に関する混乱を排除します。Kotlinのreified genericsのおかげで、モックの型はクラスを明示的に指定しなくても自動的に推論されます。

val repository = mockk<UserRepository>()

// スタビング: findById(1)の各呼び出しはユーザーを返す
every { repository.findById(1) } returns User("Alice")

// 呼び出しと検証
val result = repository.findById(1)
assertEquals("Alice", result.name)

Relaxed mock: ボイラープレートの削減

各メソッドを明示的に設定する必要があるMockitoとは異なり、MockKはrelaxed mockをサポートしています。これは任意のメソッドに対して「妥当な」デフォルト値（Listには空リスト、Intには0、Stringには空文字列）を返すモックです。これにより、セットアップコードの量が大幅に削減されます。

// Relaxed mock — すべてのメソッドがデフォルト値を返す
val api = mockk<ApiService>(relaxed = true)

// スタビング不要 — 空のリストを返す
println(api.getUsers()) // []

モックとリラックスドモックの作成

MockKはモックオブジェクトを作成するいくつかの方法を提供しています。厳格モック用のmockk<T>()（各メソッドを明示的に設定する必要あり）、リラックスドモック用のmockk<T>(relaxed = true)、実際のオブジェクトにスパイを作成するspyk(obj)です。

厳格モックとリラックスドモックの選択は状況によって異なります。厳格モックは、テストが動作が定義されていないメソッドを使用しないことを保証し、信頼性を高めます。リラックスドモックは、すべての依存関係が重要ではない迅速なテストのプロトタイピングに便利です。実際には、厳格モックから始めて、スタビングがテスト自体よりも多くの行数を占める場合にのみリラックスドに切り替えることをお勧めします。

スタビング: everyブロックによる動作設定

everyブロックはMockKにおける中心的なスタビング構文です。ラムダ内で特定の引数を持つメソッド呼び出しを記述し、returnsで値を返すか、throwsで例外をスローするか、answersで応答を計算します。

さまざまなスタビング方法

MockKはテストに必要なすべてのシナリオをサポートしています。値の返却、例外のスロー、引数に基づく応答の計算、順序に基づく複数の応答（呼び出しシーケンス）です。

// 値の返却
every { repo.findById(1) } returns User("Alice")

// 例外のスロー
every { repo.findById(999) } throws NotFoundException()

// 動的応答
every { repo.save(any()) } answers {
    val user = firstArg<User>()
    user.copy(id = 42)
}

// 応答のシーケンス
every { repo.findAll() } returnsMany listOf(
    listOf(User("Alice")),
    listOf(User("Bob")),
    emptyList()
)

コルーチン用のVerifyとcoVerify

VerifyはMockKにおいて目的はMockito.verify()と同様ですが、Kotlin DSLを使用します: verify { mock.method() }。suspend関数にはcoVerify { mock.suspendMethod() }を使用し、これはコルーチンと正しく動作し、特別なランナーは必要ありません。

呼び出し回数の検証

MockKはMockitoと同じ修飾子をサポートしています: exactly(1)、atLeast(2)、atMost(5)、wasNot(Called)。構文は最小限で、修飾子はverify { }の最初の引数として渡されます。

// 検証: メソッドが正確に1回呼び出された
verify(exactly = 1) { repo.save(any()) }

// 呼び出し順序の検証
verifySequence {
    repo.save(any())
    repo.flush()
}

// suspend関数用のcoVerify
coVerify { api.fetchUsers() }

Slot: 引数のキャプチャ

引数の検証にはslot()を使用します。これはArgumentCaptorに類似しています。Slotは呼び出し前に宣言され、everyまたはverifyに渡され、テスト実行後にキャプチャされた値を保持します。

val userSlot = slot<User>()

verify { repo.save(capture(userSlot)) }

assertEquals("Alice", userSlot.captured.name)

MockKアノテーションとJUnit統合

MockKはJUnit 5での初期化によるモック作成のための@MockKおよび@RelaxedMockKアノテーションを提供します。MockKExtensionは各テストの前に自動的にモックを作成し、後にクリーンアップします。これはMockitoExtensionと似ていますが、リラックスドモードをサポートしています。

MockKExtensionの例

@InjectMockKsアノテーション（または明示的なオブジェクト作成を伴う代替の@MockK）は、テスト対象インスタンスにモックを注入します。これによりボイラープレートが削減され、テストコードがよりクリーンになります。

@ExtendWith(MockKExtension::class)
class UserServiceTest {

    @MockK
    lateinit var repository: UserRepository

    @InjectMockKs
    lateinit var service: UserService

    @Test
    fun `getUser returns user from repository`() {
        every { repository.findById(1) } returns User("Alice")
        assertEquals("Alice", service.getUser(1)?.name)
    }
}

MockK vs Mockito: Kotlinでどちらを選ぶか

選択はチーム構成とプロジェクトの種類によって異なります。Mockitoはより大きなエコシステム、より多くの例と統合を持っていますが、MockKはよりクリーンなKotlin構文と言語機能のネイティブサポートを提供します。新しいKotlinプロジェクトには、MockKがより慣用的なソリューションとして推奨されます。

純粋なKotlinプロジェクト（Javaクラスなし）の場合、MockKが望ましいです。ボイラープレートが少なく、ネイティブのコルーチンサポート、finalクラスに関する驚きがありません。ハイブリッドプロジェクトやJava経験のあるチームの場合、Mockitoは引き続き有効な選択肢です。両方のライブラリは異なるモジュールを通じて同じプロジェクトで使用できます。MockitoからMockKへの移行時は、@Mockアノテーションを@MockKに置き換え、when().thenReturn()ブロックをevery { }形式に書き換えるだけで十分です。