Spring BootアプリのテストをSpockで書く(続編)

以前にSpring BootアプリケーションのテストをSpockで書く方法を紹介しましたが、この方法ではテストの所要時間が長くなる問題がありました。本稿では他の方法を紹介します。

int128.hatenablog.com

具体的には、インナークラスの @TestConfiguration でMockを定義するとSpecificationクラスごとにApplication Contextが再生成されてしまうため、スローテストの原因になる問題がありました。

    // Specificationのインナークラス
    @TestConfiguration
    static class MockConfig {
        final detachedMockFactory = new DetachedMockFactory()

        @Bean
        ExternalApiClient externalApiClient() {
            detachedMockFactory.Mock(ExternalApiClient)
        }
    }

特定のテストケースだけBeanをMockに置換したい場合はこの方法が必要ですが、多くの場合は必要ないはずです。その前にプロダクトコードの設計を見直す方がよいでしょう。

コンポーネントテスト

コンポーネントテストのレベルでは、コンストラクタでMockを注入する方法で十分です。

// プロダクトコード
@Component
class BarService {
    final ExternalApiClient client

    BarService(ExternalApiClient client) {
        this.client = client
        assert client
    }
}

// テストコード
@SpringBootTest(webEnvironment = NONE)
class BarServiceSpec extends Specification {
    @Subject BarService service

    ExternalApiClient client = Mock()

    def setup() {
        service = new BarService(client)
    }
}

Mockではなく本物のBeanが必要な場合は、Specificationクラスに @Autowired なプロパティを追加してBeanを取得します。

@SpringBootTest(webEnvironment = NONE)
class BarServiceSpec extends Specification {
    @Subject BarService service

    ExternalApiClient client = Mock()  // Mock Bean

    @Autowired HelloProvider provider  // 本物のBean

    def setup() {
        service = new BarService(client, provider)
    }
}

E2Eテスト

冒頭で述べた方法ではSpecificationごとにMockを定義していましたが、全テストケースで共通のMockを定義するとApplication Contextが再利用されるので所要時間が大幅に短くなります。

// Mock定義
@Configuration
class IntegrationTestConfiguration {
    private final detachedMockFactory = new DetachedMockFactory()

    @Bean
    ExternalApiClient externalApiClient() {
        detachedMockFactory.Mock(ExternalApiClient)
    }
}

// テストコード
@SpringBootTest(webEnvironment = RANDOM_PORT)
class BarControllerSpec extends Specification {
    @Autowired TestRestTemplate restTemplate

    @Autowired ExternalApiClient client
}

@Primary を付けるなどの工夫をすれば、この方法とSpecificationごとにMockを定義する方法を組み合わせて利用できると思います。（未検証…）

まとめ

これまでに以下の方法を紹介しました。

SpecificationクラスごとにMockを定義する方法
- Specificationクラスごとに本物とMockを使い分けられる。
- 個別にApplication Contextが生成されるので、スローテストの原因になる。
コンストラクタでMockを注入する方法
- Application Contextが再利用されるので、テストの所要時間が短い。
- テストコードでコンストラクタ呼び出しを記述するのが面倒。
全テストケースで共通のMockを定義する方法
- Application Contextが再利用されるので、テストの所要時間が短い。
- Mock定義が共通なので融通が利かない。

参考までにGitHubにサンプルプロジェクトを置いています。

github.com