現場で使えるJUnit5＋Mockito単体テスト術

by

開発現場において、CI/CDパイプラインの実行時間が長引き、デプロイサイクルが遅延する問題は、常にチームの開発生産性（タイムパフォーマンス）を低下させる深刻な要因となります。特に、データベースや外部APIといった外部システムに依存したテストが無秩序に混在していると、テスト環境のセットアップやデータのクリーンアップに多大な時間を奪われるだけでなく、「他者のテストデータの影響でテストが落ちる」といったフレーキー（不安定）なテストを生み出す原因にもなります。こうした外部依存を適切に切り離し、純粋なビジネスロジックの検証に特化するための標準的かつ強力な手段が、JUnit5とMockitoを組み合わせたモックテストです。今回は、Spring Bootのサービス層におけるMockの効果的な活用法と、現場導入時に直面する課題について考察します。

外部依存の切り離しがもたらす開発生産性の向上

Mockito導入のメリットと現場での技術的優位性

SpringBoot環境においてspring-boot-starter-testに内包されているMockitoを活用することは、新たなライブラリ選定コストをかけずに即座に単体テストの質を向上させる合理的な選択です。@Mockと@InjectMocksのアノテーションを組み合わせることで、DI（依存性の注入）コンテナであるSpringのコンテキストを一切起動することなく、サービス層（ビジネスロジック）のみをインスタンス化してテストを実行できます。これにより、テストの実行時間はミリ秒単位まで短縮され、開発者はコードの変更直後に瞬時にフィードバックを得ることが可能になります。また、異常系（DBの接続エラーや特定条件下での例外発生など）のテストも、when(...).thenThrow(...)を用いることで容易に意図的な再現が可能となり、堅牢なエラーハンドリングの実装を強力に後押しします。

「Mockの乱用」が招く保守性の低下に対する警鐘

一方で、Mockを利用したテストの導入には明確なトレードオフが存在します。最大の罠は、「テストが内部実装に過度に結合してしまう（脆いテスト：Fragile Testになる）」ことです。例えば、verifyメソッドを用いて「どのメソッドが何回呼ばれたか」を細かく検証しすぎると、ビジネス要件が変わっていないにもかかわらず、リファクタリングでメソッドの呼び出し順序や分割方法を変えただけでテストが落ちるようになります。単体テストの本来の目的は「入力に対する出力（あるいは状態の変更）が正しいか」を検証することであり、内部の処理手順を固定化することではありません。現場においては、外部システム（DBや外部API）との境界線のみをMock化し、ドメインロジックの内部的なメソッド呼び出しの検証（過剰なverify）は極力避けるという設計原則をチーム内で合意しておくことが不可欠です。

Mockテストと統合テストの実務的な使い分け

実務では、Mockを用いた単体テストだけで品質を担保することは不可能です。実際のデータベースを利用した統合テスト（近年ではTestcontainersを利用する手法が主流）とどのように棲み分けるかが、テスト戦略の鍵となります。

比較観点 Mockitoを活用した単体テスト Testcontainers等を活用した統合テスト
主な検証対象 ビジネスロジック（条件分岐、例外処理の網羅） クエリの正当性、トランザクション境界、DB制約
実行速度 極めて高速（ミリ秒単位）。TDDに最適 遅い（コンテナ起動やデータ投入のオーバーヘッド）
環境構築コスト 低い（ライブラリのみで完結、CI環境への依存なし） 高い（Docker環境の整備やマイグレーションの同期が必要）
信頼度（リファクタリング耐性） 中（内部実装への結合度が高くなりがち） 高（ブラックボックス的に検証できるため壊れにくい）

現場で重宝するArgumentCaptorの実務実装例

単純な戻り値の検証（thenReturn）だけでなく、実務では「サービス層内で生成・加工されたオブジェクトが、正しくリポジトリに渡されているか」を検証するケースが多々あります。このような場合、MockitoのArgumentCaptorを使用することで、引数の内部状態を精緻にアサーションすることができます。

@Test
@DisplayName("新規ユーザー登録時、初期ステータスと登録日時が正しく設定されて保存されること")
void save_verifyInternalState() {
    // Arrange
    User inputUser = new User();
    inputUser.setEmail("[email protected]");
    inputUser.setName("テスト ユーザー");

    when(userRepository.findByEmail(anyString())).thenReturn(Optional.empty());
    
    // Captorの準備（リポジトリのsaveメソッドに渡されるUserオブジェクトを捕獲する）
    ArgumentCaptor<User> userCaptor = ArgumentCaptor.forClass(User.class);

    // Act
    userService.save(inputUser);

    // Assert
    verify(userRepository).save(userCaptor.capture());
    User capturedUser = userCaptor.getValue();
    
    // サービス層内で付与されるべきビジネスルールの検証
    assertThat(capturedUser.getEmail()).isEqualTo("[email protected]");
    assertThat(capturedUser.getStatus()).isEqualTo(UserStatus.ACTIVE); // 初期状態の検証
    assertThat(capturedUser.getCreatedAt()).isNotNull(); // 登録日時が付与されているか
}

シニアエンジニアの総評

Mockitoによる依存関係の抽象化は、テスト駆動開発（TDD）のリズムを生み出し、エッジケース（異常系）の網羅率を飛躍的に高めるための必須スキルです。しかし、Mockはあくまで「現実の模倣」に過ぎず、本物のデータベースの制約違反（一意制約や外部キー制約など）を検出することはできません。テストピラミッドの概念に則り、条件分岐を網羅する軽量な単体テストの土台をMockitoで構築し、システムの重要な境界部分については統合テストで確実にカバーするという、バランスの取れた品質保証戦略を設計することが、真に保守性の高いシステムを生み出す基盤となります。

参考記事: JUnitでMockを使用した単体テストの書き方

Photo by Ivan Shilov on Unsplash

コメントする