Playwrightで4デバイス同時UI検証を自動化した——「動いているかどうか」を証明する仕組み

# Playwrightで4デバイス同時UI検証を自動化した——「動いているかどうか」を証明する仕組み

「動いてます」と言っても、それはどのデバイスで確認したのか。

開発者はMacやWindowsのブラウザでテストする。でも実際のユーザーはiPhone SEで使っていたり、Galaxy S21で使っていたりする。

DX経営ゲームは研修で使う。参加者が持ち込む端末はバラバラだ。PCで崩れなくてもiPhoneで崩れては意味がない。

この問題を解決するために、Playwrightを使った自動UI検証を組み込んだ。

検証対象デバイス

DEVICES = [
    {"name": "Desktop_1280",  "width": 1280, "height": 800,  "mobile": False},
    {"name": "iPhone_SE_375", "width": 375,  "height": 667,  "mobile": True},
    {"name": "Galaxy_S21_360","width": 360,  "height": 800,  "mobile": True},
    {"name": "iPad_768",      "width": 768,  "height": 1024, "mobile": True},
]

4つのビューポートを設定した。デスクトップ・iPhone SE（最小クラス）・Galaxy S21（Androidスマホ）・iPad。

この4つをカバーすれば、研修参加者の大半のデバイスに対応できる。

テストの核心：テーブルの実幅を測る

UIテストで最も難しいのは「崩れているかどうか」の判定だ。

画面のスクリーンショットを目視確認するアプローチもあるが、自動化が難しい。そこでJavaScriptで直接DOMの幅を測定することにした。

comp_w = await page.evaluate("""() => {
    const t = document.getElementById('comp-table');
    if (!t) return null;
    const scroll = t.parentElement;
    return {
        tableScrollWidth: t.scrollWidth,
        containerClientWidth: scroll ? scroll.clientWidth : null,
        overflowing: scroll ? t.scrollWidth > scroll.clientWidth : null
    };
}""")

scrollWidthはコンテンツの実際の幅、clientWidthはコンテナの表示幅。scrollWidth > clientWidthなら横スクロールが発生している——つまり崩れている。

これでPASSかFAILかを自動判定できる。

実際に見つかったバグ

この検証スクリプトを書いたことで、2つのことが明確になった。

comp-tableは修正前、iPhoneで527pxまで展開されていた

[iPhone_SE_375] comp-table: tableW=527, containerW=319, overflow=True ❌

テーブルが画面より208px広い。右端が大きくはみ出している。

修正後も残る問題：会社名列の展開

テーブルのmin-widthを320pxに下げてもまだ崩れた。原因を追うと、会社名列にwhite-space:nowrapが設定されており、長い会社名が列を展開していた。

/* 追加したCSS */
@media (max-width: 400px) {
  #comp-table td:first-child { 
    max-width: 80px !important; 
    overflow: hidden !important; 
    text-overflow: ellipsis !important; 
  }
}

会社名を80pxで切り捨て、はみ出た部分は「…」で表示する。

この修正後：

[iPhone_SE_375] comp-table: tableW=319, containerW=319, overflow=False ✅
[Galaxy_S21_360] comp-table: tableW=304, containerW=304, overflow=False ✅

完全に収まった。

44項目の自動テスト

最終的なUIテストは44項目になった。

検証完了  PASS=44  FAIL=0  総計=44
✅ 全44項目 PASS

4デバイス×複数チェック項目の組み合わせだ。主なチェック内容：

comp-table 横スクロール内に収まるか
home-trend-table 横スクロール内に収まるか
AI相談タブが存在するか
アイコンの404がないか
DX変革ゲージ要素が存在するか

Playwrightを使った理由

SeleniumでもCypressでも良かったが、Playwrightを選んだ理由は2つある。

async/awaitで書ける：非同期処理が直感的で、ページのロード待ちや要素の表示待ちが書きやすい。

ブラウザを複数持てる：chromium、firefox、webkit（Safari相当）を同一テストで実行できる。

実際のテストはChromiumのみで動かしているが、必要に応じてFirefox/Safariの確認も簡単に追加できる。

「動いている」の定義を変えた

このテストを書く前の「動いている」は、開発者が手元で確認した状態だった。

テストを書いた後の「動いている」は、4デバイス×44項目を全てPASSした状態だ。

基準が変わると、品質が変わる。研修で使うシステムは、参加者がどんな端末を持ってきても崩れてはいけない。その基準をコードで表現したのがこのテストだ。

デプロイの前にこのテストを実行する習慣がつくと、「本番で崩れていた」という後悔が減る。