Testcontainers運用経験から分かった、良い点・困る点
お仕事先のWebアプリケーションに、Testcontainersを導入運用して数ヶ月経過しました。
良い点と困る点について、書き残しておきます。
前提
簡単な前提として、バックエンドDB・APIとフロントエンドの3層構成のよくあるWebアプリケーションアーキテクチャです。
そのアプリケーションに対して、Testcontainers の環境構築、Playwrightのブラウザ操作、Cucumberの振る舞いテストの3セットで、
E2Eテストを書いています。
よかったこと
一番は、ポータビリティの高さ です。
Testcontainers は Docker を起動停止を操作するだけのライブラリのため、
Docker が動く環境であれば、どこでも同様の環境を構築できます。
そのため、お手元のローカル環境やGitHub ActionsやCircleCIといったCI環境であっても動作します。
例えば、ソフトウェア依存関係アップデートツール（Dependabot、Renovateなど）で起票されるPullRequest毎に対して、
Testcontainers のE2Eテストを動かすことができます。
アップデートによっては、Webアプリケーションが壊れるかどうかを早期に発見できる良さがあります。
もちろん、開発ブランチ毎にもTestcontainersを動かすこともできるため、開発PRの段階でE2Eテストが壊れるかどうか判断できます。
この早期発見は、リリース時点で検出→リバート→再リリースの手間が省かれます。
二番目の良さは、エラーの再現性の高さ です。
Testcontainers では Docker を使ってアプリケーションを構築します。
データベースの作成やマイグレーション、シード実行、アプリケーションのモジュールインストールやビルド。
そして、起動後のサービスにPlaywrightでブラウザ操作をします。
設計次第ですが、基本的にTestcontainers 内で完結できるため、エラー発生時の調査がしやすいのです。
ローカル環境にて、同様のソースコードをチェックアウトさせすれば、ほぼ間違いなくエラーを再現できます。
これは、よくあるステージング環境E2Eテストであれば、そうはいきません。
データ起因であったり、外部ネットワーク通信といった要因よって不安定にテストが失敗しますが、
それらを再現するのにもデータの準備（リセット）など手間がかかります。
その点、Testcontainers であれば データは全て冪等で同じ状態を構築できる ため心配なく、
Docker ネットワーク内で WebサーバからAPIサーバに内部通信するため経路が短く不安定になりにくいです。
三番目の良さは、テストの汎用性の高さ です。
一般的なE2Eテストの検査はブラウザ視点のものが多いのですが、
Testcontainersによるテストであれば、 DBに格納されているデータをチェックできます 。
Docker のシステム日付を変更すれば 年末年始のテスト も実現できます。
特別なデータをステージング環境でメンテナンスする必要がなく、Testcontainers用のシードデータを用意しておけば大丈夫です。
また、 バッチ起動やキューIN・OUT、メール送受信 といったテストも可能です。
多言語対応であれば、Docker内の言語設定とPlaywrightの言語設定を修正すれば実現できます。
困る点
一番は、実行時間の遅さ です。
モジュールインストールやDockerビルド、起動とテストとやることがいっぱいです。
愚直に直列で構築すると、簡単なテストだけでも10分以上かかります。
その内のセットアップが9割を占め、残り1割がテスト実行となります。
そのため、CI環境でTestcontainersを動かすには、いくつか設計が必要になります。
1つは、キャッシュの有効活用 です。
テストステップをインストール・ビルド・起動テスト の3段階に分けて、
インストールとビルドにキャッシュを導入します。
そうすれば、起動テストだけになり高速になります。
もう1つは、処理の並列化 です。
扱うDocker分を直列ではなく並列処理させると、
足し算ではなく一番遅い処理時間のものが実行時間になります。
また、テスト自体も全て並列で動くように設計すると良いです。
私の場合は、テストケースを全てユニークなCucumberのタグとし、GitHub Actionsのmatrixでタグを全て列挙します。
そうすれば、全てのテストが独立して並列でテストされます。
次に困るのは、 Docker内のテストしかできない点 です。
例えば、ステージング環境E2Eテストの場合だと CDN やロードバランサーといったサービスが使われていることがあります。
特にフロントエンドではCDNの設定に依存する場合があります。
その場合、そのCDN依存なテストケースは Testcontainers では再現できません。
CDNと振る舞いが同じ Docker コンテナを用意してプロキシするようにできなくはないですが、
完全一致しないため、あまりお勧めしません。
Testcontainers でテストできるのは Docker で動かすもののみ となります。
OAuth認証などを使用する場合、外部サービスの認証をする必要があるため、
そのテストを書きたくない場合は、外部通信をインターセプトし成功情報を返す、ということは実現できます。
必ずアプリケーション側にロジック注入してはならず（E2Eのときは処理しないなど）、
外部から振る舞いを調整できるようにすること（プロキシ、サイドカーなど） をお勧めします。
終わりに
何度かステージング環境E2Eテストを経験してきた私としては、
このTestcontainersによる使い捨てテスト環境は 運用が楽で気に入っています。
また知見が貯まれば共有します！
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「テスト」の記事
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi
業務でWebフロントエンドのテストコードを書く際に、どこに何を書くかというのをざっくりと考えをまとめてみます。 前提 Webアプリケーションのプログラムファイルがツリー構造である前提とします。 tree よくあるフィーチャー単位のフォルダ構
2026年06月05日
個人開発のバイブコーディングでテストコードを書かせているが意味がなかった。 期待する機能をプロンプトで指示しプロダクションコードが出来上がるが、同時にテストコードも書かせていた。 そのテストコードは、プロダクションコードをそのままテストコー