【2024年保存版】Mockito.verifyの完全ガイド – 基本から応用まで15のベストプラクティス

Mockito.verifyとは？基本概念を理解しよう

verifyメソッドの役割と重要性

Mockito.verifyは、モックオブジェクトに対して特定のメソッドが「どのように呼び出されたか」を検証するためのメソッドです。単体テストにおいて、テスト対象のクラスが依存オブジェクトを正しく操作しているかを確認する際に重要な役割を果たします。

verifyが解決する課題

テストコードにおいて、以下のような検証が必要な場面で活用されます：

1. メソッドが呼び出されたかどうかの確認
2. メソッドが正しい引数で呼び出されたかの確認
3. メソッドが指定した回数だけ呼び出されたかの確認
4. メソッドが特定の順序で呼び出されたかの確認

verifyの基本的な使用場面

// メール送信サービスの例
public class NotificationService {
    private EmailSender emailSender;

    public NotificationService(EmailSender emailSender) {
        this.emailSender = emailSender;
    }

    public void notifyUser(String userId, String message) {
        // ユーザー情報の取得や他の処理...
        emailSender.sendEmail(userId, message);
    }
}

// テストコード
@Test
public void testNotifyUser() {
    // モックの作成
    EmailSender mockEmailSender = mock(EmailSender.class);
    NotificationService service = new NotificationService(mockEmailSender);

    // メソッド実行
    service.notifyUser("user123", "Hello!");

    // 検証
    verify(mockEmailSender).sendEmail("user123", "Hello!");
}

このように、verifyを使用することで、テスト対象のクラスが依存オブジェクトを期待通りに操作しているかを確認できます。

モックオブジェクトの振る舞い検証の基本

モックオブジェクトの振る舞い検証には、大きく分けて以下の3つの要素があります：

1. 検証の種類

2. 検証のタイミング

verifyによる検証は、通常以下の順序で行われます：

1. モックオブジェクトの作成
2. テスト対象クラスの実行
3. 振る舞いの検証

// 検証のタイミングの例
@Test
public void demonstrateVerificationTiming() {
    // 1. モックの作成
    UserRepository mockRepository = mock(UserRepository.class);
    UserService service = new UserService(mockRepository);

    // 2. テスト対象メソッドの実行
    service.deleteUser("userId123");

    // 3. 振る舞いの検証
    verify(mockRepository).deleteById("userId123");
}

3. 検証の粒度

検証の粒度は、テストの目的に応じて適切に選択することが重要です：

// 様々な粒度での検証例
@Test
public void demonstrateVerificationGranularity() {
    OrderService mockOrderService = mock(OrderService.class);

    // メソッド呼び出しの有無のみを検証
    verify(mockOrderService).processOrder(any());

    // 具体的な引数値を検証
    verify(mockOrderService).processOrder(eq("ORDER001"));

    // 呼び出し回数も含めて検証
    verify(mockOrderService, times(1)).processOrder(any());
}

これらの基本概念を理解することで、Mockito.verifyを効果的に活用したテストコードを作成できるようになります。次のセクションでは、より具体的な使用方法と実践的なパターンについて解説します。

Mockito.verifyの基本的な使い方

verifyの基本構文と実装例

Mockito.verifyの基本構文を理解することは、効果的なテストコード作成の第一歩です。以下で、基本的な使い方から応用的な使い方まで段階的に説明します。

1. 基本的な検証

// 基本的なverifyの使用例
@Test
public void demonstrateBasicVerify() {
    // モックの作成
    List<String> mockedList = mock(List.class);

    // モックメソッドの実行
    mockedList.add("test");
    mockedList.clear();

    // 基本的な検証
    verify(mockedList).add("test");  // addメソッドが"test"で呼ばれたことを検証
    verify(mockedList).clear();      // clearメソッドが呼ばれたことを検証
}

2. メソッドチェーンでの検証

// verifyのメソッドチェーンの例
@Test
public void demonstrateMethodChaining() {
    UserService userService = mock(UserService.class);

    // モックメソッドの実行
    userService.findById("userId").getName();

    // メソッドチェーンの検証
    verify(userService).findById("userId");  // findByIdメソッドの検証
}

検証回数の指定方法（times/never/atLeast）

verifyメソッドでは、メソッドの呼び出し回数を様々な方法で検証できます。

1. 基本的な回数指定

@Test
public void demonstrateVerificationModes() {
    List<String> mockedList = mock(List.class);

    // モックメソッドの複数回実行
    mockedList.add("test");
    mockedList.add("test");
    mockedList.add("test");

    // 様々な回数指定による検証
    verify(mockedList, times(3)).add("test");    // 正確に3回
    verify(mockedList, atLeast(2)).add("test");  // 最低2回
    verify(mockedList, atMost(4)).add("test");   // 最大4回
}

2. 特殊な回数指定

@Test
public void demonstrateSpecialVerificationModes() {
    UserService userService = mock(UserService.class);

    // メソッド実行
    userService.updateUser("user1");

    // 特殊な検証モードの使用
    verify(userService, never()).deleteUser(any());     // deleteUserは呼ばれていない
    verify(userService, atLeastOnce()).updateUser(any()); // updateUserは最低1回呼ばれた
}

引数マッチャーの活用テクニック

引数マッチャーを使用することで、より柔軟な検証が可能になります。

1. 基本的な引数マッチャー

@Test
public void demonstrateArgumentMatchers() {
    UserService userService = mock(UserService.class);

    // メソッド実行
    userService.createUser("john", 25);

    // 様々な引数マッチャーの使用
    verify(userService).createUser(anyString(), anyInt());  // 型による検証
    verify(userService).createUser(eq("john"), gt(20));    // 値による検証
}

2. カスタム引数マッチャー

より複雑な検証が必要な場合は、カスタム引数マッチャーを使用できます：

@Test
public void demonstrateCustomArgumentMatcher() {
    UserService userService = mock(UserService.class);

    User user = new User("john", "john@example.com");
    userService.registerUser(user);

    // カスタム引数マッチャーの使用
    verify(userService).registerUser(argThat(u -> 
        u.getName().equals("john") && 
        u.getEmail().contains("@")
    ));
}

3. 引数マッチャー使用時の注意点

1. 一貫性の原則

   // 正しい使用例
   verify(service).process(anyString(), anyInt());

   // 誤った使用例（混在させない）
   verify(service).process("exactString", anyInt()); // コンパイルエラー

2. nullの扱い

   // nullを許容する場合
   verify(service).process(nullable(String.class));

   // nullチェックを含むカスタムマッチャー
   verify(service).process(argThat(str -> 
       str != null && str.length() > 0
   ));

実装のポイント：

1. 適切なマッチャーの選択
   • 検証の目的に応じて最適なマッチャーを選択する
   • 過度に厳密な検証は避ける
2. 可読性の維持
   • 複雑なマッチャーはメソッド化して再利用する
   • 検証の意図が明確になるようにコードを構造化する
3. エラーメッセージの改善

   verify(userService).createUser(
       argThat(name -> {
           assertThat(name).matches("[a-zA-Z]+");
           return true;
       }),
       argThat(age -> {
           assertThat(age).isBetween(0, 120);
           return true;
       })
   );

これらの基本的な使い方を理解することで、Mockito.verifyを効果的に活用したテストコードを作成できます。次のセクションでは、より実践的なverifyの活用パターンについて解説します。

verifyを使用したテストの設計パターン

Given-When-Then形式での実装例

Given-When-Then（GWT）パターンは、テストを構造化し、可読性を高めるための効果的な方法です。Mockito.verifyと組み合わせることで、より明確なテストを作成できます。

1. 基本的なGWTパターン

@Test
public void demonstrateBasicGWT() {
    // Given: テストの前提条件を設定
    UserRepository userRepo = mock(UserRepository.class);
    EmailService emailService = mock(EmailService.class);
    UserService userService = new UserService(userRepo, emailService);

    User testUser = new User("testUser", "test@example.com");
    when(userRepo.findById("userId")).thenReturn(Optional.of(testUser));

    // When: テスト対象の操作を実行
    userService.deactivateUser("userId");

    // Then: 期待される結果を検証
    verify(userRepo).updateStatus("userId", UserStatus.INACTIVE);
    verify(emailService).sendDeactivationEmail("test@example.com");
}

2. GWTパターンの拡張

@Test
public void demonstrateExtendedGWT() {
    // Given
    OrderService orderService = mock(OrderService.class);
    PaymentService paymentService = mock(PaymentService.class);
    NotificationService notificationService = mock(NotificationService.class);

    OrderProcessor processor = new OrderProcessor(
        orderService, 
        paymentService, 
        notificationService
    );

    Order testOrder = new Order("ORD001", 1000.0);
    when(orderService.getOrder("ORD001")).thenReturn(testOrder);

    // When
    processor.processOrder("ORD001");

    // Then: 処理順序の検証
    InOrder inOrder = inOrder(paymentService, orderService, notificationService);

    inOrder.verify(paymentService).processPayment(eq(1000.0));
    inOrder.verify(orderService).updateOrderStatus(
        eq("ORD001"), 
        eq(OrderStatus.PAID)
    );
    inOrder.verify(notificationService).sendOrderConfirmation(any());
}

テスト可読性を高めるverifyの使い方

テストコードの可読性は、メンテナンス性と理解のしやすさに直結します。

1. カスタムマッチャーの活用

@Test
public void demonstrateReadableVerification() {
    OrderService orderService = mock(OrderService.class);

    // カスタムマッチャーの定義
    class ValidOrderMatcher implements ArgumentMatcher<Order> {
        @Override
        public boolean matches(Order order) {
            return order != null &&
                   order.getAmount() > 0 &&
                   order.getItems().size() > 0;
        }

        @Override
        public String toString() {
            return "a valid order with positive amount and items";
        }
    }

    // 可読性の高い検証
    verify(orderService).processOrder(argThat(new ValidOrderMatcher()));
}

2. BDDスタイルの適用

@Test
public void demonstrateBDDStyle() {
    // Given/Arrange
    UserService userService = mock(UserService.class);
    given(userService.findById("userId"))
        .willReturn(Optional.of(new User("testUser")));

    // When/Act
    userService.updateProfile("userId", new Profile("newName"));

    // Then/Assert
    then(userService)
        .should(times(1))
        .updateProfile(eq("userId"), any(Profile.class));
}

テストの保守性を向上させるverifyの活用法

テストの保守性を高めるためには、適切な抽象化とカプセル化が重要です。

1. テストヘルパーの作成

public class OrderTestHelper {
    private final OrderService orderService;
    private final PaymentService paymentService;

    public OrderTestHelper() {
        this.orderService = mock(OrderService.class);
        this.paymentService = mock(PaymentService.class);
    }

    public void verifyOrderProcessing(String orderId) {
        verify(orderService).validateOrder(orderId);
        verify(paymentService).processPayment(any(Payment.class));
        verify(orderService).updateOrderStatus(
            eq(orderId), 
            eq(OrderStatus.COMPLETED)
        );
    }

    public OrderService getOrderService() {
        return orderService;
    }

    public PaymentService getPaymentService() {
        return paymentService;
    }
}

@Test
public void demonstrateTestHelper() {
    OrderTestHelper helper = new OrderTestHelper();
    OrderProcessor processor = new OrderProcessor(
        helper.getOrderService(), 
        helper.getPaymentService()
    );

    processor.processOrder("ORD001");

    helper.verifyOrderProcessing("ORD001");
}

2. カスタムアサーション

public class OrderAssert {
    private final OrderService orderService;

    public OrderAssert(OrderService orderService) {
        this.orderService = orderService;
    }

    public OrderAssert hasProcessedOrder(String orderId) {
        verify(orderService).processOrder(eq(orderId));
        return this;
    }

    public OrderAssert hasNotifiedCustomer(String orderId) {
        verify(orderService).sendNotification(eq(orderId));
        return this;
    }

    public static OrderAssert assertThat(OrderService orderService) {
        return new OrderAssert(orderService);
    }
}

@Test
public void demonstrateCustomAssertions() {
    OrderService orderService = mock(OrderService.class);
    OrderProcessor processor = new OrderProcessor(orderService);

    processor.processOrder("ORD001");

    assertThat(orderService)
        .hasProcessedOrder("ORD001")
        .hasNotifiedCustomer("ORD001");
}

実装のポイント：

1. テスト構造の一貫性
   • GWTパターンを基本とする
   • セクションを明確に分ける
   • コメントで各セクションを説明する
2. 可読性の向上
   • 意図を明確に表現する命名
   • カスタムマッチャーの活用
   • BDDスタイルの適切な使用
3. 保守性の確保
   • テストヘルパーの作成
   • カスタムアサーションの活用
   • 共通処理の抽象化

これらの設計パターンを適切に活用することで、より保守性が高く理解しやすいテストコードを作成できます。次のセクションでは、チームでの活用に向けたベストプラクティスについて解説します。

よくあるverifyのエラーと解決方法

WantedButNotInvoked対策方法

WantedButNotInvokedは最も一般的なMockito.verifyのエラーの一つです。このエラーは、期待されたメソッド呼び出しが実際には行われなかった場合に発生します。

1. エラーの典型的な例

@Test
public void demonstrateWantedButNotInvoked() {
    UserService userService = mock(UserService.class);

    // メソッドを呼び出さない

    // 以下でエラーが発生
    verify(userService).deleteUser("userId");
    // org.mockito.exceptions.verification.WantedButNotInvoked:
    // Wanted but not invoked: userService.deleteUser("userId");
}

2. 一般的な原因と解決方法

3. 体系的な解決アプローチ

@Test
public void demonstrateSystematicDebugging() {
    UserService userService = mock(UserService.class);

    // デバッグ用のリスナー追加
    MockitoSession session = Mockito.mockitoSession()
        .initMocks(this)
        .strictness(Strictness.WARN)
        .startMocking();

    try {
        // テスト対象のメソッド実行
        userService.deleteUser("userId");

        // 段階的な検証
        verify(userService).deleteUser(argThat(id -> {
            System.out.println("Actual argument: " + id);
            return id.equals("userId");
        }));
    } finally {
        session.finishMocking();
    }
}

TooManyActualInvocationsの解決手順

TooManyActualInvocationsエラーは、メソッドが期待以上の回数呼び出された場合に発生します。

1. エラーパターンの特定

@Test
public void demonstrateTooManyInvocations() {
    EmailService emailService = mock(EmailService.class);

    // 複数回呼び出し
    emailService.sendEmail("test@example.com");
    emailService.sendEmail("test@example.com");

    // 以下でエラーが発生
    verify(emailService).sendEmail("test@example.com");
    // org.mockito.exceptions.verification.TooManyActualInvocations:
    // Wanted 1 time but was called 2 times
}

2. 解決のためのチェックリスト

1. 呼び出し回数の確認

// 正確な回数を指定
verify(emailService, times(2)).sendEmail(any());

// または範囲を指定
verify(emailService, atLeast(1)).sendEmail(any());
verify(emailService, atMost(3)).sendEmail(any());

2. 重複呼び出しの特定

@Test
public void demonstrateInvocationTracking() {
    EmailService emailService = mock(EmailService.class);

    // 呼び出しを記録
    ArgumentCaptor<String> captor = ArgumentCaptor.forClass(String.class);

    emailService.sendEmail("test1@example.com");
    emailService.sendEmail("test2@example.com");

    // 全ての呼び出しを捕捉
    verify(emailService, times(2)).sendEmail(captor.capture());
    List<String> allValues = captor.getAllValues();

    // 呼び出しの分析
    allValues.forEach(System.out::println);
}

NullPointerExceptionを防ぐベストプラクティス

Mockitoを使用する際のNullPointerExceptionは、主にモックの初期化や設定の問題から発生します。

1. 一般的な原因と対策

@Test
public void demonstrateNullPointerPrevention() {
    // 悪い例
    UserService userService;  // 初期化されていない

    // 良い例
    @Mock
    UserService userService;  // @Mock アノテーションを使用

    @Before
    public void setup() {
        MockitoAnnotations.openMocks(this);
    }
}

2. 予防的アプローチ

@Test
public void demonstrateDefensiveMocking() {
    UserService userService = mock(UserService.class);

    // nullを返す可能性のあるメソッドに対する防御
    when(userService.findById(any()))
        .thenReturn(Optional.empty());  // nullの代わりにOptionalを使用

    // 引数のnullチェック
    when(userService.createUser(argThat(user -> 
        Objects.nonNull(user) && 
        Objects.nonNull(user.getName())
    ))).thenReturn(true);
}

3. エラー発生時のデバッグ手順

1. モックの初期化確認

@Test
public void demonstrateDebugProcess() {
    // モックの作成を確認
    UserService userService = mock(UserService.class);
    assertNotNull("Mock should not be null", userService);

    // スタブの設定を確認
    when(userService.findById("testId"))
        .thenReturn(new User("test"));

    // メソッド呼び出しの検証
    User result = userService.findById("testId");
    assertNotNull("Result should not be null", result);
}

実装のポイント：

1. エラー防止の基本原則
   • モックは必ず初期化する
   • スタブの戻り値は慎重に設定する
   • 引数のバリデーションを適切に行う
2. デバッグの効率化
   • エラーメッセージを注意深く読む
   • ステップバイステップで問題を切り分ける
   • テストの意図を明確にする
3. 保守性の向上
   • テストコードにも適切なコメントを入れる
   • 複雑なテストは小さく分割する
   • エラーケースも考慮したテストを書く

これらのエラー対策を理解し実践することで、より安定したテストコードを作成できます。次のセクションでは、verifyを使用したテストの設計パターンについて解説します。

チームでの活用に向けたベストプラクティス

コードレビューで指摘されやすいverifyの問題点

コードレビューの効率を上げ、品質を確保するために、よくある問題点とその改善方法を理解しましょう。

1. 過剰な検証

// 悪い例：すべての内部動作を検証
@Test
public void badExampleOverVerification() {
    UserService userService = mock(UserService.class);
    EmailService emailService = mock(EmailService.class);
    LogService logService = mock(LogService.class);

    UserManager manager = new UserManager(userService, emailService, logService);
    manager.createUser("test", "test@example.com");

    verify(userService).validateEmail("test@example.com");
    verify(userService).validateUsername("test");
    verify(userService).checkDuplicate("test");
    verify(userService).saveUser(any());
    verify(emailService).sendWelcomeEmail(any());
    verify(logService).logUserCreation(any());
}

// 良い例：重要な結果のみを検証
@Test
public void goodExampleFocusedVerification() {
    UserService userService = mock(UserService.class);
    EmailService emailService = mock(EmailService.class);
    LogService logService = mock(LogService.class);

    UserManager manager = new UserManager(userService, emailService, logService);
    manager.createUser("test", "test@example.com");

    // 重要な結果のみを検証
    verify(userService).saveUser(argThat(user -> 
        user.getUsername().equals("test") && 
        user.getEmail().equals("test@example.com")
    ));
    verify(emailService).sendWelcomeEmail(any());
}

2. 不適切な検証順序

// 悪い例：順序の検証が不要な場合でも指定
@Test
public void badExampleUnnecessaryOrder() {
    OrderService orderService = mock(OrderService.class);
    PaymentService paymentService = mock(PaymentService.class);

    OrderProcessor processor = new OrderProcessor(orderService, paymentService);
    processor.processOrder("ORD001");

    // 順序は重要でないのに指定している
    InOrder inOrder = inOrder(orderService, paymentService);
    inOrder.verify(orderService).validateOrder("ORD001");
    inOrder.verify(paymentService).processPayment(any());
}

// 良い例：必要な場合のみ順序を検証
@Test
public void goodExampleOrderVerification() {
    TransactionService transactionService = mock(TransactionService.class);

    // トランザクション処理では順序が重要
    transactionService.beginTransaction();
    transactionService.commit();

    InOrder inOrder = inOrder(transactionService);
    inOrder.verify(transactionService).beginTransaction();
    inOrder.verify(transactionService).commit();
}

テストコードの標準化とverifyの使用指針

チーム全体で一貫性のあるテストコードを作成するための指針を設定します。

1. テストクラスのテンプレート

public class StandardTestTemplate {
    // 共通のモックオブジェクト
    @Mock
    private UserService userService;
    @Mock
    private EmailService emailService;

    // テスト対象クラス
    private UserManager userManager;

    @Before
    public void setup() {
        MockitoAnnotations.openMocks(this);
        userManager = new UserManager(userService, emailService);
    }

    @Test
    public void shouldSuccessfullyCreateUser() {
        // Given
        String username = "testUser";
        String email = "test@example.com";
        when(userService.isEmailAvailable(email)).thenReturn(true);

        // When
        userManager.createUser(username, email);

        // Then
        verify(userService).saveUser(argThat(user -> 
            user.getUsername().equals(username) &&
            user.getEmail().equals(email)
        ));
    }
}

2. 命名規約とコメント

// テストメソッドの命名規約
public class UserServiceTest {
    @Test
    public void shouldSendWelcomeEmail_whenUserIsCreated() {
        // テストの説明をコメントで記載
        // Given: 新規ユーザー作成時の条件
        // When: ユーザーが作成された時
        // Then: ウェルカムメールが送信されること
    }

    @Test
    public void shouldNotifyAdmin_whenUserFailsToCreate() {
        // テストの説明をコメントで記載
        // Given: ユーザー作成が失敗する条件
        // When: ユーザー作成を試みた時
        // Then: 管理者に通知されること
    }
}

モックの使いすぎを防ぐための設計指針

モックの過剰な使用は、テストの保守性と信頼性を低下させる原因となります。

1. モック使用の判断基準

// 悪い例：すべての依存をモック化
public class BadExample {
    @Mock
    private UserRepository userRepo;
    @Mock
    private ValidationService validator;
    @Mock
    private DateTimeService dateTime;  // 不要なモック

    @Test
    public void overMockedTest() {
        when(dateTime.now()).thenReturn(LocalDateTime.now());  // 不要
        // ...
    }
}

// 良い例：必要なものだけモック化
public class GoodExample {
    @Mock
    private UserRepository userRepo;  // 外部依存なのでモック化
    private ValidationService validator = new ValidationService();  // 純粋なロジックなので実装を使用

    @Test
    public void appropriatelyMockedTest() {
        // テストに必要な最小限のモックのみ使用
    }
}

2. テスト容易性を考慮した設計

// 良い設計例：テスタビリティを考慮した依存注入
public class UserRegistrationService {
    private final UserRepository userRepo;
    private final EmailValidator emailValidator;
    private final NotificationService notificationService;

    // コンストラクタインジェクションで依存関係を明確に
    public UserRegistrationService(
        UserRepository userRepo,
        EmailValidator emailValidator,
        NotificationService notificationService
    ) {
        this.userRepo = userRepo;
        this.emailValidator = emailValidator;
        this.notificationService = notificationService;
    }

    // ビジネスロジックと外部依存を分離
    public RegistrationResult registerUser(UserDto userDto) {
        if (!emailValidator.isValid(userDto.getEmail())) {
            return RegistrationResult.invalid("Invalid email");
        }

        User user = userRepo.save(User.fromDto(userDto));
        notificationService.sendWelcomeEmail(user);
        return RegistrationResult.success(user);
    }
}

実装のポイント：

1. コードレビューの効率化
   • 検証の範囲を適切に設定
   • 順序の検証は必要な場合のみ
   • テストの意図を明確に記述
2. 標準化によるメリット
   • チーム内での一貫性確保
   • レビュー効率の向上
   • 新メンバーの学習曲線の緩和
3. 適切なモック使用
   • 外部依存のみモック化
   • ビジネスロジックは実装を使用
   • テスタビリティを考慮した設計

これらのベストプラクティスを適切に活用することで、チーム全体のテストコードの品質と保守性を向上させることができます。

まとめ：効果的なMockito.verifyの活用に向けて

本記事で学んだ重要なポイント

1. 基本概念と使い方
   • verifyメソッドは、モックオブジェクトの振る舞いを検証するための強力なツール
   • 基本構文から応用的な使い方まで、段階的な理解が重要
   • 適切な引数マッチャーの選択が効果的なテストの鍵
2. 実践的な活用パターン
   • 非同期処理のテスト手法
   • 例外処理の適切な検証方法
   • スパイとモックの使い分け
3. よくあるエラーへの対応
   • WantedButNotInvokedの原因と解決
   • TooManyActualInvocationsの防止方法
   • NullPointerExceptionを回避するベストプラクティス
4. 設計パターンとベストプラクティス
   • Given-When-Then形式でのテスト構造化
   • テストの可読性と保守性の向上
   • チーム開発における標準化とレビューのポイント

実践に向けたステップ

1. 基本から始める

   // 最もシンプルな形から始めましょう
   @Test
   public void startWithBasics() {
       UserService userService = mock(UserService.class);
       userService.createUser("test");
       verify(userService).createUser("test");
   }

2. 段階的な改善

   // 基本的なテストから徐々に改善を重ねる
   @Test
   public void improveGradually() {
       UserService userService = mock(UserService.class);

       // 基本的な検証から...
       userService.createUser("test");
       verify(userService).createUser("test");

       // より堅牢な検証へ
       verify(userService, times(1)).createUser(argThat(name ->
           name != null && name.length() > 0
       ));
   }

3. チーム全体での品質向上

   // チームで共有できるテストヘルパーの例
   public class TestHelper {
       public static UserServiceVerifier verifyUserService(UserService service) {
           return new UserServiceVerifier(service);
       }
   }

   @Test
   public void teamwideQualityImprovement() {
       UserService userService = mock(UserService.class);
       userService.createUser("test");

       verifyUserService(userService)
           .hasCreatedUser("test")
           .hasNotDeletedAnyUser();
   }

次のステップに向けて

1. さらなる学習の方向性
   • Mockitoの高度な機能の探求
   • テスト駆動開発（TDD）との組み合わせ
   • コードカバレッジの向上
2. 実践的な課題への取り組み
   • 実際のプロジェクトでの段階的な導入
   • チーム内でのベストプラクティスの共有
   • レビュープロセスの確立
3. 継続的な改善
   • テストコードの定期的な見直し
   • 新しいパターンやプラクティスの適用
   • チームメンバーとの知識共有

おわりに

Mockito.verifyは、単体テストにおける検証を強力にサポートするツールです。本記事で解説した内容を基に、まずは基本的な使い方から始め、徐々に応用的な技術を取り入れていくことをお勧めします。

テストコードの品質は、プロジェクト全体の品質に直結します。チーム全体で継続的に改善を重ねることで、より信頼性の高いソフトウェア開発が実現できます。

ぜひ、この記事で学んだ内容を実践し、より良いテストコードの作成に取り組んでください。