PlaywrightでCMS管理画面を検証する
チーフリライアビリティエンジニア 黒澤私が携わっている案件の中には、CMS管理画面の検証作業を部分的に自動化しているものがあります。具体的には、記事の作成や公開が正しく行えるかどうかといった検証を、Playwrightを用いて自動化しています。
この記事では、自動化を取り入れた背景およびフロントエンドに関係するTipsを紹介します。
検証自動化の背景
CMS管理画面の検証に自動化を取り入れたのは、自動化に向いていると考えたためです。具体的には、次のような特徴があると感じたためでした。
- 検証すべき操作の種類は多くない
- コンテンツや編集者の種類によって検証パターンが増える
CMS管理画面にはログイン、記事の作成・編集、画像などのアップロード、プレビュー、承認（ある場合）、公開、取り下げといった典型的な操作があり、それ以外の操作はほとんど存在しません。
他方、同じ操作であっても、コンテンツや編集者の違いによって検証パターンが増えることはよくあります。お知らせページと製品・サービス詳細ページでは、掲載すべき情報（管理画面の入力項目）が異なることもありますし、広報担当と事業担当では、利用できる機能が異なることもあります。
結果として、同じような操作を異なる設定で何度も検証することが多くあります。一度だけ検証するのであれば手作業でよいのですが、実際には運用中に何度も検証が発生します。CMSの目的上、広報担当がページを編集できていれば、事業担当はページを編集できなくなってもよいといったことは受け入れられないため、検証範囲をむやみに狭めることも難しいと考えています。
このような繰り返しの多い検証は自動化に向いており、実際に一部の案件において自動化を進めています。自動化には一定のコストがかかりますが、検証頻度（≒改修頻度）によっては手作業を繰り返すよりもトータルでのコストを抑えられます。
自動化のTips
CMS管理画面の検証は基本的に次の流れで行っています。
- リンクやボタンなどをクリックして操作を行う画面・状態まで遷移
- テキスト入力欄やメニューを操作して検証用データを入力
- 表示された結果が期待した内容と一致するかを確認
これらの操作をPlaywrightのPython版（同期API）で自動化しています。
自動化を進めていくなかでは入力で問題が起きることは多くなく、
- ボタンやリンクなどをクリック後、結果が表示される前に検証しようとして失敗する
- ボタンやリンクなどが検証可能な状態になる前にクリックして検証に失敗する
問題が起きました。この記事の残りでは、これらの問題への対応Tipsを紹介します。
要素が表示されるまで待機
結果が表示される前に検証しようとして失敗する問題への対応は、基本的に結果が表示されるまで待機することです。
Playwrightでは、多くの処理で対象の要素が表示されるまで自動的に待機する機能（Auto-waiting）がありますが、手動での待機が必要になるケースもあります。
ある要素が表示されるまで待機するにはwait_for()やto_be_visibleアサーションなどが利用できます。
button = page.get_by_role("button", name="ボタン", exact=True)
result = page.get_by_role("group", name="結果", exact=True)
# ボタンをクリック
button.click()
# resultが表示されるまで待機
result.wait_for()
# 検証処理要素が削除されるまで待機
Playwrightは要素が表示されるまでは自動待機しますが、非表示や削除の待機は手動で指定します。
ある要素がDOMツリーから削除されるまで待機するにはwait_for()にdetachedを指定したり、not_to_be_attachedアサーションを用いたりできます。
button = page.get_by_role("button", name="ボタン", exact=True)
# ボタンをクリック
button.click()
# ボタンがDOMツリーから削除されるまで待機
button.wait_for(state="detached")
# 検証処理ボタンを押下すると処理が行われ、処理が完了するとボタンが削除されるような機能の検証で利用できます。
属性が変わるまで待機
ボタンをクリックすると通常は確認なしに処理が実行されるものの、特定のJavaScriptが実行されると確認ダイアログを表示する機能の検証は次のように行いました。
- 対象のJavaScriptを調整し、ダイアログを表示する場合はボタンにaria-haspopup属性を指定
- Playwrightではaria-haspopup属性の指定を待ってから検証
ある要素の属性が特定の値に変わるまで待機するにはto_have_attributeアサーションが利用できます。
button = page.get_by_role("button", name="ボタン", exact=True)
# ボタンをクリック
button.click()
# ボタンのaria-haspopup属性がdialogになるまで待機
expect(button).to_have_attribute("aria-haspopup", "dialog")
# 検証処理他にも、ビジー状態をaria-busy属性で判断できる場合は、Playwrightでaria-busy属性の変更を待機することもできるでしょう。
button = page.get_by_role("button", name="ボタン", exact=True)
# ボタンをクリック
button.click()
# ボタンのaria-busy属性がfalseになるまで待機
expect(button).to_have_attribute("aria-busy", "false")
# 検証処理読み込み中を表す文言が消えるまで待機
ボタンを押すとデータの読み込みが始まり、複数あるデータ表示領域に「Processing...」という文言が表示され、読み込みが完了すると本来のデータが表示される機能の検証では、文言が表示されなくなるまで待機する処理を入れました。これはnot_to_contain_textアサーションを利用しています。
button = page.get_by_role("button", name="ボタン", exact=True)
result = page.get_by_role("group", name="結果", exact=True)
# ボタンをクリック
button.click()
# 結果に「Processing...」が含まれなくなるまで待機
expect(result).not_to_contain_text("Processing...")
# 検証処理この方法は、文言が「Processing...」から「読み込み中...」などに変わると待機に失敗するため、実際には「Processing...」が表示されることも待機しています。
button = page.get_by_role("button", name="ボタン", exact=True)
result = page.get_by_role("group", name="結果", exact=True)
# ボタンをクリック
button.click()
# 結果に「Processing...」が含まれるまで待機
expect(result).to_contain_text("Processing...")
# 結果に「Processing...」が含まれなくなるまで待機
expect(result).not_to_contain_text("Processing...")
# 検証処理まとめ
CMS管理画面の検証は、繰り返しが多く自動化に向いていると考えており、一部の案件では実際に自動化を取り入れています。
また、自動化するなかで生じた問題の多くは、フロントエンドの知識で解決できました。
この記事が検証自動化の参考になれば幸いです。