はじめに
前回はMicrosoft Playwright Workspacesの概要として、E2Eテストの課題、OSS Playwrightとの関係、親サービスであるAzure App Testingの位置づけ、料金体系などについて紹介しました。
今回からは実際にアプリケーションとテストの実装を行っていきます。Azureポータル上でPlaywright Workspacesのリソースを作成し、ローカルで用意した簡易TODOアプリに対するE2Eテストを「クラウド上のブラウザ」で実行して、その成功をAzureポータルで確認するところまでを説明していきます。
検証環境と前提
本回のハンズオンは、次の環境を前提とします。お手元の環境を事前に整えておいてください。
- 有効なサブスクリプションを持つAzureアカウント
- Node.js（LTS版。執筆時点では20.x以降を推奨）
- Azure CLI（バージョン2.2.0以降。「az --version」で確認できます）
Playwright Workspacesは、テストの「制御」自体は手元のマシンで実行し、ブラウザの起動だけをクラウドへオフロードする構造でした。そのため、ローカルにNode.jsとPlaywrightの実行環境が必要になります。Azure CLIは、後述するMicrosoft Entra ID認証でクラウドへサインインするために使用します。
題材となる簡易TODOアプリ
本連載では、全4回を通じて同じ簡易TODOアプリをテスト対象として使い回します。まずはその構成を確認しておきましょう。アプリはNode.js／Expressで実装したサーバーと、静的なHTML／JavaScriptのフロントエンドから成る、ごく小さなものです。
アプリの機能と画面
TODOアプリが提供する画面は次の3つです。いずれもE2Eテストの題材として典型的な操作を含んでいます。
- ログイン画面（ユーザー名とパスワードを入力して認証）
- TODO一覧画面（登録済みのやることを一覧表示）
- 追加・削除の操作（フォームから追加、ボタンで削除）
ログインフォームの操作、入力した値の送信、一覧への反映、要素の削除といった一連の流れは、実際のWebアプリでも頻出するパターンです。これらをE2Eテストで検証できれば、本サービスの基本的な使い方は十分に身についたと言えるでしょう。
ファイル構成
サンプルアプリは「programs/todo-app/」配下に配置しています。主なファイル構成は次の通りです。
- server.js：Expressによるサーバー（APIと静的ファイルの配信）
- public/：フロントエンド（index.html、app.js、style.css）
- playwright.config.ts：OSS Playwright用の基本設定
- playwright.service.config.ts：クラウド実行用の設定（後の手順で生成）
- tests/todo.spec.ts：E2Eテストの本体
サーバーは、TODOデータをインメモリで保持するだけのシンプルな実装です。ログイン認証も学習用の固定アカウント（demo／passw0rd）で行います。サーバーの要点を抜粋すると次のようになります。
// ログイン認証。成功時のみ200を返します
app.post('/api/login', (req, res) => {
const { username, password } = req.body ?? {};
if (username === DEMO_USER.username && password === DEMO_USER.password) {
return res.json({ ok: true });
}
res.status(401).json({ ok: false });
});
// TODOの追加
app.post('/api/todos', (req, res) => {
const text = (req.body?.text ?? '').trim();
const todo = { id: nextId++, text };
todos.push(todo);
res.status(201).json(todo);
});
アプリを起動するには、todo-appフォルダで依存パッケージをインストールしてからサーバーを起動します。
npm install node server.js
ブラウザで「http://localhost:3000」にアクセスし、ログイン後にTODOの追加・削除ができれば準備は完了です。
