最近、Testcontainers を使う機会があり、苦労したことについて備忘録として残しておきます。
以下の記事で書いてある構成に近いものです。
技術スタックなどは関係なく、フロントエンド(Web)に Docker 、バックエンド(API)に Docker Compose を使用します。
バックエンドには、Database も含まれる想定です。
動かす環境は、ローカル環境とCI環境の2つです。
アプリを起動する際、どのポートでサーブするかを決める必要があります。
以下の記事であるとおり、ホスト側で使用できるポートを固定にせずに動的ポートにすると、
ホスト側のポートを気にしなくてすみ、ポートの競合も考えなくてすみます。
ただ、(私の知る限りでは)コンテナ起動後でないと動的に決まったポートがわかりません。(もちろん自前で決める方法はありますが)
そのため、例えばフロントエンドとバックエンドのURLの値を環境変数に相互に設定されていて、ビルドタイムで必要な場合は難しいです。
そこで、そこはもう諦めて固定ポートで対応することとしました。
認証でログインした際に発行されるセッショントークンを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 で以下のようなことで効率化しました。
ただ、キャッシュが効いていると困ることもあるので、
キャッシュ無効の環境変数でも作ればよかったなと思っています...。
Testcontainers を使うことのメリットは、やはり使い捨てできる環境という点です。
特にE2Eテストでよくあるデータ準備という面倒事を、Testcontainers では大胆に変更しても良いのです。
なぜなら使い終わったら、コンテナごと消すからです。
他には、以下のことも実現できるのです。
バックエンドとフロントエンドを一気通貫した検証ができるので、
Docker を使っているアプリには、テストライブラリとして Testcontainers をお勧めします!
-
※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
タグ「テスト」の記事
以下の記事で書いた CSSをテストする方法について、試してみました。 https://zenn.dev/silverbirder/articles/df6752b230f04c ソースコードは、以下に置いています。 https://gith
Web のフロントエンド実装において、次のようなミスによってデザイン崩れを起こしてしまったことはありませんか。 flex-shrink の指定を忘れて、要素が押しつぶされてしまった z-index の指定を間違えて、要素が意図せず前面(また
AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。 単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。 興味があれば、参考として読んでもらえると嬉しい
2026年01月09日