Testing

​

title: テストと開発

​

概要

​

開発向けテストエージェント

{
  "agent_uri": "https://test-agent.adcontextprotocol.org/mcp",
  "protocol": "mcp",
  "version": "1.0",
  "auth": {
    "type": "bearer",
    "token": "1v8tAhASaUYYp4odoQ1PnMpdqNaMiTrCRqYo9OJp6IQ"
  }
}

{
  "agent_uri": "https://test-agent.adcontextprotocol.org/a2a",
  "protocol": "a2a",
  "version": "1.0",
  "auth": {
    "type": "bearer",
    "token": "L4UCklW_V_40eTdWuQYF6HD5GWeKkgV8U6xxK-jwNO8"
  }
}

• 認証付きオペレーションの試験
• 連携パターンの練習
• リクエスト/レスポンス構造の検証
• クライアント実装の開発・デバッグ

​

プロトコル適合性テスト

​

Addie を使ったテスト

“Hey Addie, test my sales agent at https://sales.example.com”

• health_check - エージェントが応答するか確認
• discovery - get_adcp_capabilities、get_products、list_creative_formats をテスト
• create_media_buy - ディスカバリー + テストキャンペーン作成
• full_sales_flow - 作成 → 更新 → 配信のライフサイクル全体
• creative_sync - sync_creatives フローをテスト
• creative_inline - create_media_buy でのインラインクリエイティブをテスト
• pricing_models - チャネル横断で価格オプションを分析

• error_handling - 判別共用体のエラーレスポンスが適切か確認
• validation - 無効な入力（マイナス予算、無効な enum など）を拒否するかテスト
• pricing_edge_cases - オークションと固定価格、min_spend 要件、bid_price の扱いを検証
• temporal_validation - 日付/時刻の順序や ISO 8601 形式のバリデーションをテスト

• behavior_analysis - 認証要件、brand_manifest 必須要件、ブリーフの関連性フィルタ、チャネルフィルタなどエージェントの特性を分析

​

セールスエージェント適合チェックリスト

• get_adcp_capabilities - エージェントの能力やポートフォリオ、サポート機能を返す
• get_products - pricing_options、format_ids、delivery_type 付きで商品を返す
• list_creative_formats - サポートするフォーマットとクリエイティブエージェントを返す

• create_media_buy - product_id、pricing_option_id、budget 付きパッケージを受け付ける
• update_media_buy - 予算、ペーシング、ターゲティングの PATCH セマンティクスに対応
• get_media_buy_delivery - インプレッション、支出、ステータスを返す

• sync_creatives - アイテム単位のアクション追跡付きでクリエイティブを upsert
• list_creatives - フィルタ付きでクリエイティブラリを検索
• create_media_buy でのインラインクリエイティブ対応
• クリエイティブ参照（creative_ids）対応

• CPM - インプレッション 1,000 件あたりのコスト
• vCPM - ビューアブル CPM（MRC 標準）
• CPCV - 完視聴あたりのコスト
• CPC - クリックあたりのコスト
• CPP - rating point あたりのコスト（TV/ラジオ）
• 定額 - 固定費のスポンサーシップ
• オークション価格 - pricing option に fixed_price がない場合 bid_price をサポート

• 静的クリエイティブ（画像・動画アセット）
• 参照クリエイティブ（既存ライブラリへの creative_ids）
• ジェネレーティブクリエイティブ（マニフェストベース）
• パラメータ化クリエイティブ（置換付き）

• 判別共用体レスポンス（success XOR errors）
• スキーマ準拠レスポンス（JSON スキーマで検証）
• 非同期オペレーションは submitted/working/completed のステータスを返す
• バッチオペレーション（例: sync_creatives）でアイテムごとのエラーを返す

• X-Dry-Run ヘッダー対応
• 並列テスト分離のための X-Test-Session-ID
• 時間シミュレーション用の X-Mock-Time

• 予算のマイナス値を拒否
• 無効な pacing enum を拒否
• end_time が start_time より前の場合に拒否
• 無効な ISO 8601 日付形式を拒否
• 存在しない product_id に対して適切なエラーを返す
• オークション価格のとき bid_price を必須にする
• min_spend_per_package 未満の予算を拒否
• クリエイティブ weight > 100 を拒否
• 判別共用体のエラーレスポンスを返す（success と errors を同時に返さない）

​

テストモード

​

ドライランモード

X-Dry-Run: true

• 実際のプラットフォーム API 呼び出しは行われない
• 実費は発生しない
• レスポンスにテストモードが有効であることが示される
• すべての操作はシミュレートされた現実的な結果を返す

​

時間シミュレーションモード

X-Mock-Time: 2025-01-01T09:00:00Z
X-Auto-Advance: true

• X-Mock-Time: 現在のシミュレーション時刻を設定
• X-Auto-Advance: 次のイベントへ自動で進める
• X-Jump-To-Event: 特定のキャンペーンイベントへジャンプ

​

リクエストヘッダー

​

テスト制御ヘッダー

X-Dry-Run: <boolean>             # ドライランモードを有効化
X-Test-Session-ID: <string>      # 並列テストセッションを分離
X-Mock-Time: <ISO-8601>          # 現在のシミュレーション時刻を設定
X-Auto-Advance: <boolean>        # 次のイベントへ自動で進行
X-Jump-To-Event: <event_name>    # 特定イベント（ライフサイクルまたはエラー）へジャンプ

​

レスポンスヘッダー

X-Dry-Run: true                  # ドライランモードが有効であることを示す
X-Test-Session-ID: <string>      # テストセッション識別子
X-Mock-Time: <ISO-8601>          # 現在のシミュレーション時刻
X-Next-Event: <event_name>       # 次に予定されるイベント
X-Next-Event-Time: <ISO-8601>    # 次のイベントが発生する時刻
X-Simulated-Spend: <decimal>     # これまでのシミュレート支出

​

イベント進行

​

ジャンプ可能なイベント

• campaign_created - 初期セットアップ完了
• campaign_approved - クリエイティブ提出が可能
• creative_approved - 配信開始の準備完了
• campaign_launched - ライブ配信開始
• campaign_50_percent - スケジュールの中間地点
• campaign_completed - 自然終了

• creative_policy_violation - クリエイティブの拒否を強制
• budget_exceeded - 予算超過をシミュレート
• inventory_unavailable - 在庫不足をシミュレート
• manual_approval_delay - HITL 承認の遅延を追加

​

時間の進行

X-Advance-Time: 7d

X-Auto-Advance: true

​

テスト例

​

例: クリエイティブ拒否のテスト

POST /sync_creatives
Headers: {
  "X-Dry-Run": "true",
  "X-Jump-To-Event": "creative_policy_violation"
}

Response: {
  "status": "rejected",
  "dry_run": true,
  "errors": [{
    "code": "POLICY_VIOLATION",
    "message": "Creative violates policy (test event)"
  }]
}

​

例: 時間進行のテスト

POST /create_media_buy
Headers: {
  "X-Dry-Run": "true",
  "X-Mock-Time": "2025-01-01T09:00:00Z"
}

Response: {
  "media_buy_id": "mb_test_123",
  "status": "pending_approval",
  "dry_run": true,
  "simulated_time": "2025-01-01T09:00:00Z"
}

GET /get_media_buy_delivery?media_buy_id=mb_test_123
Headers: {
  "X-Dry-Run": "true",
  "X-Jump-To-Event": "campaign_50_percent"
}

Response: {
  "media_buy_id": "mb_test_123",
  "dry_run": true,
  "simulated_time": "2025-01-15T09:00:00Z",
  "metrics": {
    "impressions": 350000,
    "spend": 5000.00,
    "pacing": "on_track"
  }
}

​

テストパターン

​

パターン 1: ハッピーパスのテスト

X-Dry-Run: true
X-Mock-Time: 2025-01-01T00:00:00Z

​

パターン 2: エラー復旧テスト

X-Dry-Run: true
X-Jump-To-Event: creative_policy_violation

X-Dry-Run: true
X-Jump-To-Event: creative_approved

​

パターン 3: 時間ベースのテスト

X-Dry-Run: true
X-Mock-Time: 2025-01-01T00:00:00Z
X-Auto-Advance: true

​

パターン 4: 並列テスト

// Test Session A - 通常フロー
POST /create_media_buy
Headers: {
  "X-Dry-Run": "true",
  "X-Test-Session-ID": "test-session-a",
  "X-Mock-Time": "2025-01-01T00:00:00Z"
}

// Test Session B - エラーを強制（別セッション）
POST /create_media_buy
Headers: {
  "X-Dry-Run": "true",
  "X-Test-Session-ID": "test-session-b",
  "X-Jump-To-Event": "budget_exceeded"
}

​

実装要件

​

コア要件

1. ドライランモード
   • X-Dry-Run ヘッダーの認識
   • 本番システムへの副作用なし
   • レスポンスでテストモードを明示
2. テストセッション分離
   • 並列テスト分離のための X-Test-Session-ID
   • セッションごとに独立した状態
   • セッション間の干渉なし
3. 基本的な時間制御
   • シミュレーション時刻設定の X-Mock-Time
   • イベント進行のための X-Jump-To-Event
   • 時間ジャンプ間で一貫した状態

​

推奨機能

1. 自動進行
   • 自動進行用の X-Auto-Advance
   • 期間ベースのジャンプ用 X-Advance-Time
2. エラーイベント
   • X-Jump-To-Event によるエラー状態へのジャンプ
   • 一般的なエラーイベント（ポリシー違反、予算問題など）
   • 復旧テスト

​

任意機能

1. 高度なテスト
   • カスタムイベント定義
   • 複雑なエラー注入
   • パフォーマンスシミュレーション
2. 詳細メトリクス
   • 現実的なパフォーマンスカーブ
   • 業界ベンチマークのシミュレーション
   • コストモデリング

​

セキュリティ考慮事項

• テストモードは本番から完全に隔離する必要がある
• テストモードの操作は別途ログに残す
• テストモードでも認証は必須
• レート制限は適用される（閾値が異なる場合あり）

​

まとめ

1. 迅速な開発 - 数秒でライフサイクル全体を検証
2. 包括的なテスト - すべてのシナリオを決定論的にカバー
3. ゼロコスト - テストで実費が発生しない
4. 分離性 - 本番から完全に分離