Menü
統合テストとE2Eテストを設計。モック境界と振る舞い検証ルールを適用。E2Eテスト、統合テスト作成時に使用。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
PRD、ADR、Design Doc、UI Spec、作業計画書の作成を支援。技術ドキュメントの作成・レビュー時、または「UI Spec/画面設計/コンポーネント分解」が言及された時に使用。
入力・出力・成功基準・決定事項・未解決条件を明確化し、下流エージェントが推測せず実行できるようにする。LLM向けのプロンプト・ハンドオフ・計画成果物・レビュー・レポート・生成指示を記述または改訂する時に使用。
タスクの本質を分析し適切なスキルを選択。規模見積もりとメタデータを返却。タスク開始時、スキル選択時に使用。
Guides PRD, ADR, Design Doc, UI Spec, and Work Plan creation. Use when creating or reviewing technical documents, or when "UI spec/screen design/component decomposition" is mentioned.
Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream agents can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.
Analyzes task essence and selects appropriate skills. Returns scale estimates and metadata. Use when starting tasks or selecting skills.
| name | integration-e2e-testing |
| description | 統合テストとE2Eテストを設計。モック境界と振る舞い検証ルールを適用。E2Eテスト、統合テスト作成時に使用。 |
| テスト種別 | 目的 | スコープ | 外部依存 | ファイル形式 | 機能あたり上限 | 実装タイミング |
|---|---|---|---|---|---|---|
| 統合 | in-processでのコンポーネント間連携を検証 | システムの部分的な統合（in-processモジュール、UIコンポーネントの場合はReact/TSではRTL+MSW） | モック または in-process | *.int.test.ts | 最大3件 | 実装と並行して作成 |
| fixture-e2e | 決定論的フィクスチャを用いてブラウザ上でUIの振る舞いを検証 | UIフロー全体（モックバックエンド/フィクスチャ駆動の状態） | モック/フィクスチャのみ — ライブサービスなし | *.fixture-e2e.test.ts | 最大3件 | UI機能と並行して作成 |
| service-integration-e2e | 起動済みのローカルスタックに対してクリティカルユーザージャーニーを検証 | サービスをまたいだシステム全体 | ローカルの実サービスまたはスタブ | *.service-e2e.test.ts | 最大1-2件 | 最終フェーズでのみ実行 |
レーン選択（E2Eのみ）:
2つのE2Eレーンの予算は独立して計上される — あるジャーニーに fixture-e2e があっても service-integration-e2e の予算は消費されず、その逆も同様。
クリティカルユーザージャーニー: 収益影響・法的要件・大多数のユーザーが日常的に利用する機能
| チェック | 質問 | NOの場合 |
|---|---|---|
| 観測可能 | ユーザーが結果を観測できるか？ | 除外 |
| システム文脈 | 複数コンポーネントの統合が必要か？ | 除外 |
| 自動化可能 | CI環境で安定実行できるか？ | 除外 |
Include: ビジネスロジック正確性、データ整合性、ユーザー可視機能、エラーハンドリング Exclude: 外部実接続、パフォーマンス指標、実装詳細、UIレイアウト
コミットするスケルトンは、テストフレームワーク（describe/it/it.todo 用）のみを import する。テスト対象モジュールは実装タスクが import するものであり、スケルトンでは import しない — まだ作成されていないモジュールを参照するスケルトンは、テストファイルを型チェック・コンパイル・ロードするゲートが実装着手前に失敗し得る。
各テストに以下のアノテーションを含めること。
// AC: "[受入条件原文]"
// ROI: [0-100] | ビジネス価値: [0-10] | 頻度: [0-10]
// 振る舞い: [トリガー] → [処理] → [観測可能な結果]
// @category: core-functionality | integration | edge-case | ux | fixture-e2e | service-integration-e2e
// @lane: integration | fixture-e2e | service-integration-e2e
// @dependency: none | [コンポーネント名] | full-ui (mocked backend) | full-system
// @complexity: low | medium | high
// @real-dependency: [コンポーネント名]（任意、テスト境界で非モックセットアップが指定された場合）
it.todo('[AC番号]: [テスト名]')
@lane 選択ルール:
integration — in-processでのコンポーネント間連携、ブラウザを使用しない（例: React/TSではRTL+MSW、その他言語でも in-process のモジュール/ハンドラ統合）fixture-e2e — モックバックエンド/フィクスチャ駆動の状態に対するブラウザレベルのUI検証。@dependency は通常 full-ui (mocked backend)service-integration-e2e — 起動済みローカルサービスまたはスタブに対するブラウザレベルまたはエンドツーエンドの検証。@dependency は full-system// Property: `[検証式]`
// fast-check: fc.property(fc.[arbitrary], (input) => [不変条件])
it.todo('[AC番号]-property: [不変条件記述]')
以下の3条件をすべて満たす場合、その機能にはマルチステップユーザージャーニーが含まれる:
マルチステップジャーニーは予約スロット適用判定のために分類される:
| 分類 | 条件 | 予約スロット適用 | 例 |
|---|---|---|---|
| ユーザー向け | 人間のユーザーが直接ステップをトリガーし結果を観察する（UI、CLI、または直接的なAPIインタラクション経由） | 対象 — デフォルトで fixture-e2e の予約スロットに割り当て。ジャーニーの正しさが実サービス間の挙動に依存する場合のみ service-integration-e2e の予約スロットを追加 | Web購入フロー、CLIセットアップウィザード、モバイルオンボーディング |
| サービス内部 | バックエンドサービスがユーザーの直接操作なしにステップをトリガーする | 予約スロット対象外 — 統合テストを使用。フルシステム検証が妥当な場合は通常のROI > 50パスを通じた service-integration-e2e は引き続き有効 | 非同期ジョブパイプライン、サービス間saga、スケジュールバッチ処理 |
この分類は予約スロットルールおよびE2Eギャップチェックに適用される。それ以外の選定はレーンごとのROIルール（後述）に従う。
ROI Score = Business Value × User Frequency + Legal Requirement × 10 + Defect Detection（範囲: 0–120）
ROI Scoreは同一テスト種別内での優先順位付けに使用する（統合テスト同士、E2Eテスト同士）。テスト種別間の比較には使用しない。統合とE2Eの予算は独立して選択されるため、種別間比較は不要。
ROI Scoreが高い = 同一テスト種別内での優先度が高い。正規化やキャッピングは適用しない — 生のスコアをそのままランキングに使用する。重複排除は候補自体を除外する別のステップであり、スコアは変更しない。
2つのE2Eレーンは所有コストが大きく異なるため、独立した閾値を使用する。
| レーン | ROI閾値 | 理由 |
|---|---|---|
| fixture-e2e | ROI ≥ 20（予約スロット以外） | ハーネスが整備されていればコストは統合テストと同等。少数のテストで十分な場合に MAX 3 を低シグナルなテストで埋めてしまうことを避けるためのフロア（基準点） |
| service-integration-e2e | ROI > 50（予約スロット以外） | 作成・実行・保守コストが統合テストの3〜10倍。他の方法では価値を立証できないジャーニーのみに使用 |
予約スロットのルールはレーンごとに適用され、閾値を上書きする（予約された候補はROIスコアに関わらず出力される）。予約スロット以外でフロアを下回る候補は出力されず、予算は意図的に未消化のまま残し、低価値なテストで埋めない。
| シナリオ | BV | Freq | Legal | Defect | ROI Score | テスト種別 | 選択結果 |
|---|---|---|---|---|---|---|---|
| コア決済UIフロー | 10 | 9 | true | 9 | 109 | fixture-e2e | 選択（予約スロット: ユーザー向けマルチステップジャーニー、フィクスチャによるブラウザ検証） |
| 実決済サービスへのコア決済 | 10 | 9 | true | 9 | 109 | service-integration-e2e | 選択（実サービスでの正しさ。ROI閾値超過） |
| Dismissボタンによる UI 状態更新 | 6 | 7 | false | 8 | 50 | fixture-e2e | 選択（fixture-e2e 予算3件中ランク2位） |
| 決済エラーメッセージ表示（UI） | 5 | 4 | false | 7 | 27 | fixture-e2e | 選択（fixture-e2e 予算3件中ランク3位） |
| 任意フィルタ切替 | 3 | 4 | false | 2 | 14 | fixture-e2e | 不選択（ランク4位、予算上限到達） |
| 実プロバイダへの決済リトライ | 8 | 3 | false | 7 | 31 | service-integration-e2e | ROI閾値未満（31 < 50）、不選択 |
| DB永続化チェック | 8 | 8 | false | 8 | 72 | 統合 | 選択（3件中ランク1位） |
| 純粋なデータ変換 | 5 | 3 | false | 4 | 19 | 統合 | 選択（3件中ランク2位） |
Property注釈がある場合、fast-checkライブラリ必須:
import fc from 'fast-check'
it('AC2-property: モデル名は常にgemini-3-pro-image-preview', () => {
fc.assert(
fc.property(fc.string(), (prompt) => {
const result = client.generate(prompt)
return result.model === 'gemini-3-pro-image-preview'
})
)
})
必須事項:
fc.assert(fc.property(...)) 形式で記述// fast-check:コメントをそのまま実装に反映振る舞い記述の検証レベル:
| ステップ種別 | 検証対象 | 例 |
|---|---|---|
| トリガー | Arrangeで再現 | API障害 → mockResolvedValue({ ok: false }) |
| 処理 | 中間状態または呼び出し | 関数呼び出し、状態変更 |
| 観測可能な結果 | 最終出力の値 | 戻り値、エラーメッセージ、ログ出力 |
判定基準: 「観測可能な結果」がテスト対象の戻り値またはモックの呼び出し引数として検証されていれば合格
| スケルトンの状態 | 検証項目の決定方法 |
|---|---|
// 検証項目: が列挙されている | 列挙された全項目をexpectで実装 |
// 検証項目: がない | 「振る舞い」記述の「観測可能な結果」から導出 |
| 両方ある | 検証項目を優先、振る舞いは補足として使用 |
| 判断基準 | モック | 実物 |
|---|---|---|
| テスト対象の一部か？ | No → モック可 | Yes → 実物必須 |
| 呼び出しがテストの検証対象か？ | No → モック可 | Yes → 実物または検証可能なモック |
| 外部ネットワーク通信か？ | Yes → モック必須 | No → 実物推奨 |
判定フロー:
fixture-e2e:
@dependency: full-ui (mocked backend)）。ライブサービス不要service-integration-e2e:
@dependency: full-system）| チェック | 不合格条件 |
|---|---|
| Property検証 | Property注釈があるのにfast-check未使用 |
| 振る舞い検証 | 「観測可能な結果」に対応するexpectがない |
| 検証項目網羅 | 列挙された検証項目がexpectに含まれていない |
| モック境界 | 統合テストで内部コンポーネントをモック化 |
| チェック | 不合格条件 |
|---|---|
| AAA構造 | Arrange/Act/Assertの区切りが不明確 |
| 独立性 | テスト間で状態共有、実行順序依存 |
| 再現性 | 日時・乱数に依存し結果が変動 |
| 可読性 | テスト名と検証内容が一致しない |