mcpField
T
test-error-states

test-error-states

github.com/reticlehqテスト・品質1.3k242 回インストール今日更新
リポジトリ

test-error-states について

ネットワーク応答のモックと時刻制御で、エラー状態や空状態をテストする Reticle スキルです。障害時の復旧動作、状態の整合性、コンソールエラーを検証できます。

主な機能

  1. 01ネットワーク応答のモック
  2. 02時刻の固定と進行
  3. 03復旧 UI とアプリ状態のアサート
  4. 04未捕捉のコンソールエラー確認
  5. 05モックの解除と時刻のリセット

活用シーン

  1. 01サーバーエラー後の UI 動作のテスト
  2. 02空応答や不正形式の応答状態の検証
  3. 03再試行とタイムアウト動作の確認
  4. 04デバウンスや時間依存 UI のテスト

インストール

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

$npx skills add https://github.com/reticlehq/reticle --skill test-error-states

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

詳細

エラー状態は一度も実行されたことがありません

どのアプリにも、誰も実行したことのない catch ブロックや、誰も目にしたことのない空の状態があります。想像で書かれ、テストされないまま出荷され、調子の悪い日にユーザーが発見します。

Reticle を使えば、実行中のアプリでそうした状態を強制できます。まだセットアップしていませんか？ reticle スキルに従ってください。Reticle をインストールし、init によるアプリのファイル変更前にユーザーへ確認し、1 つのフローが機能することを実証します。

始める前にお読みください：ネットワークモックには操作中のブラウザーか、リースされたブラウザーが必要です

reticle_network_mock は Reticle が所有するブラウザー内のリクエストをインターセプトします。常時稼働の SDK では実行できません。 reticle drive もリースも使わずに接続したタブでは、{ ok: false, reason: "no-cdp-provider" } が返されます。

利用できるのは、リースされた Playwright タブ（reticle_run { tool: "reticle_lease", args: { action: "acquire", url } }）か、リモートデバッグを有効にして起動した Chrome を指定する RETICLE_CDP_URL です。

# macOS — the user runs this once, in their own Chrome
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

RETICLE_CDP_URL=http://localhost:9222 npx @reticlehq/server@latest mcp

リースも操作中のブラウザーもない場合は、その旨を一行で伝え、このスキルのうち時計を使う部分だけでも提案してください。reticle_clock にはどちらも必要ありません。ハッピーパスを操作して正常に通るのを見て、エラー処理も機能すると報告することはできません。

失敗を強制する

reticle_run({ tool: "reticle_network_mock", sessionId, args: {
  mocks: [{ urlContains: "/api/deploys", status: 500 }],
}})

次にフローを操作します。実行する前に、期待する復旧動作を明示してください。

reticle_act_and_wait({ sessionId, ref, action: "click", until: { kind: "allOf", predicates: [
  { kind: "element", query: { testid: "error-banner" } },
  { kind: "console", level: "error", absent: true },
]}})

2 つ目の述語に注目してください。捕捉されない例外をログに記録することでエラーを「処理」する UI は、エラーを処理できていません。完了したら { clear: true } でモックを解除してください。解除しないと、以降のチェックはすべて偽りの状態で実行されます。

壊れていることが多い順に、強制しておく価値がある状態は 500、実際のエラーボディーを伴う 4xx、空の 200（[]、空の状態）、不正な形式のペイロード、そして応答が返らないリクエスト（いつまでも回り続けるスピナー）です。

スリープせずに時間を進める

reticle_run({ tool: "reticle_clock", args: { sessionId, freeze: true } })
reticle_run({ tool: "reticle_clock", args: { sessionId, advanceMs: 5000 } })
reticle_run({ tool: "reticle_clock", args: { sessionId, reset: true } })

自動で消えるトースト、デバウンス検索、ポーリング、セッションタイムアウト、リトライのバックオフ。こうした機能は通常、スリープして確認しますが、それでは時間がかかり、同じくらい不安定です。タイミングのアサーションは実行環境に左右されるため、あなたのノート PC では通っても CI では失敗します。

時間を止め、正確に指定した間隔だけ進め、その結果をアサートします。高速なノート PC でも、負荷の高いランナーでも、同じ結果になります。終了時には必ず reset してください。時計を止めたままにすると、その後に実行されるすべての処理が気づかないうちに壊れます。

アサートする内容

クラッシュしなかったことではなく、復旧できたことを確認します。

  1. エラーがユーザーに表示されること。「ページが真っ白にならなかった」だけではなく、具体的な要素を確認します。
  2. アプリを引き続き使用できること。再試行が機能し、フォームに入力欄が残り、ナビゲーションが停止していないことを確認します。
  3. 状態が正確であること。reticle_look { action: "state" } で、失敗が反映されており、楽観的更新が中途半端に適用されていないことを確認します。画面上ではロールバックされたように見えてもストアには楽観的な値が残っている、というのはここでよく起きる不具合です。ストアの読み取りでしか見つけられません。
  4. コンソールに捕捉されないエラーがないこと。

誠実さ

モックはアプリの世界を変えるため、モック有効時の判定は、そのモック条件下での結果のみを示します。合格を報告する際は、どのモックが有効だったかを伝え、引き渡す前にすべてのモックを解除し、時計をリセットしてください。/api/deploys に 500 を設定したまま監査を終えると、次の人のセッションが壊れ、実際の障害のように見えてしまいます。

機能のリファレンス：curl https://docs.reticle.sh/capabilities.md。その他すべて：curl https://docs.reticle.sh/llms.txt。

コメント

Markdown 対応