【実践ガイド】JUnitとMockitoで学ぶ9つのモックパターン – 現場で使える具体例付き

モックとは？JUnitテストにおける重要性

モックを使用する目的と効果

モックとは、テスト対象のクラスが依存している外部のオブジェクトを模倣する代用品です。実際のオブジェクトの代わりにモックを使用することで、以下のような効果が得られます：

JUnitテストでモックが必要なケース3選

1. 外部サービスとの通信が必要な場合

// 実際のAPIクライアント
public class WeatherApiClient {
    public WeatherInfo getWeather(String city) {
        // 実際のAPI呼び出し（テスト時に呼びたくない）
        return callExternalApi(city);
    }
}

// テスト対象のクラス
public class WeatherService {
    private WeatherApiClient client;

    public boolean isSunnyDay(String city) {
        WeatherInfo info = client.getWeather(city);  // ここをモック化
        return "SUNNY".equals(info.getCondition());
    }
}

2. データベース操作を含む処理

// データベースアクセスを行うリポジトリ
public class UserRepository {
    public User findById(Long id) {
        // 実際のDB接続（テスト時に避けたい）
        return executeQuery("SELECT * FROM users WHERE id = ?", id);
    }
}

// テスト対象のサービス
public class UserService {
    private UserRepository repository;

    public String getUserName(Long id) {
        User user = repository.findById(id);  // ここをモック化
        return user.getName();
    }
}

3. 時間に依存する処理

// 現在時刻に依存する処理
public class ExpirationChecker {
    public boolean isExpired(LocalDateTime expirationDate) {
        LocalDateTime now = LocalDateTime.now();  // ここをモック化
        return now.isAfter(expirationDate);
    }
}

ケースごとのメリット

モックの使用は、特に大規模なエンタープライズアプリケーションの開発において、テストの品質と開発効率を両立させるための重要な技術となっています。次のセクションでは、実際にJUnitでモックを実装するための準備手順について説明します。

JUnitでモックを実装するための準備

Mockitoのセットアップ方法

Maven プロジェクトの場合

pom.xmlに以下の依存関係を追加します：

<dependencies>
    <!-- JUnit 5 -->
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.9.2</version>
        <scope>test</scope>
    </dependency>

    <!-- Mockito Core -->
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-core</artifactId>
        <version>5.3.1</version>
        <scope>test</scope>
    </dependency>

    <!-- Mockito JUnit Jupiter -->
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-junit-jupiter</artifactId>
        <version>5.3.1</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Gradle プロジェクトの場合

build.gradleに以下を追加：

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.9.2'
    testImplementation 'org.mockito:mockito-core:5.3.1'
    testImplementation 'org.mockito:mockito-junit-jupiter:5.3.1'
}

テストクラスの基本構成

基本的なテストクラスの構造は以下の通りです：

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.Mock;
import org.mockito.InjectMocks;
import org.mockito.junit.jupiter.MockitoExtension;
import static org.mockito.Mockito.*;
import static org.junit.jupiter.api.Assertions.*;

@ExtendWith(MockitoExtension.class)  // Mockitoの機能を有効化
public class UserServiceTest {

    @Mock  // モック化するオブジェクト
    private UserRepository userRepository;

    @InjectMocks  // モックを注入される側のクラス
    private UserService userService;

    @BeforeEach
    void setUp() {
        // テストケース実行前の共通設定
    }

    @Test
    void testGetUserName() {
        // モックの振る舞いを定義
        when(userRepository.findById(1L))
            .thenReturn(new User(1L, "テストユーザー"));

        // テスト対象メソッドの実行
        String userName = userService.getUserName(1L);

        // 検証
        assertEquals("テストユーザー", userName);
        verify(userRepository).findById(1L);
    }
}

主要なアノテーションと役割：

これでMockitoを使用したテストの実装準備が整いました。次のセクションでは、この基本構成を使って具体的なモックパターンの実装方法を見ていきます。

実践！9つの基本的なモックパターン

1. 戻り値の固定（when-thenReturn）

最も基本的なモックパターンです。メソッドの戻り値を指定した値に固定します。

// テスト対象のサービス
public class UserService {
    private UserRepository userRepository;

    public User findActiveUser(Long id) {
        User user = userRepository.findById(id);
        if (user != null && user.isActive()) {
            return user;
        }
        return null;
    }
}

// テストコード
@Test
void testFindActiveUser() {
    // モックの戻り値を設定
    when(userRepository.findById(1L))
        .thenReturn(new User(1L, "テストユーザー", true));

    // テスト実行
    User result = userService.findActiveUser(1L);

    // 検証
    assertNotNull(result);
    assertEquals("テストユーザー", result.getName());
}

2. 例外のスロー（when-thenThrow）

異常系のテストを行う際に、意図的に例外をスローさせます。

// テスト対象のサービス
public class PaymentService {
    private PaymentGateway gateway;

    public void processPayment(Payment payment) throws PaymentException {
        try {
            gateway.execute(payment);
        } catch (GatewayException e) {
            throw new PaymentException("決済処理に失敗しました", e);
        }
    }
}

// テストコード
@Test
void testProcessPaymentFailure() {
    Payment payment = new Payment(1000, "JPY");

    // 例外をスローするように設定
    when(gateway.execute(payment))
        .thenThrow(new GatewayException("接続エラー"));

    // 例外が発生することを検証
    assertThrows(PaymentException.class, () -> {
        paymentService.processPayment(payment);
    });
}

3. void メソッドのモック化（doNothing-when）

戻り値のないメソッドのモック化に使用します。

// テスト対象のサービス
public class NotificationService {
    private EmailSender emailSender;

    public void notifyUser(String email, String message) {
        emailSender.sendEmail(email, message);
    }
}

// テストコード
@Test
void testNotifyUser() {
    String email = "test@example.com";
    String message = "テストメッセージ";

    // voidメソッドのモック化
    doNothing().when(emailSender).sendEmail(email, message);

    // テスト実行
    notificationService.notifyUser(email, message);

    // メソッドが呼び出されたことを検証
    verify(emailSender).sendEmail(email, message);
}

4. 引数のマッチング（ArgumentMatchers）

柔軟な引数のマッチングを行う場合に使用します。

@Test
void testWithArgumentMatchers() {
    // any()を使用した任意の引数のマッチング
    when(userRepository.findByEmail(anyString()))
        .thenReturn(new User("test@example.com"));

    // 特定のパターンにマッチする引数
    when(userRepository.findByEmail(matches(".*@example\\.com")))
        .thenReturn(new User("test@example.com"));

    // 数値範囲のマッチング
    when(productService.getPrice(argThat(id -> id > 0 && id < 100)))
        .thenReturn(BigDecimal.valueOf(1000));
}

5. メソッド呼び出し回数の検証（verify）

メソッドが適切な回数呼び出されたことを検証します。

@Test
void testVerifyMethodCalls() {
    // テストの準備
    String email = "test@example.com";

    // メソッド実行
    notificationService.sendMultipleNotifications(email);

    // 検証
    verify(emailSender, times(1)).sendEmail(email, "初回通知");
    verify(emailSender, times(2)).sendReminder(email);
    verify(emailSender, never()).sendError(any());

    // 順序の検証
    InOrder inOrder = inOrder(emailSender);
    inOrder.verify(emailSender).sendEmail(email, "初回通知");
    inOrder.verify(emailSender, times(2)).sendReminder(email);
}

6. スパイを使用したパーシャルモック

実際のオブジェクトの一部のメソッドだけをモック化します。

@Test
void testWithSpy() {
    // 実際のオブジェクトをスパイ化
    UserService userServiceSpy = spy(new UserService(userRepository));

    // 特定のメソッドだけをモック化
    doReturn("モック値")
        .when(userServiceSpy)
        .formatUserName(any());

    // 他のメソッドは実際の実装を使用
    String result = userServiceSpy.getUserDisplayName(1L);
}

7. static メソッドのモック化

静的メソッドのモック化には特別な設定が必要です。

// モック化したい静的メソッドを含むクラス
public class DateUtils {
    public static LocalDateTime getCurrentDateTime() {
        return LocalDateTime.now();
    }
}

// テストコード
@Test
void testStaticMethod() {
    try (MockedStatic<DateUtils> dateUtils = mockStatic(DateUtils.class)) {
        // 静的メソッドのモック化
        dateUtils.when(DateUtils::getCurrentDateTime)
            .thenReturn(LocalDateTime.of(2024, 1, 1, 0, 0));

        // テスト実行
        LocalDateTime result = DateUtils.getCurrentDateTime();

        // 検証
        assertEquals(LocalDateTime.of(2024, 1, 1, 0, 0), result);
    }
}

8. コンストラクタのモック化

新しいオブジェクトの生成をモック化します。

@Test
void testConstructorMocking() {
    // モック化したいクラスのコンストラクタを準備
    User mockUser = mock(User.class);
    when(mockUser.getName()).thenReturn("モックユーザー");

    // コンストラクタのモック化
    try (MockedConstruction<User> mocked = mockConstruction(User.class,
        (mock, context) -> {
            when(mock.getName()).thenReturn("モックユーザー");
        })) {

        // 新しいインスタンス生成時にモックが返される
        User user = new User();
        assertEquals("モックユーザー", user.getName());
    }
}

9. 複数の戻り値を順番に返す（thenReturn chain）

一つのメソッド呼び出しに対して、複数の戻り値を順番に返します。

@Test
void testMultipleReturns() {
    // 複数の戻り値を設定
    when(userRepository.getNextUser())
        .thenReturn(new User("ユーザー1"))
        .thenReturn(new User("ユーザー2"))
        .thenReturn(new User("ユーザー3"));

    // または以下のように書くこともできます
    when(userRepository.getNextUser())
        .thenReturn(
            new User("ユーザー1"),
            new User("ユーザー2"),
            new User("ユーザー3")
        );

    // 順番に異なる値が返される
    assertEquals("ユーザー1", userRepository.getNextUser().getName());
    assertEquals("ユーザー2", userRepository.getNextUser().getName());
    assertEquals("ユーザー3", userRepository.getNextUser().getName());
}

これらのパターンを組み合わせることで、複雑なテストシナリオにも対応できます。次のセクションでは、実際のプロジェクトでよく使用される具体的な例を見ていきます。

実際のプロジェクトでよくあるモックの使用例

外部APIとの通信処理のモック化

外部APIとの通信は、テストの実行時間や安定性に大きく影響します。以下は、REST APIクライアントをモック化する実践的な例です。

// APIクライアントインターフェース
public interface WeatherApiClient {
    WeatherResponse getWeatherInfo(String cityCode) throws ApiException;
}

// テスト対象のサービス
@Service
public class WeatherService {
    private final WeatherApiClient apiClient;
    private final WeatherCache cache;

    public WeatherInfo getWeatherForecast(String cityCode) throws ServiceException {
        try {
            // キャッシュチェック
            WeatherInfo cachedInfo = cache.get(cityCode);
            if (cachedInfo != null) {
                return cachedInfo;
            }

            // API呼び出し
            WeatherResponse response = apiClient.getWeatherInfo(cityCode);
            WeatherInfo weatherInfo = convertToWeatherInfo(response);

            // キャッシュ保存
            cache.put(cityCode, weatherInfo);

            return weatherInfo;
        } catch (ApiException e) {
            throw new ServiceException("天気情報の取得に失敗しました", e);
        }
    }
}

// テストコード
@ExtendWith(MockitoExtension.class)
class WeatherServiceTest {
    @Mock
    private WeatherApiClient apiClient;

    @Mock
    private WeatherCache cache;

    @InjectMocks
    private WeatherService weatherService;

    @Test
    void testGetWeatherForecast_APISuccess() throws Exception {
        // テストデータ
        String cityCode = "TOKYO";
        WeatherResponse mockResponse = new WeatherResponse("晴れ", 25.0);

        // モックの設定
        when(cache.get(cityCode)).thenReturn(null);  // キャッシュミス
        when(apiClient.getWeatherInfo(cityCode)).thenReturn(mockResponse);

        // テスト実行
        WeatherInfo result = weatherService.getWeatherForecast(cityCode);

        // 検証
        assertNotNull(result);
        assertEquals("晴れ", result.getCondition());
        assertEquals(25.0, result.getTemperature());

        // キャッシュ保存の確認
        verify(cache).put(eq(cityCode), any(WeatherInfo.class));
    }
}

データベース操作のモック化

トランザクション処理を含むデータベース操作のテストは、モックを活用することで効率的に行えます。

// リポジトリ
public interface OrderRepository extends JpaRepository<Order, Long> {
    List<Order> findByUserId(Long userId);
}

// テスト対象のサービス
@Service
@Transactional
public class OrderService {
    private final OrderRepository orderRepository;
    private final PaymentService paymentService;

    public OrderResult processOrder(OrderRequest request) {
        // 注文情報の保存
        Order order = createOrder(request);
        Order savedOrder = orderRepository.save(order);

        // 支払い処理
        PaymentResult payment = paymentService.processPayment(
            request.getPaymentInfo()
        );

        if (!payment.isSuccess()) {
            throw new PaymentException("支払い処理に失敗しました");
        }

        return new OrderResult(savedOrder.getId(), payment.getTransactionId());
    }
}

// テストコード
@Test
void testProcessOrder_Success() {
    // テストデータ
    OrderRequest request = new OrderRequest(/* パラメータ */);
    Order mockOrder = new Order(/* パラメータ */);
    PaymentResult mockPayment = new PaymentResult(true, "TRX123");

    // モックの設定
    when(orderRepository.save(any(Order.class))).thenReturn(mockOrder);
    when(paymentService.processPayment(any()))
        .thenReturn(mockPayment);

    // テスト実行
    OrderResult result = orderService.processOrder(request);

    // 検証
    assertNotNull(result);
    assertEquals(mockOrder.getId(), result.getOrderId());
    assertEquals("TRX123", result.getTransactionId());
}

時間に依存する処理のモック化

スケジュール処理やタイムアウト処理など、時間に依存するロジックのテストでは、時間をコントロールできるようにモック化します。

// 時間提供サービス
public class TimeProvider {
    public LocalDateTime getCurrentTime() {
        return LocalDateTime.now();
    }
}

// テスト対象のサービス
@Service
public class ReservationService {
    private final TimeProvider timeProvider;

    public boolean isReservationAvailable(
        LocalDateTime reservationTime,
        int maxDaysAhead
    ) {
        LocalDateTime currentTime = timeProvider.getCurrentTime();
        LocalDateTime maxAllowedTime = currentTime.plusDays(maxDaysAhead);

        return !reservationTime.isBefore(currentTime) 
            && !reservationTime.isAfter(maxAllowedTime);
    }
}

// テストコード
@Test
void testIsReservationAvailable() {
    // 固定の現在時刻を設定
    LocalDateTime fixedCurrentTime = 
        LocalDateTime.of(2024, 1, 1, 10, 0);
    when(timeProvider.getCurrentTime())
        .thenReturn(fixedCurrentTime);

    // 予約可能な時間帯のテスト
    assertTrue(reservationService.isReservationAvailable(
        fixedCurrentTime.plusDays(2), 7));

    // 予約不可能な時間帯のテスト（期限超過）
    assertFalse(reservationService.isReservationAvailable(
        fixedCurrentTime.plusDays(8), 7));
}

これらの実践的な例は、実際のプロジェクトでよく遭遇する状況に基づいています。次のセクションでは、モックを使用する際の注意点とベストプラクティスについて説明します。

モックを使用する際の注意点とベストプラクティス

過度なモック化を避ける方法

過度なモック化は、テストの保守性と信頼性を低下させる原因となります。以下のガイドラインに従って、適切なモック化を心がけましょう。

1. モック化の判断基準

// アンチパターン：過度なモック化
@Test
void overMockedTest() {
    // ユーティリティクラスまでモック化（不要）
    when(StringUtils.isEmpty(anyString())).thenCallRealMethod();

    // POJOもモック化（不要）
    User mockUser = mock(User.class);
    when(mockUser.getName()).thenReturn("テスト");

    // 本来のテスト...
}

// 推奨パターン：必要最小限のモック化
@Test
void properlyMockedTest() {
    // 実際のPOJOを使用
    User realUser = new User("テスト");

    // 外部依存のみモック化
    when(userRepository.findById(1L)).thenReturn(Optional.of(realUser));

    // 本来のテスト...
}

テストの可読性を高めるTips

1. テストデータのセットアップを明確に

// アンチパターン：わかりにくいセットアップ
@Test
void unclearTest() {
    when(repository.findById(any()))
        .thenReturn(Optional.of(new Entity(1L, "x", true, 100)));
}

// 推奨パターン：意図が明確なセットアップ
@Test
void clearTest() {
    // Given
    Entity testEntity = Entity.builder()
        .id(1L)
        .name("アクティブユーザー")
        .active(true)
        .score(100)
        .build();

    when(repository.findById(1L))
        .thenReturn(Optional.of(testEntity));
}

2. BDDスタイルのテスト記述

@Test
void shouldProcessOrderWhenPaymentSucceeds() {
    // Given（前提条件）
    OrderRequest request = createTestOrderRequest();
    when(paymentService.processPayment(any()))
        .thenReturn(new PaymentResult(true, "TRX123"));

    // When（テスト対象の実行）
    OrderResult result = orderService.processOrder(request);

    // Then（結果の検証）
    assertThat(result)
        .isNotNull()
        .satisfies(r -> {
            assertThat(r.isSuccess()).isTrue();
            assertThat(r.getTransactionId()).isEqualTo("TRX123");
        });
}

モックの代わりにスタブを使うべきケース

単純な戻り値の固定だけが必要な場合は、完全なモックの代わりにスタブの使用を検討します。

// スタブの例
public class UserRepositoryStub implements UserRepository {
    private final Map<Long, User> userMap = new HashMap<>();

    public void addUser(User user) {
        userMap.put(user.getId(), user);
    }

    @Override
    public Optional<User> findById(Long id) {
        return Optional.ofNullable(userMap.get(id));
    }

    // 他のメソッドは最小限の実装
    @Override
    public List<User> findAll() {
        return new ArrayList<>(userMap.values());
    }
}

// スタブを使用したテスト
@Test
void testWithStub() {
    // スタブの準備
    UserRepositoryStub stub = new UserRepositoryStub();
    stub.addUser(new User(1L, "テストユーザー"));

    // スタブを使用したサービスのテスト
    UserService service = new UserService(stub);
    User result = service.findUser(1L);

    assertThat(result)
        .isNotNull()
        .extracting(User::getName)
        .isEqualTo("テストユーザー");
}

これらのベストプラクティスを適用することで、テストコードの品質と保守性が向上し、チーム全体の開発効率が上がります。

よくあるトラブルと解決方法

NullPointerExceptionが発生する場合の対処法

モックを使用したテストでNullPointerExceptionが発生する主な原因と解決方法を説明します。

1. モックの初期化忘れ

// 問題のあるコード
public class UserServiceTest {
    private UserRepository userRepository;  // @Mockアノテーション忘れ

    @InjectMocks
    private UserService userService;

    @Test
    void testGetUser() {
        // NullPointerException発生！
        when(userRepository.findById(1L))
            .thenReturn(Optional.of(new User()));
    }
}

// 解決策
@ExtendWith(MockitoExtension.class)  // 重要！
public class UserServiceTest {
    @Mock  // 追加
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void testGetUser() {
        // 正常に動作
        when(userRepository.findById(1L))
            .thenReturn(Optional.of(new User()));
    }
}

2. 深いオブジェクトグラフの処理

// 問題が発生しやすいケース
@Test
void testDeepObjectGraph() {
    when(order.getCustomer().getAddress().getCountry())
        .thenReturn("日本");  // NullPointerException!
}

// 解決策：チェーンの各オブジェクトをモック化
@Test
void testDeepObjectGraph() {
    Customer mockCustomer = mock(Customer.class);
    Address mockAddress = mock(Address.class);

    when(order.getCustomer()).thenReturn(mockCustomer);
    when(mockCustomer.getAddress()).thenReturn(mockAddress);
    when(mockAddress.getCountry()).thenReturn("日本");
}

モックの戻り値が期待通りでない場合の確認ポイント

1. 引数のマッチング問題

// 問題のあるコード
@Test
void testArgumentMatching() {
    User user = new User(1L, "テスト");
    when(userRepository.save(user)).thenReturn(user);  // 動作しない

    User result = userService.createUser(new User(1L, "テスト"));
    // 期待した戻り値が返ってこない
}

// 解決策：適切な引数マッチャーを使用
@Test
void testArgumentMatching() {
    User user = new User(1L, "テスト");

    // 方法1：anyを使用
    when(userRepository.save(any(User.class))).thenReturn(user);

    // 方法2：カスタムマッチャーを使用
    when(userRepository.save(argThat(u -> 
        u.getId().equals(1L) && 
        u.getName().equals("テスト")
    ))).thenReturn(user);
}

verify()が失敗する際のデバッグ方法

1. 実行順序の問題

// 問題のあるコード
@Test
void testVerificationOrder() {
    // テスト実行
    notificationService.sendNotifications();

    // 検証順序が間違っている
    verify(emailSender).sendReminder();
    verify(emailSender).sendInitialEmail();  // 失敗！
}

// 解決策：InOrderを使用
@Test
void testVerificationOrder() {
    // テスト実行
    notificationService.sendNotifications();

    // 正しい順序で検証
    InOrder inOrder = inOrder(emailSender);
    inOrder.verify(emailSender).sendInitialEmail();
    inOrder.verify(emailSender).sendReminder();
}

2. 呼び出し回数の問題

@Test
void testCallCount() {
    // テスト実行
    for (int i = 0; i < 3; i++) {
        service.process();
    }

    // デバッグのためのより詳細な検証
    verify(repository, times(3)).save(any());  // 期待：3回
    verify(repository, atLeast(2)).save(any()); // 最低2回
    verify(repository, atMost(4)).save(any());  // 最大4回

    // 失敗時のデバッグ情報
    Mockito.verifyNoMoreInteractions(repository);
    // または
    Mockito.validateMockitoUsage();
}

トラブルシューティングのためのTips

1. モックの振る舞いの確認

   // モックの設定を出力
   System.out.println(mockingDetails(userRepository).printInvocations());

2. デバッグモードの有効化

   // テストクラスの先頭に追加
   @Before
   public void setup() {
       MockitoLogger.setLogger(new ConsoleLogger());
   }

3. モックの検証順序のリセット

   @AfterEach
   void tearDown() {
       Mockito.reset(userRepository);
   }

これらの問題解決テクニックを活用することで、モックを使用したテストのトラブルシューティングを効率的に行うことができます。

まとめ

JUnitとMockitoを使用したモックテストについて、基本から実践まで解説してきました。ここで重要なポイントを整理しましょう。

記事のポイント整理

1. モックの基本的な理解
   • テストの独立性を高める重要なテクニック
   • 外部依存を分離し、テストを安定化
   • パフォーマンスと信頼性の向上に貢献
2. 実装のための具体的なステップ
   • Mockitoの適切なセットアップ方法
   • 基本的なテストクラスの構成
   • アノテーションの正しい使用方法
3. 実践的な使用パターン
   • 9つの基本パターンの使い分け
   • 実際のプロジェクトでの具体的な適用例
   • 各パターンの利点と注意点
4. 品質向上のためのベストプラクティス
   • 過度なモック化を避ける
   • テストの可読性を重視
   • スタブの適切な使用
5. 効率的なトラブルシューティング
   • 一般的な問題の解決方法
   • デバッグの具体的な手順
   • 予防的な対策の実施

次のステップ

この記事で学んだ内容を実践に活かすために、以下のようなステップを推奨します：

1. 既存のテストコードの見直し
2. モックパターンの段階的な導入
3. チーム内でのベストプラクティスの共有
4. 継続的な改善とフィードバックの収集

モックテストは、現代のソフトウェア開発において不可欠なテクニックです。この記事で解説した内容を基に、プロジェクトの品質向上に取り組んでいただければ幸いです。