今、個人開発で Fequest という「ユーザー画面」と「管理画面」の 2 つの Web アプリを実装しています。
この 2 つを跨いだ E2E テストを、Testcontainers と Cucumber(Gherkin Markdown)、そして Playwright を組み合わせて書いています。
今回、管理画面でデータを登録し、その内容がユーザー画面で正しく表示される という一連の E2E テストが GitHub Actions 上で動作するようになったので、その方法をまとめておきます。
Fequest(feature request) は、ユーザーが新機能や改善要望を投稿できるサービスです。
ユーザーと開発者が、「つくってほしいもの」「つくる予定のもの」を相互に伝え合える場を作るのが目的です。
Fequest の構成は以下のとおりです。
Testcontainers は Docker 上で動作できることが必須なので、それ以外はなんでも構いません。
実際に行う処理は次のような流れです。
この一連の流れは ローカルだけで完結 します。
GitHub Actions 上でも完全に同じ構成で動作します。
ステージング環境が不要になるのが大きなメリットです。
ソースコードはすべて公開しています。
以下は、その中から抜粋したサンプルです。
管理画面ログイン済み状態を作るため、DB にユーザーとセッションを直接挿入します。
const userId = `e2e-user-${randomUUID()}`;
await db.insert(users).values(buildUserRecord(userId));
const sessionToken = `e2e-session-${randomUUID()}`;
await db.insert(sessions).values({
expires: new Date(Date.now() + 1000 * 60 * 60),
sessionToken,
userId,
});Playwright のブラウザコンテキストに Cookie を追加し、管理画面にアクセスした瞬間からログイン済み状態にします。
await adminBrowser.context.addCookies([
{
domain: new URL(adminBaseUrl).hostname,
httpOnly: true,
name: "authjs.session-token",
path: "/",
sameSite: "Lax",
secure: false,
value: sessionToken,
},
]);adminBrowser で管理画面にアクセス管理画面とユーザー画面が 同じ DB を参照している ため、
管理側で登録した内容がユーザー側ですぐ反映されます。
UI ベースで「実運用に近い E2E テスト」を構築できるのが非常に快適です。
以上、Testcontainers 芸人でした。
Testcontainers については、以下の記事も参考にしてください。
タグ「テスト」の記事
Web のフロントエンド実装において、次のようなミスによってデザイン崩れを起こしてしまったことはありませんか。 flex-shrink の指定を忘れて、要素が押しつぶされてしまった z-index の指定を間違えて、要素が意図せず前面(また
AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。 単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。 興味があれば、参考として読んでもらえると嬉しい
2026-01-09
はじめに Playwright で E2E テストを書く際、playwright codegen や、近年では Playwright MCP を利用して、テストコードの雛形を作成することが多いと思います。 ただし、生成したテストコードが正し
2025-12-26