Microsoft Entra ID認証と初回テストのクラウド実行
設定が整いました。最後に、認証を済ませてテストをクラウドで実行してみましょう。
Microsoft Entra IDによる認証
Playwright Workspacesの既定かつ推奨の認証方式は、Microsoft Entra IDによる認証です。テストを実行するマシンから、Azure CLIでサインインします。
az login
複数のEntra IDテナントに所属している場合は、ワークスペースが属するテナントへサインインする必要があります。その際は「az login --tenant <テナントID>」のようにテナントを明示してください。設定ファイルで指定した「DefaultAzureCredential」が、このサインイン情報を自動的に利用して認証を行います。
テストコードの確認
今回のテストは、各テストで共通して使うログイン操作をヘルパー関数「login」に切り出したうえで、（1）ログイン後にTODO一覧画面へ遷移すること、（2）TODOの追加と削除ができること、の2本を用意しています。いずれもOSS Playwrightの書き方そのままで、クラウド実行のための特別な記述は必要ありません。
まずは、共通のloginヘルパーと、ログイン後の遷移を確認するテストを見てみましょう。
import { test, expect } from '@playwright/test';
// ログイン操作を共通化するヘルパー
async function login(page) {
await page.goto('/');
await page.getByLabel('ユーザー名').fill('demo');
await page.getByLabel('パスワード').fill('passw0rd');
await page.getByRole('button', { name: 'ログイン' }).click();
}
test('正しい資格情報でログインするとTODO画面が表示される', async ({ page }) => {
await login(page);
// ログイン後にTODO一覧の見出しが表示されることを確認
await expect(page.getByRole('heading', { name: 'TODO一覧' })).toBeVisible();
});
要素の操作に使っている「getByLabel」「getByRole」は、前回紹介したLocator APIです。ラベルやロールといった意味のある属性で要素を指し示すため、画面構造が多少変わっても壊れにくいテストになります。
続いて、TODOの追加と削除を検証するテストです。先ほどのloginヘルパーを再利用し、フォームからの追加（一覧への表示）と、削除ボタンによる消去を順に確認します。
test('TODOを追加・削除できる', async ({ page }) => {
await login(page);
// 追加
await page.getByPlaceholder('やることを入力').fill('記事を執筆する');
await page.getByRole('button', { name: '追加' }).click();
await expect(page.getByText('記事を執筆する')).toBeVisible();
// 削除
await page.getByRole('button', { name: '削除' }).click();
await expect(page.getByText('記事を執筆する')).toHaveCount(0);
});
入力欄は「getByPlaceholder」でプレースホルダー文言を手がかりに取得しています。削除の確認では「toHaveCount(0)」を使い、対象の要素が一覧から完全に消えたことを検証している点がポイントです。
クラウドでのテスト実行
それでは、クラウドのブラウザでテストを実行します。設定ファイルとして、先ほど生成したplaywright.service.config.tsを指定する点がポイントです。
npx playwright test --config=playwright.service.config.ts --workers=20
「--workers」で並列度を指定できます。今回はテストが少数のため効果は限定的ですが、テスト件数が多いほどクラウド並列の恩恵が大きくなります。
なお無料トライアル中は実行分の消費に注意し、まずは少数のテストで動作を確認するとよいでしょう。実行が完了すると、ターミナルに結果が表示されます。
Azureポータルでの結果確認
実行したテストの結果は、Azureポータルのワークスペース画面に集約されます。左側メニューの「ブラウザーセッション」内の「ブラウザーアクティビティログ」の一覧から該当の実行を開くと、テストの成否やブラウザの種類、所要時間などを確認できます。
このように、ローカルで書いたテストをそのままクラウドのブラウザで実行し、その結果をポータルで一元的に確認できました。これがPlaywright Workspacesの基本的な利用の流れです。
まとめ
今回は、AzureポータルでのPlaywright Workspacesリソースの作成から、@azure/playwrightによるプロジェクトの初期化、Microsoft Entra ID認証、そして初回テストのクラウド実行までを、簡易TODOアプリを題材に一通り体験しました。ローカルで書いたOSS Playwrightのテストを、設定ファイルを切り替えるだけでクラウド実行できる手軽さを実感いただけたのではないでしょうか。
次回は、今回動かした1本のテストを起点にブラウザ／OSのマトリクスやモバイルエミュレーションへと対象を広げ、「--workers」による大規模並列実行で実行時間を短縮する方法について紹介する予定です。
