環境とデバッグ
テスト
OpenClaw には3つの Vitest スイート(ユニット/統合、e2e、ライブ)と、いくつかの Docker ランナーがあります。このドキュメントは「私たちのテスト方法」ガイドです:
- 各スイートがカバーする範囲(および意図的にカバーしない範囲)
- 一般的なワークフロー(ローカル、プッシュ前、デバッグ)で実行するコマンド
- ライブテストが認証情報を発見し、モデル/プロバイダーを選択する方法
- 実世界のモデル/プロバイダー問題に対する回帰テストの追加方法
クイックスタート
ほとんどの日:
- 完全ゲート(プッシュ前に期待される):
pnpm build && pnpm check && pnpm test
テストに触れる場合や追加の確信が必要な場合:
- カバレッジゲート:
pnpm test:coverage - E2E スイート:
pnpm test:e2e
実際のプロバイダー/モデルのデバッグ(実際の認証情報が必要):
- ライブスイート(モデル + ゲートウェイ ツール/イメージプローブ):
pnpm test:live
ヒント:1つの失敗ケースのみが必要な場合は、以下で説明する許可リスト環境変数を使用してライブテストを絞り込むことを推奨します。
テストスイート(どこで何が実行されるか)
スイートは「現実性の増加」(および不安定性/コストの増加)として考えてください:
ユニット / 統合(デフォルト)
- コマンド:
pnpm test - 設定:
scripts/test-parallel.mjs(vitest.unit.config.ts,vitest.extensions.config.ts,vitest.gateway.config.tsを実行) - ファイル:
src/**/*.test.ts,extensions/**/*.test.ts - 範囲:
- 純粋なユニットテスト
- プロセス内統合テスト(ゲートウェイ認証、ルーティング、ツーリング、パース、設定)
- 既知のバグに対する決定論的回帰テスト
- 期待:
- CI で実行される
- 実際のキーは不要
- 高速で安定しているべき
- プールに関する注意:
- OpenClaw は Node 22/23 でより高速なユニットシャードのために Vitest
vmForksを使用します。 - Node 24+ では、OpenClaw は Node VM リンクエラー (
ERR_VM_MODULE_LINK_FAILURE/module is already linked) を避けるために自動的に通常のforksにフォールバックします。 OPENCLAW_TEST_VM_FORKS=0(強制的にforks) またはOPENCLAW_TEST_VM_FORKS=1(強制的にvmForks) で手動で上書きできます。
- OpenClaw は Node 22/23 でより高速なユニットシャードのために Vitest
E2E(ゲートウェイ スモーク)
- コマンド:
pnpm test:e2e - 設定:
vitest.e2e.config.ts - ファイル:
src/**/*.e2e.test.ts - ランタイムデフォルト:
- より高速なファイル起動のために Vitest
vmForksを使用。 - 適応型ワーカーを使用 (CI: 2-4, ローカル: 4-8)。
- デフォルトでサイレントモードで実行し、コンソール I/O オーバーヘッドを削減。
- より高速なファイル起動のために Vitest
- 便利な上書き:
OPENCLAW_E2E_WORKERS=でワーカー数を強制 (最大16)。OPENCLAW_E2E_VERBOSE=1で詳細なコンソール出力を再有効化。
- 範囲:
- マルチインスタンスゲートウェイのエンドツーエンド動作
- WebSocket/HTTP サーフェス、ノードペアリング、より重いネットワーキング
- 期待:
- CI で実行される(パイプラインで有効な場合)
- 実際のキーは不要
- ユニットテストよりも多くの可動部品(より遅くなる可能性あり)
ライブ(実際のプロバイダー + 実際のモデル)
- コマンド:
pnpm test:live - 設定:
vitest.live.config.ts - ファイル:
src/**/*.live.test.ts - デフォルト:有効 (
pnpm test:liveによってOPENCLAW_LIVE_TEST=1が設定される) - 範囲:
- 「このプロバイダー/モデルは実際の認証情報で今日実際に動作するか?」
- プロバイダーフォーマットの変更、ツール呼び出しの癖、認証問題、レ ート制限動作の検出
- 期待:
- 設計上 CI 安定ではない(実際のネットワーク、実際のプロバイダーポリシー、クォータ、障害)
- コストがかかる / レート制限を使用する
- 「すべて」ではなく絞り込んだサブセットの実行を推奨
- ライブ実行は不足している API キーを取得するために
~/.profileをソースする
- API キーローテーション(プロバイダー固有):カンマ/セミコロン形式の
*_API_KEYSまたは*_API_KEY_1,*_API_KEY_2を設定(例:OPENAI_API_KEYS,ANTHROPIC_API_KEYS,GEMINI_API_KEYS)またはOPENCLAW_LIVE_*_KEYによるライブ単位の上書き;テストはレート制限応答でリトライします。
どのスイートを実行すべきですか?
この決定表を使用してください:
- ロジック/テストの編集:
pnpm testを実行(多く変更した場合はpnpm test:coverageも) - ゲートウェイ ネットワーキング / WS プロトコル / ペアリングに触れる:
pnpm test:e2eを追加 - 「ボットがダウンしている」/ プロバイダー固有の失敗 / ツール呼び出しのデバッグ:絞り込んだ
pnpm test:liveを実行
ライブ: Android ノード キャパビリティ スイープ
- テスト:
src/gateway/android-node.capabilities.live.test.ts - スクリプト:
pnpm android:test:integration - 目標:接続された Android ノードによって現在アドバタイズされているすべてのコマンドを呼び出し、コマンド契約の動作をアサート。
- 範囲:
- 前提条件設定/手動セットアップ(スイートはアプリのインストール/実行/ペアリングを行わない)。
- 選択された Android ノードに対するコマンドごとのゲートウェイ
node.invoke検証。
- 必要な事前セットアップ:
- Android アプリがすでにゲートウェイに接続 + ペアリング済み。
- アプリをフォアグラウンドに維持。
- 通過を期待するキャパビリティに対して権限/キャプチャ同意が付与済み。
- オプションのターゲット上書き:
OPENCLAW_ANDROID_NODE_IDまたはOPENCLAW_ANDROID_NODE_NAME。OPENCLAW_ANDROID_GATEWAY_URL/OPENCLAW_ANDROID_GATEWAY_TOKEN/OPENCLAW_ANDROID_GATEWAY_PASSWORD。
- 完全な Android セットアップ詳細:Android アプリ
ライブ: モデル スモーク(プロファイルキー)
ライブテストは、失敗を分離できるように2つのレイヤーに分割されています:
- 「直接モデル」は、プロバイダー/モデルが与えられたキーで少なくとも応答できることを示します。
- 「ゲートウェイ スモーク」は、そのモデルに対して完全なゲートウェイ+エージェントパイプラインが機能することを示します(セッション、履歴、ツール、サンドボックスポリシーなど)。
レイヤー 1: 直接モデル完了(ゲートウェイなし)
- テスト:
src/agents/models.profiles.live.test.ts - 目標:
- 発見されたモデルを列挙
getApiKeyForModelを使用して認証情報を持つモデルを選択- モデルごとに小さな完了を実行(必要に応じて対象を絞った回帰テストも)
- 有効化方法:
pnpm test:live(または Vitest を直接呼び出す場合はOPENCLAW_LIVE_TEST=1)
OPENCLAW_LIVE_MODELS=modern(またはall、modern のエイリアス) を設定して実際にこのスイートを実行;それ以外の場合はpnpm test:liveをゲートウェイ スモークに集中させるためにスキップ- モデル選択方法:
OPENCLAW_LIVE_MODELS=modernでモダン許可リストを実行 (Opus/Sonnet/Haiku 4.5, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.5, Grok 4)OPENCLAW_LIVE_MODELS=allはモダン許可リストのエイリアス- または
OPENCLAW_LIVE_MODELS="openai/gpt-5.2,anthropic/claude-opus-4-6,..."(カンマ許可リスト)
- プロバイダー選択方法:
OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"(カンマ許可リスト)
- キーの取得元:
- デフォルト:プロファイルストアと環境変数のフォールバック
OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1を設定してプロファイルストアのみを強制
- これが存在する理由:
- 「プロバイダー API が壊れている / キーが無効」と「ゲートウェイ エージェントパイプラインが壊れている」を分離
- 小さく分離された回帰テストを含む(例:OpenAI Responses/Codex Responses 推論再生 + ツール呼び出しフロー)