mcpField
E
expect

expect

github.com/millioncoテスト・品質3.6k1.9k 回インストール29 週間前に更新
リポジトリ

expect について

Expect は、完了を報告する前に実際のブラウザーでコード変更を検証するスキルです。expect MCP ツールでの操作、セッションの再利用、操作の一括実行、失敗修正後の再検証を重視します。

主な機能

  1. 01完了報告前のブラウザー検証
  2. 02expect MCP ツールでのブラウザー操作
  3. 03既存ブラウザーセッションの再利用
  4. 04操作と結果収集の一括実行
  5. 05失敗修正後の再テスト

活用シーン

  1. 01複数段階のフォームとエラー状態の検証
  2. 02コード変更後に既存セッションを確認
  3. 03コード編集と並行してブラウザーチェックを実行

MCP 対応

`open`、`playwright`、`screenshot` などの expect MCP ツールをブラウザー操作に使用します。明示的に求められない限り、通常のブラウザーツールは使わないよう指示しています。

インストール

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

$npx skills add https://github.com/millionco/expect --skill expect

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

詳細

Expect

コード変更が動作すると主張する前に、実際のブラウザで検証します。ブラウザでの証拠がなければ、完了の主張はできません。

すべてのブラウザ操作には expect MCP ツール(open、playwright、screenshot など)を使用してください。ユーザーが明示的に要求しない限り、生のブラウザツール(Playwright MCP、chrome ツールなど)を使用しないでください。

サブエージェントの使用

ブラウザ検証はサブエージェント(Task ツール)またはバックグラウンドシェルで実行するのが最適です。そうすればメインスレッドがコード編集のために空きます。これにより会話の応答性が保たれ、ブラウザテストを並行して実行しながらコードを修正できます。ブラウザ作業にはサブエージェントを起動することを強く推奨します。特にテストが複数のステップや長いインタラクションを含む場合はなおさらです。テストが本当に些細なもの(単一のスクリーンショット確認)であれば、インラインでも許容されます。

ブラウザ状態の再開

新しいブラウザを開く前に、すでに起動しているかどうかを確認してください。browser_tabs(action list)または expect の screenshot ツールを使用して、セッションがまだアクティブかどうかを確認します。対象の URL でタブがすでに開いている場合は、それを再利用してください — 閉じて開き直さないでください。コード修正後の再検証では、最初からやり直すよりも、既存のセッションをナビゲートまたはリフレッシュすることを優先してください。

複合化

playwright ツールは、ref() を使ってスナップショットの ref を Locator に解決する code 文字列を受け取ります。1 回の呼び出しでインタラクション全体を実行できます — 入力、クリック、そしてデータ収集まで。これを使ってください。

BAD — 5 回のツール呼び出し:

screenshot (snapshot)
playwright: await ref('e3').fill('Jane')
screenshot (snapshot)                        ← WHY? page didn't change
playwright: await ref('e5').fill('[email protected]')
playwright: await ref('e7').click()

GOOD — 2 回のツール呼び出し:

screenshot (snapshot)
playwright (snapshotAfter=true):
  await ref('e3').fill('Jane');
  await ref('e5').fill('[email protected]');
  await ref('e7').click();
  return { title: await page.title(), url: page.url(), errors: (await page.$$('.error')).length };

データを収集するには return を使用します。レスポンス: { result: <value>, resultFile: "<tmp path>", snapshot: { tree, refs, stats } }。resultFile は close まで保持されます — 後で読み取るか grep してください。戻り値がない場合は "OK" を返します(snapshotAfter=true の場合はスナップショットのみ)。

再スナップショットは DOM の境界をまたぐ場合のみ行ってください。 入力やホバーはページ構造を変更しません — 同じ ref を使い続けてください。ナビゲーション、送信、ダイアログの開閉は構造を変更します — snapshotAfter=true を設定してください。

指示の書き方

悪い例: "Check that the login form renders on http://localhost:5173" 良い例: "Submit the login form empty, with invalid email, with wrong password, and with valid credentials. Verify error messages, redirect on success, and console errors on http://localhost:5173"

完了を主張する前に

  1. 敵対的な指示でブラウザ検証を行います。
  2. 出力全体を読みます — 失敗、アクセシビリティ、パフォーマンスを確認します。
  3. いずれかの失敗がある場合: コードを修正し、すぐに再検証します。尋ねることも待つこともなく。
  4. 失敗が 0 になるまで繰り返し、その後、合格した証拠とともに主張を述べます。

正当化

  • 「ブラウザテストをインラインで実行するよ、すぐ終わるから」 — おそらく違います。サブエージェントを起動すれば、並行してコードを編集し続けられます。サブエージェントを省略するのは、単一のスクリーンショットの健全性チェックの場合だけにしてください。
  • 「再テストのために新しいブラウザを開くよ」 — まず既存のセッションを確認してください。タブがまだ開いている場合は、リフレッシュまたはナビゲートしてください — コールドスタートで時間を無駄にしないでください。
  • 「アクションごとに 1 回の playwright 呼び出しを行うよ」 — 違います。シーケンス全体を 1 回の呼び出しで行ってください。
  • 「入力の間にスナップショットが必要だ」 — 違います。入力は DOM を変更しません。まとめてください。
  • 「何が変わったか見るためにスナップショットを取ろう」 — ページはナビゲートまたは送信しましたか? いいえ? それを実行するアクションで snapshotAfter=true を使用してください。

コメント