jpskill.com
🛠️ 開発・MCP コミュニティ

scenario-testing

コードの動作検証や機能テストを行う際に、実際の依存関係を用いてシナリオベースのテストを効率的に記述するSkill。

📜 元の英語説明(参考)

This skill should be used when writing tests, validating features, or needing to verify code works. Triggers on "write tests", "add test coverage", "validate feature", "integration test", "end-to-end", "e2e test", "mock", "unit test". Enforces scenario-driven testing with real dependencies in .scratch/ directory.

🇯🇵 日本人クリエイター向け解説

一言でいうと

コードの動作検証や機能テストを行う際に、実際の依存関係を用いてシナリオベースのテストを効率的に記述するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o scenario-testing.zip https://jpskill.com/download/6561.zip && unzip -o scenario-testing.zip && rm scenario-testing.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/6561.zip -OutFile "$d\scenario-testing.zip"; Expand-Archive "$d\scenario-testing.zip" -DestinationPath $d -Force; ri "$d\scenario-testing.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して scenario-testing.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → scenario-testing フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

AIコード生成のためのシナリオ駆動型テスト

核となる原則

鉄則: 「実際の依存関係でシナリオがパスするまで、いかなる機能も検証されたことにはならない」

モックは誤った自信を生み出します。実際のシステムを実行するシナリオだけが、コードが機能することを検証します。

真実の階層

  1. シナリオテスト (実際のシステム、実際のデータ) = 真実
  2. ユニットテスト (分離されたもの) = 人間が安心するためだけ
  3. モック = バグを隠す嘘

原則に述べられているように、「モックを使用するテストは、あなたのシステムをテストしているわけではありません。それは、依存関係がどのように振る舞うかについてのあなたの仮定をテストしているのです。」

このスキルを使用するタイミング

  • 新しい機能の検証
  • 作業完了を宣言する前
  • モックを使いたくなったとき
  • 検証が必要なバグを修正した後
  • コードが機能することを証明する必要があるとき

必須のプラクティス

1. .scratch/ にシナリオを記述する

  • タスクに適した任意の言語を使用します
  • 実際のシステムをエンドツーエンドで実行します
  • モックは一切許可されません
  • .gitignore に含まれている必要があります (コミットしない)

2. パターンを scenarios.jsonl に昇格させる

  • 繰り返し発生するシナリオを文書化された仕様として抽出します
  • シナリオごとに1行のJSON
  • 以下を含めます: name, description, given/when/then, validates
  • このファイルはコミットされます

3. 実際の依存関係を使用する

外部APIは実際のサービスにアクセスする必要があります (サンドボックス/テストモードは許容されます)。いかなる依存関係のモックもシナリオを無効にします。

4. 独立性の要件

各シナリオは、以前の実行に依存せずに単独で実行できる必要があります。これにより、以下が可能になります:

  • 並列実行
  • 隠れた順序依存関係の防止
  • 信頼性の高いCI/CD統合

シナリオを無効にするもの

シナリオは、以下の場合に無効です:

  • いかなるモックも含まれている場合
  • 実際のストレージの代わりに偽のデータを使用している場合
  • 別のシナリオが最初に実行されることに依存している場合
  • パスすることを確認するために実際に実行されたことがない場合

避けるべき一般的な違反

これらの合理化を拒否してください:

  • 「ちょっとしたユニットテストだから...」 - ユニットテストは機能を検証しません
  • 「エンドツーエンドには単純すぎる...」 - 統合は単純なものを壊します
  • 「速度のためにモックを使う...」 - テストが嘘をつくなら速度は関係ありません
  • 「API認証情報がない...」 - 人間のパートナーに実際のものを尋ねてください

完了の定義

機能は、以下の場合にのみ完了です:

  1. ✅ .scratch/ 内のシナリオがモックなしでパスする
  2. ✅ 実際の依存関係が実行される
  3. ✅ .scratch/ が .gitignore に残っている
  4. ✅ 堅牢なパターンが scenarios.jsonl に抽出される

ワークフローの例

  1. シナリオを記述する - .scratch/test-user-registration.py を作成します
  2. 実際の依存関係を使用する - 実際のデータベース、実際の認証サービス (テストモード) にアクセスします
  3. 実行して検証する - シナリオを実行し、パスすることを確認します
  4. パターンを抽出する - scenarios.jsonl に文書化します
  5. .scratch を無視したままにする - スクラッチシナリオは決してコミットしません

なぜこれが重要なのか

  • ユニットテスト は分離されたロジックを検証します
  • 統合テスト はコンポーネントが連携して機能することを検証します
  • シナリオテスト はシステムが実際に機能することを検証します

シナリオテストだけが、あなたの機能がユーザーに価値を提供することを証明します。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Scenario-Driven Testing for AI Code Generation

Core Principle

The Iron Law: "NO FEATURE IS VALIDATED UNTIL A SCENARIO PASSES WITH REAL DEPENDENCIES"

Mocks create false confidence. Only scenarios exercising real systems validate that code works.

The Truth Hierarchy

  1. Scenario tests (real system, real data) = truth
  2. Unit tests (isolated) = human comfort only
  3. Mocks = lies hiding bugs

As stated in the principle: "A test that uses mocks is not testing your system. It's testing your assumptions about how dependencies behave."

When to Use This Skill

  • Validating new functionality
  • Before declaring work complete
  • When tempted to use mocks
  • After fixing bugs requiring verification
  • Any time you need to prove code works

Required Practices

1. Write Scenarios in .scratch/

  • Use any language appropriate to the task
  • Exercise the real system end-to-end
  • Zero mocks allowed
  • Must be in .gitignore (never commit)

2. Promote Patterns to scenarios.jsonl

  • Extract recurring scenarios as documented specifications
  • One JSON line per scenario
  • Include: name, description, given/when/then, validates
  • This file IS committed

3. Use Real Dependencies

External APIs must hit actual services (sandbox/test mode acceptable). Mocking any dependency invalidates the scenario.

4. Independence Requirement

Each scenario must run standalone without depending on prior executions. This enables:

  • Parallel execution
  • Prevents hidden ordering dependencies
  • Reliable CI/CD integration

What Makes a Scenario Invalid

A scenario is invalid if it:

  • Contains any mocks whatsoever
  • Uses fake data instead of real storage
  • Depends on another scenario running first
  • Never actually executed to verify it passes

Common Violations to Avoid

Reject these rationalizations:

  • "Just a quick unit test..." - Unit tests don't validate features
  • "Too simple for end-to-end..." - Integration breaks simple things
  • "I'll mock for speed..." - Speed doesn't matter if tests lie
  • "I don't have API credentials..." - Ask your human partner for real ones

Definition of Done

A feature is complete only when:

  1. ✅ A scenario in .scratch/ passes with zero mocks
  2. ✅ Real dependencies are exercised
  3. ✅ .scratch/ remains in .gitignore
  4. ✅ Robust patterns extracted to scenarios.jsonl

Example Workflow

  1. Write scenario - Create .scratch/test-user-registration.py
  2. Use real dependencies - Hit real database, real auth service (test mode)
  3. Run and verify - Execute scenario, confirm it passes
  4. Extract pattern - Document in scenarios.jsonl
  5. Keep .scratch ignored - Never commit scratch scenarios

Why This Matters

  • Unit tests verify isolated logic
  • Integration tests verify components work together
  • Scenario tests verify the system actually works

Only scenario tests prove your feature delivers value to users.