Question 1

e2eモバイルテストで、worker replacementがprovider-leased session上のdevice claimをドロップさせるのはなぜですか？

Accepted Answer

`e2e@0.15.1` / `@e2e-dev/mobile@0.9.0` では、ユニットが失敗するとワーカーが退役し、`AgentDeviceSurface.dispose()` が `sessions.close()` を呼び出して、代替ワーカーがクレームを再オープンする前に agent-device のクレームを解放してしまい、別のセッションがデバイスを奪取できる状態になります。PR #1209 で修正されました：スロットがプロバイダーリースを保持している場合、ワーカーの置き換え時にセッションとそのデバイスクレームがオープン状態に維持されるようになり、`release` または実行終了時のみクローズされます。修正をインストールするには `npm i @e2e-dev/mobile@nightly e2e@nightly` を実行するか、0.15.1 / 0.9.0 以降の次の安定版リリースにアップグレードしてください。

Question 2

設定されているAPIキーに応じて、e2e.config.tsで異なるAIモデルを使用するにはどうすればよいですか？

Accepted Answer

組み込みのフォールバック API は必要ありません。環境変数に対する単純な条件式を `e2e.config.ts` で直接使用してください。

```ts
export default {
  agents: {
    default: {
      model: process.env.ANTHROPIC_API_KEY
        ? anthropic('claude-sonnet-5')
        : gateway('openai/gpt-6-luna-fast'),
    },
  },
} satisfies E2EConfig;
```

これにより、各マシンはコミット済みの設定を編集することなく、ローカルで利用可能なクレデンシャル（例: `ANTHROPIC_API_KEY` 対 `AI_GATEWAY_API_KEY`）に基づいてモデルを選択します。補足: 専用の `firstAvailable` コア API が提案されましたが、メンテナーによって却下されました。モデルをリプレイキャッシュキーに含めると、マシン間でのリプレイが壊れ、設定の読み込み時に失敗するためです。その代わりに、選択されたモデルはキャッシュキーを変更せずに、レコーディングごとに記録されます（issue #1192 を参照）。

Question 3

tester-army の e2e で、モデルビジョンを有効にせず、また誤ったアクションに紐付けられることなく、ステップごとのデバッグスクリーンショットをキャプチャするにはどうすればよいですか？

Accepted Answer

`onStep` から非同期でスクリーンショットを撮らないでください。これはノンブロッキングの進捗フィードであるため、キャプチャが後の画面のものになってしまう可能性があります。代わりに次のようにしてください: 1) `e2e@0.21.2` にアップグレードして `session.report()` を呼び出し、リダクト済みで範囲を制限したステップごとのセマンティック差分を含む、組み込みのステップ画面トレースを取得します。2) `agent.act()` の `onAction` フック(#1219 で追加)を使用します。これは各アクションの後に await されて実行されるため、その中で `app.screenshot()` を呼び出せば、そのアクションに対応したスクリーンショットになることが保証されます: `await agent.act('Open Settings', { onAction: async () => { await app.screenshot(); } })`。3) アーティファクトのスクリーンショットは、シークレットの入力後も保持されるようになりました(#1218)。既存のマスキングおよび secret-taint ルールは引き続き適用されます。これらのいずれもモデルのビジョンを有効にしたり、ピクセルをモデルに送信したりするものではありません。

Question 4

ホステッドe2eセッションから外部デバッグビューアー向けのバージョン付きデバッグレポートをエクスポートする方法

Accepted Answer

`e2e@0.21.2`（PR #1156）で提供された `session.report()` を使用してください。セッションの終了後、ホストされたトレース用に構築されたものと同じスキーマを持つ、セッションの安定した `report-1` ドキュメントが返されます。これには、run/attempt/target の識別情報、最終的な SDK の結果、ステップのタイミング/ステータス/エラー、記録されたイベント、既存のアーティファクト参照が含まれます。これは、成功、SDK 失敗、タイムアウトしたセッションのすべてで利用できるため、コンシューマーは Markdown を解析したり、アーティファクトディレクトリを走査したり、プライベートなランナー内部をインポートしたりすることなく、ドキュメントをシリアライズ/アップロードして独自のビューアーをレンダリングできます。既存のシークレットの墨消しおよび保持ポリシーは引き続き権威のあるものとして有効です（遅延解決されたシークレットの墨消しは issue #1157 で個別に追跡されています）。アーティファクトマニフェストと推論の抜粋を含む、より広範なデバッグバンドルはスコープから外れました。ビューアーが `report-1` に含まれないエビデンスを必要とする場合は、焦点を絞った issue を作成してください。

Question 5

なぜ e2e CLI は、ビデオ録画のクリーンアップが失敗したにもかかわらず、コード 0 で終了してテストがパスしたと報告するのですか？

Accepted Answer

e2e 0.21.2 では、CLI はビデオのクリーンアップ失敗（例: CLEANUP_TIMEOUT 'stopping the video timed out'）を実行の失敗として扱わないため、`--video on` を指定した実行が、テストは合格したにもかかわらずビデオアーティファクトが保持されないまま、終了コード 0 で終了する可能性があります。回避策: (1) 終了コード 0 だけを信用しないこと — CLI をラップして、実行レポートに `cleanup: "failed"` やコード CLEANUP_TIMEOUT を含む `secondaryErrors` がないかを調べ、ビデオアーティファクトが実際に存在することを確認してください。(2) タイムアウト自体を回避するには、スクリーンキャストのサイズを縮小し（例: 1440x1100 から 960x720 に）、品質を 60 に下げ、`cleanupTimeout` を 30000 から 90000 ms に増やしてください。失敗したクリーンアップを実行結果または終了ステータスで明示的に示す修正が現在進行中です。

e2e

概要

README プレビュー

FAQ (5)

同类型项目

tensorflow

superpowers

everything-claude-code

flutter