ホーム自己紹介ブログ
NO.347
DATE2026. 05. 14

Testcontainers 導入の苦労話メモ

最近、Testcontainers を使う機会があり、苦労したことについて備忘録として残しておきます。

前提

以下の記事で書いてある構成に近いものです。

Testcontainersで実現する、使い捨て結合テスト環境構築とテスト実施

Zenn

技術スタックなどは関係なく、フロントエンド(Web)に Docker 、バックエンド(API)に Docker Compose を使用します。
バックエンドには、Database も含まれる想定です。
動かす環境は、ローカル環境とCI環境の2つです。

動的ポート

アプリを起動する際、どのポートでサーブするかを決める必要があります。
以下の記事であるとおり、ホスト側で使用できるポートを固定にせずに動的ポートにすると、
ホスト側のポートを気にしなくてすみ、ポートの競合も考えなくてすみます。

  • Testcontainers のベスト プラクティス | Docker - www.docker.com

ただ、(私の知る限りでは)コンテナ起動後でないと動的に決まったポートがわかりません。(もちろん自前で決める方法はありますが)
そのため、例えばフロントエンドとバックエンドのURLの値を環境変数に相互に設定されていて、ビルドタイムで必要な場合は難しいです。
そこで、そこはもう諦めて固定ポートで対応することとしました。

認証とCookie

認証でログインした際に発行されるセッショントークンをDB管理とCookie貼り付けする場合、
擬似的に 認証状態にすることは比較的容易です。
なぜなら、DBのTestcontainerにアクセスしてセッショントークンを保存し、
Playwright 等のブラウザオートメーションに Cookie をセットすれば済むからです。

しかし、テストの流れとして認証クッキーが必要な場面があります。
そうすると、SameSite 属性(Lax)の判定を通すためには、same-site にする必要があります。
scheme(http ≠ https)、domain (api.example.com = app.example.com)を揃えないといけません。
バックエンドとフロントエンドのそれらを揃える必要があり、ライブラリによっては https でないといけなかったりします。
(sslを無効化するオプションをアプリコードに埋めたくない)

となると、自己証明書の発行や API間通信(異なるコンテナ間の通信)用の信頼ストアの設定が必要です。
Testcontainersを操作するテストコード上に証明書を発行して、各アプリへ配って設定するという仕組みが必要です。
また、アプリ自体がhttps対応していない場合は 前段に nginx を置いてhttpsとしてプロキシするなどで対応するのは比較的容易でした。
なぜなら、nginxのdocker containerを使えば済むからです。

暖気

これはTestcontainersという訳ではないのですが、アプリの挙動がたまに怪しくなる場合がありました。
バックエンドにルーティングがあるはずのパスがないなどのログがでたりします。
私の場合は、まだアプリがDocker起動してセットアップ中などでリクエストを処理できない状態に陥っているようでして、
とりあえず アプリへの暖気リクエストを飛ばしてからテストをするように調整しました。

キャッシュ

Docker やら Docker Compose を使っていると、とにかく遅いです。
ビルドと起動をする中で、モジュール関係のインストールも含まれていて、
セットアップだけで5分かかるとかがよくあります。
これは開発効率が悪くて困るため、Testcontainers で以下のようなことで効率化しました。

  • ボリュームを消さない
    • モジュールインストールを飛ばす
    • 起動時にDBをリセットする
  • Dockerイメージも消さない
    • 指定するDockerイメージがあれば使う。
    • なければ、ビルドする。
  • ローカル環境とCI環境を両立する

ただ、キャッシュが効いていると困ることもあるので、
キャッシュ無効の環境変数でも作ればよかったなと思っています...。

終わりに

Testcontainers を使うことのメリットは、やはり使い捨てできる環境という点です。
特にE2Eテストでよくあるデータ準備という面倒事を、Testcontainers では大胆に変更しても良いのです。
なぜなら使い終わったら、コンテナごと消すからです。
他には、以下のことも実現できるのです。

  • システム日付を変えた日付関連のテスト
  • バッチやキュー処理のテスト
  • メールの受信・送信のテスト

バックエンドとフロントエンドを一気通貫した検証ができるので、
Docker を使っているアプリには、テストライブラリとして Testcontainers をお勧めします!

テスト

-

読者になる

|

シェアする

|

silverbirders

silverbirder

Webソフトウェアエンジニア

ブログを応援する

この記事がよかったら、お布施という形で応援してもらえるとうれしいです。

おふせぼたん

※ ログイン不要で投稿できます。

※ 同じブラウザから投稿を削除できます。

0

読み込み中...

前の記事へ

関連する記事

タグ「テスト」の記事

CSSを、Vitestでテストしてみる

以下の記事で書いた CSSをテストする方法について、試してみました。 https://zenn.dev/silverbirder/articles/df6752b230f04c ソースコードは、以下に置いています。 https://gith

2026年02月10日

フロントエンド
テスト
CSS Layout Testing というテスト手法の提案

Web のフロントエンド実装において、次のようなミスによってデザイン崩れを起こしてしまったことはありませんか。 flex-shrink の指定を忘れて、要素が押しつぶされてしまった z-index の指定を間違えて、要素が意図せず前面(また

2026年01月10日

フロントエンド
テスト
単体テストを全通り書くんじゃない!

AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。 単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。 興味があれば、参考として読んでもらえると嬉しい

2026年01月09日

テスト
← ブログ一覧へ