Posted inDevOps

ユニットテストだけでは不十分な理由：実践的なインテグレーションテストのためのTestcontainers活用術

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

「インメモリ」という近道の高い代償

ユニットテストはパスして「グリーン」なのに、本番環境のログはエラーで「真っ赤」になっている。そんな光景を目にしたことはありませんか？ テストで使用される「インメモリ」のH2データベースでは受け入れられるクエリが、本番のPostgreSQLインスタンスではことごとく拒否されるというのは、よくある話です。

かつて私は、モック環境では完璧に動作したPostgres固有のウィンドウ関数が本番でクラッシュを引き起こしたために、4時間もデバッグに費やしたことがあります。テストをH2に依存するのは、マラソンの練習をトレッドミルで行うようなものです。便利ではありますが、実際の地形（本番環境）への備えにはなりません。

また、共有のテスト用データベースを維持するのも同様に苦痛です。2人の開発者が同時にCI/CDビルドを実行すると、お互いのレコードを上書きしてしまい、原因不明の不安定なテスト（フラッキーテスト）を引き起こすことがよくあります。Testcontainersは、Dockerを活用して、分離された使い捨ての依存関係をオンデマンドで立ち上げることで、この問題を解決します。

インテグレーションテスト手法の比較

なぜプログラムによるインフラ制御が支持されているのかを理解するために、これまでの外部依存関係の扱い方を振り返ってみましょう。

1. モックとインメモリデータベース

これは「速いが本物ではない」アプローチです。Mockitoを使用してデータベースをシミュレートしたり、RAM上でH2インスタンスを実行したりします。テストはミリ秒単位で完了しますが、設定エラー、スキーマの不一致、トリガーやストアドプロシージャなどのデータベース固有のロジックを捉えることはできません。これは偽りの安心感を与えてしまいます。

2. 壊れやすいDocker Compose設定

多くのチームがテスト専用のdocker-compose.ymlファイルを維持しています。これでは、開発者がテストスイートを開始する前に手動でdocker-compose upを実行する必要があります。CI/CD環境において、これは非常に厄介です。コンテナが「正常」であることを確認してからテストを開始し、ビルドが途中でクラッシュした場合にはクリーンアップを処理するカスタムスクリプトを書かなければなりません。

3. Testcontainers：Infrastructure as Code

Testcontainersは、テストコード内で直接コンテナのライフサイクルを管理することで、この状況を一変させます。テストスイートが開始されると、ライブラリがDocker APIと通信して必要なイメージをプルし、サービスを起動します。テストが終了すると、すべてをクリーンに削除します。ポートマッピング、ヘルスチェック、リソースのクリーンアップが、手動の介入なしで自動化されます。

トレードオフ：導入する価値はあるか？

どんなツールも万能薬ではありません。Testcontainersはモダンなサービス開発において私のデフォルトの選択肢ですが、リソースのオーバーヘッドを考慮する必要があります。

メリット

  • 完全な分離： 各テスト実行ごとに真っさらなデータベースが用意されます。「汚れたデータ」によるランダムな失敗に悩まされることはもうありません。
  • 本番環境との同等性： 本番で使用しているものと全く同じバージョン（例：PostgreSQL 15.4）に対してテストを行えます。
  • スムーズなオンボーディング： 新しい開発者はDockerをインストールするだけで済みます。ローカルデータベースを設定するために、10ステップもあるREADMEに従う必要はありません。
  • 動的なポートマッピング： 内部ポート（5432など）をホスト上のランダムなハイレンジポートにマッピングします。これにより、並列ビルド中に発生する「Address already in use」エラーを防ぐことができます。

課題

  • 起動の遅延： 200MBのDockerイメージをプルし、エンジンが初期化されるのを待つために、最初のテスト実行に約10〜20秒追加されます。
  • リソースの消費： Postgres、Redis、Kafkaのコンテナをフルセットで実行すると、2GBから4GBのRAMを簡単に消費します。
  • CI/CDの複雑化： ビルドランナーがDockerをサポートしている必要があります。これには、「Docker-in-Docker（DinD）」設定やDockerソケットのマウントが必要になる場合があります。

モダンなプロジェクトのための推奨構成

この例ではJavaとSpring Bootのスタックを使用しますが、Python、Go、Node.jsを使用する場合でも基本的なロジックは同じです。まず、pom.xmlに必要な依存関係を追加します。

<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>postgresql</artifactId>
    <version>1.19.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>junit-jupiter</artifactId>
    <version>1.19.0</version>
    <scope>test</scope>
</dependency>

実装：初めてのインテグレーションテスト

これを正しく設定することは、バックエンドエンジニアにとって基礎となるスキルです。実際の環境に即したインテグレーションテストの信頼性を一度体験すれば、データレイヤーをモック化することは後退しているように感じるでしょう。

1. コンテナ環境の定義

まずPostgreSQLコンテナを宣言します。イメージサイズを小さく抑え、ダウンロード時間を短縮するために、-alpineタグを使用することをお勧めします。

@Testcontainers
@SpringBootTest
class MyIntegrationTest {

    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15-alpine")
        .withDatabaseName("testdb")
        .withUsername("user")
        .withPassword("password");

    @DynamicPropertySource
    static void configureProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
        registry.add("spring.datasource.username", postgres::getUsername);
        registry.add("spring.datasource.password", postgres::getPassword);
    }

    @Test
    void connectionEstablished() {
        assertThat(postgres.isCreated()).isTrue();
        assertThat(postgres.isRunning()).isTrue();
    }
}

2. DynamicPropertySourceの役割

@DynamicPropertySourceアノテーションは非常に重要です。Testcontainersはデータベースにランダムなポートを割り当てるため、アプリケーションは事前にJDBC URLを知る方法がありません。このメソッドは、実行時に動的なURLを取得し、コンテキストがロードされる前にSpring環境に注入します。

3. CI/CD統合：GitHub Actions

ubuntu-latestのような最新のランナーにはDockerがプリインストールされているため、これらのテストをパイプラインで実行するのは驚くほど簡単です。以下は、合理化された.github/workflows/test.ymlの例です。

name: Java CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - name: JDK 17のセットアップ
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven
    - name: テストの実行
      run: mvn test
      env:
        DOCKER_HOST: unix:///var/run/docker.sock

4. プロのヒント：高速化のためのシングルトンコンテナ

50個のテストクラスがあり、それぞれが独自のコンテナを立ち上げていると、CIビルドに永遠に時間がかかってしまいます。より優れた戦略は、シングルトンコンテナパターンです。抽象ベースクラスを使用することで、コンテナを一度だけ起動し、スイート全体で共有できます。私の経験では、これによりビルド時間を最大70%短縮できます。

public abstract class BaseIntegrationTest {
    static final PostgreSQLContainer<?> postgres;

    static {
        postgres = new PostgreSQLContainer<>("postgres:15-alpine");
        postgres.start();
    }

    @DynamicPropertySource
    static void configureProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.datasource.url", postgres::getJdbcUrl);
    }
}

最後に

Testcontainersは開発と本番のギャップを埋めてくれます。すべての開発者とCIランナーが同じインフラストラクチャ上で動作することを保証することで、「自分のマシンでは動く」という言い訳を排除します。15秒の起動時間はかかりますが、リリースに対する自信が得られることを考えれば、待つ価値は十分にあります。まずは最も重要なデータベーステストの移行から始めてみてください。次回の本番デプロイ時に、過去の自分に感謝することになるでしょう。

Share:
Tags: