テストがパスしても実際のシステムが動かないなら、そのテストはあなたに嘘をついています。このプラグインは実依存関係でのテストを強制します — 実際のサービス、実際のデータ、モックなし。テスト作成・機能検証・モック言及のタイミングで自動トリガーし、システムが本当に動くことを証明するシナリオへと誘導します。

インストール

/plugin marketplace add 2389-research/claude-plugins
/plugin install scenario-testing

できること

プラグインが強制するルールは1つ: 実依存関係でシナリオがパスするまで、機能は検証されない。

Claude Code にテスト作成を依頼すると、このスキルが介入してシナリオアプローチへ誘導します。モックした依存関係を持つユニットテストではなく、.scratch/ ディレクトリに実サービスへアクセスするシナリオファイルを書きます — 実データベース (テストインスタンス)、実認証プロバイダー (サンドボックスモード)、実ファイルストレージ (テストバケット)。サンドボックスとテストモードはOKです。モックはダメです。

真実の階層が哲学を示します:

シナリオテスト (実システム、実データ) — 真実
ユニットテスト (独立したロジック) — 有用だが証明にならない
モック — バグを隠す嘘

モックテストは正しい引数で正しい関数を呼び出したことを教えてくれます。シナリオテストは物事が実際に動いていることを教えてくれます。

各シナリオはスタンドアロンで実行。 シナリオ間の順序依存なし。各シナリオが自分でテストデータをセットアップし、実サービスで実行し、後片付けをします。並列実行でもCI/CDで脆弱な順序問題は起きません。

スキルが拒否する言い訳:

「ちょっとしたユニットテストだけ…」 — ユニットテストは機能を検証しない
「エンドツーエンドが必要なほど複雑じゃない…」 — インテグレーションはシンプルなものを壊す
「速度のためにモックする…」 — テストが嘘をつくなら速度は意味がない

仕組み

2つの成果物、2つのライフサイクル。

.scratch/ ファイルは一時的なシナリオスクリプトです。タスクに合った言語で書きます。.scratch/ に置かれ、gitignoreされます — コミットされることはありません。これがあなたの実際のテストで、実サービスに当たって動くことを証明するものです。

# .scratch/test-auth.py
def test_user_can_register_and_login():
    user = register_user(email="test@example.com", password="s3cure")
    assert user.id is not None

    token = login(email="test@example.com", password="s3cure")
    assert token is not None

    delete_user(user.id)  # cleanup

scenarios.jsonl は永続的な記録です。シナリオがパスしてパターンを残す価値があると判断したら、1行のJSONエントリとして抽出します。このファイルはコミットされます — 使い捨てのテストコードを含まずに何が動くべきかを記述します。

{"name":"user-auth","description":"Register and login with real auth service","given":"New credentials","when":"User registers then logs in","then":"Valid token returned","validates":"Auth flow"}

.scratch/ で書き、実サービスで実行し、パスを確認し、パターンを scenarios.jsonl に抽出して次に進む。スクラッチファイルは開発中に積み重なり、適宜クリーンアップします。JSONLファイルはシステムができることの生きた仕様として成長します。