mcpField
W
web-testing

web-testing

github.com/onsager-aiテスト・品質761 回インストール2 週間前に更新
リポジトリ

web-testing について

web-testingは、回帰テストを置き換えるのではなく、実ブラウザーでダッシュボードのUI変更を探索的に検証するスキルです。差分に関係するルートをデスクトップとモバイルで確認し、スクリーンショットと構造化された判定を残します。

主な機能

  1. 01コード変更を対象ルートに対応付け
  2. 02デスクトップとモバイルの表示をテスト
  3. 03操作を行い結果を検証
  4. 04証拠としてスクリーンショットを撮影
  5. 05発見事項を再現可能なテストに反映
  6. 06エンドツーエンドテスト失敗の分類

活用シーン

  1. 01プルリクエストのダッシュボード変更を検証
  2. 02レスポンシブレイアウトの回帰を確認
  3. 03エンドツーエンドテストの失敗を調査
  4. 04発見した問題を継続的なテストに追加

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/onsager-ai/dev-skills --skill web-testing

インストール後、Claude Code で/web-testingを入力して読み込まれたか確認します。

詳細

Web Testing Protocol（L2）

ダッシュボード UI の変更を探索的に、AI 主導で検証します。回帰テストではありません。 回帰テストは L1 の担当です（ダッシュボードのテストディレクトリにあるスモークテストと E2E テスト）。L2 では、L1 が見逃す問題を検出します。レイアウトの不具合、モバイルでのリグレッション、実際のブラウザーでのみ失敗するインタラクションフローなどです。

別のリポジトリで採用する場合： 手順（差分を読む → ルートに対応付ける → 2 つのビューポートで agent-browser を実行する → スクリーンショットを撮る → 判定する）は、リポジトリに依存しません。以下のルート表、テストパス、判定スキーマは、onsager-ai/onsager の例です。スキルをフォークし、ご自身のダッシュボードに合わせて具体的な箇所を置き換えてください。

実行するタイミング

  • PR が apps/dashboard/** に変更を加えている場合
  • L1 E2E が失敗し、それが実際のリグレッションなのか、不安定なテストなのか、環境の問題なのかを確認する必要がある場合
  • 誰かが「UI を検証して」または「この変更を実地で試して」と言った場合

テスト対象のアプリ

CI パイプラインは crates/stiglab/deploy/Dockerfile をビルドします。この単一のイメージには、Rust バックエンド（stiglab と synodic）およびビルド済みのダッシュボード SPA がバンドルされています。http://localhost:3000 でリッスンします。

主なルート：

ルートページ見出し
/ファクトリーの概要Factory
/sessionsセッション一覧Sessions
/sessions/:idセッション詳細—（動的）
/nodesノード一覧Nodes
/artifactsアーティファクト一覧Artifacts
/spineイベントスパインビューアー—（動的）
/governanceガバナンスGovernance
/settings設定と認証情報Settings

ビューポート（必ず両方でテスト）

  • デスクトップ：agent-browser set viewport 1280 720
  • モバイル： agent-browser set viewport 375 812

モバイルでの確認は重要です。ダッシュボードはレスポンシブレイアウトを採用しています（全体にわたる md: ブレークポイントを参照）。横方向のオーバーフローとナビゲーションの非表示は、最も多い 2 種類のリグレッションです。

手順

  1. 差分を読む（git diff $DIFF_RANGE）— CI から環境変数として DIFF_RANGE が渡されます。
  2. 変更をルートに対応付けます。 src/pages/SessionsPage.tsx の変更 ⇒ /sessions。src/components/layout/** の変更 ⇒ すべてのルート。
  3. 影響を受ける各ルートについて、各ビューポートで次を行います。
    • agent-browser open http://localhost:3000<route>
    • ページのスナップショットを取得し、見出しと主要な要素が表示されることを確認します。
    • インタラクティブな要素を実際に操作します。マークアップを確認するだけでは不十分です。
      • ボタンをクリックし、フォームを送信し、ダイアログを開きます。
      • 結果を確認します — UI の状態は変わったか、ダイアログは閉じたか、新しいデータは表示されたかを確認します。マークアップが存在するだけでは、正常に動作している証拠になりません。
    • レイアウトの不具合を確認します。特にモバイルでは、横スクロールが発生したら不合格です。ナビゲーションがコンテンツを覆っている場合も不合格です。
    • agent-browser screenshot --screenshot-dir /tmp/l2-screenshots を実行し、出力ファイルの名前を {route-slug}-{desktop|mobile}.png に変更します。
  4. 調査結果をテストとして定着させます。 新しい動作を検証したときや、修正方法を説明できる不具合を見つけたときは、apps/dashboard/tests/smoke/（コンポーネントレベル）または apps/dashboard/tests/e2e/（ブラウザーレベル）に決定論的な L1 テストを作成します。こうして L2 での発見を、恒久的な L1 のテスト範囲に反映できます。
  5. 判定を出します。 tests/l2-verdict-schema.json に一致する JSON を返します。
    • 影響を受けるすべてのルートが、両方のビューポートで合格した場合は PASS。
    • いずれかのルートが失敗した場合は FAIL。該当する問題を viewports[].issues[] に記載します。

トリアージモード

L1 E2E の失敗後に実行された場合は、作業内容が異なります。

  1. apps/dashboard/tests/e2e/ にある失敗したテストファイルを読みます。
  2. agent-browser を使って http://localhost:3000 で再現します。
  3. 失敗ごとに、regression（実際の不具合）、flaky（断続的な失敗／タイミングの問題）、environment（テストハーネスまたは CI の問題）に分類します。
  4. 根本原因と修正案を含む、tests/l2-triage-schema.json に一致する JSON を返します。

ガードレール

  • 差分の範囲に絞ります。1 行の変更でアプリ全体を再テストしないでください。
  • スクリーンショットは必須の証拠です。スクリーンショットがなければ、ビューポートを実行していません。
  • ルートを勝手に作らないでください。差分で新しいルートが追加された場合はそれを使い、そうでなければ上記の表に従ってください。
  • コストを抑えてください。ビューポートごとにブラウザーセッションは 1 つで十分です。

コメント

Markdown 対応