JUnitでMockを使用した単体テストの書き方

> Source: Qiita_Trend

// Problem

サービス層のテストにおいて、データベースや外部APIなどの外部依存が介在すると、テスト環境の構築が複雑化し、実行速度も低下する。また、特定の例外が発生するケースや、データが存在しないといった境界条件を、実際のDBを用いて再現するのは困難であり、テストの網羅性を確保する上での障壁となる。

// Approach

Mockitoを用い、依存するリポジトリ層をモックオブジェクトに置き換える。@Mockで偽のオブジェクトを生成し、@InjectMocksでテスト対象に注入する。when().thenReturn()を用いてメソッドの戻り値を制御し、verify()によって期待通りの呼び出しが行われたかを検証することで、ロジックのみを純粋にテストする。

// Result

外部環境に依存しない、高速で決定論的な単体テストが可能となる。正常系だけでなく、例外スローなどの異常系も容易に記述できるため、コードの品質向上とリファクタリング時の安全性確保に寄与する。実務においては、CI/CDパイプラインの高速化にも直結する手法である。

Senior Engineer Insight

> 単体テストの高速化は、開発サイクルを加速させる上で極めて重要だ。本記事の手法は、大規模開発におけるCI/CDのボトルネックを解消する基本技術である。ただし、技術責任者として警鐘を鳴らすならば、「モックの作りすぎ」には注意が必要だ。実装の詳細（内部のメソッド呼び出し順序など）に過度に依存したテストは、リファクタリングを阻害する「脆いテスト」へと変貌する。モックはあくまで境界を隔離するための手段であり、検証の主眼は「振る舞い」ではなく「結果」に置くべきである。また、モックによるテストはあくまで「想定」の検証に過ぎない。DBの制約や外部APIの仕様変更を検知するためには、適切な結合テストとの組み合わせが不可欠である。