Testcontainersで開発PR単位にE2Eテストなど
Testcontainers + Playwright + Cucumber.js による受け入れテストを、公私ともに活用しています。
運用していて気づいた点について、また書き残そうと思います。
開発PR単位でE2Eテスト
これはTestcontainers 導入初期から設定しているもので、
GitHub Actions などのCI経由で E2Eテストを動かせます。
依存関係アップデートツール によるPRや開発PRの単位で E2Eテストを回せるのは、
かなり早い段階で不具合を発見できるため良いです。
さまざまな機能
Playwright を使えば、カメラで何かをスキャンする といった操作も GitHub Actions 経由でもテストできました。
外部デバイスってどうなんだろうなと思ってたのですが、できてびっくりです。
ブラウザの時間やDockerのシステム時刻を変更すれば、タイムトラベルできました。
メールやバッチ処理もキックできるため、送信されたメール件数や内容も確認できます。
Playwright で使用するレンダリングエンジン Chromium、WebKit、Firefox を選べるため、
クロスブラウザテスト もできます。
ビューポートも変えることができるため、スマホ、タブレット、ラップトップ、デスクトップと クロスデバイステスト もできます。
さまざまな非機能
さまざまな非機能テストも PR単位で短時間で検証できます。
パフォーマンステスト が実現できます。
ブラウザの描画パフォーマンスとして、どれぐらい遅いのかテストすることができます。
負荷テスト も実現できます。
vegeta や k6 を Dockerfile として使用して、対象箇所（API、ブラウザ）に負荷をかけるテストもできます。
本番環境と同等のマシンスペックは GitHub Actions では用意するとお金がかかるので、
スケールダウンして検証するとよいです。
カオステスト も実現できます。
Docker の一部の箇所を高負荷にして処理不能に追い込んだ際の挙動を確認する、というのもできます。
AIモンキーテスト
AI の力を借りれば、モンキーテスト もできます。
画面を操作するための Page Object Model があれば、操作可能です。
DBに投入するシードデータも Testcontainers 内で自由に制御できるため、必要なものは整えれます。
それらの情報をもとに、Claude や Codex 等の AI にデータを渡して自由に Cucumber.js のシナリオを作成させます。
そのシナリオを実行させてどうなるか、というモンキーテストも実現できました。
単体テストを処分
特に個人開発においては、単体テストは処分しました。
AI によって、E2Eテスト作成は圧倒的に早くなりました。
AI量産写経単体テストは、プロダクションコードを正として書かれるため、プロダクションコードがバグっていても気づけませんでした。
Testcontainers E2Eテストの場合は、必ず 動画ファイル をつけるようにしているので、
テストが成功した場合の動画を見て判断しています。
もちろん、意図しない無理やりE2Eテストもできなくはないので、レビューは欠かせません。
終わりに
こんなにも幅広い柔軟性の高い設計ができるなんて、少し自慢したくなり本記事を書きました。（笑）
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「テスト」の記事
テストコードをテストする、ミューテーションテスト。 プロダクションコードを突然変異でコードを書き換えたら（ミューテーション）、テストが失敗してくれるかどうか。 失敗するということは、不具合を検知できたということです。 ミューテーションする箇
2026年08月25日
お仕事先のWebアプリケーションに、Testcontainersを導入運用して数ヶ月経過しました。 良い点と困る点について、書き残しておきます。 前提 簡単な前提として、バックエンドDB・APIとフロントエンドの3層構成のよくあるWebアプ
2026年07月08日
以下で書いた通り、プロダクトコードを写経したテストコードを削除しました。 "こぶりー" ( https://kobliy.vercel.app/ ) という個人ブログを読むアプリのコードです。 https://silverbirder.gi