demock

バンドルされたスクリプトを使い、テストダブル、握りつぶされた失敗、または実コードパス上のプレースホルダーの候補を見つけ、それぞれを読み、何かを修正する前に、実際に使うべき依存関係または原因を明示する失敗を提案します。

目標

実コードパスでは、うたわれている処理が実行されます。成功とは処理が実際に行われたことを意味し、失敗はその原因を明らかにします。対象範囲は人が指定したものです。ファイル、ディレクトリ、差分、または直近に行った変更が該当します。実行対象を実行自体が選ぶことはありません。

実行結果では、各検出事項について、場所、実コードパスから到達することを示す証拠、分類、提案を報告します。さらに、人が承認した各項目について、最初に失敗したテストと修正内容を報告します。対象範囲に検出事項がなければ、何も変更せず、その旨を伝えます。

ワークフロー

1. まず実コードパスとテストパスを分けます。 テストディレクトリ、ファイル名の規則、テスト設定から、リポジトリのテスト規約を確認します。実コードパスとは、エントリーポイント（ビルド出力、エクスポート、ハンドラー、CLI）から到達するコードです。依存性注入やレジストリによって何が接続されるかも含め、インポートと呼び出しをたどります。どこからも到達しないコードはデッドコードであり、ここでの検出事項ではありません。クリーンアップの作業として報告します。
2. 候補を列挙します。 このスキルのフォルダーから node scripts/scan.mjs <paths...> [--test-glob <glob>]... [--json] を実行し、対象範囲をスキャンします。リポジトリの規約で既定値以外のテストパスが指定されている場合は、それぞれに --test-glob を追加します。テストパス外の候補について、ファイル、行、種類、証拠テキストが出力されます。--json を指定すると、JSON オブジェクトが 1 つ出力されます。終了コードは、候補なしが 0、候補ありが 3、使用方法の誤りが 2 です。終了コード 2 は実行の不備です。コマンドを修正して再実行します。名前の一致は手がかりであり、判定ではありません。
3. リポジトリ独自のリンタールールを追加します。 リポジトリですでに、握りつぶされた失敗を検出するルール（ruff BLE、S110 と S112、ESLint no-empty、Go errcheck）を含むリンターを使っている場合は、リポジトリ独自のスクリプトまたはローカルにインストール済みのバイナリーを使い、リポジトリが指定するバージョンでそれらのルールを実行し、検出結果を候補に追加します。新しいツールはインストールしません。
4. 各候補を読み、分類します。 クラス（a）は、実コードパス上のテストダブルです。クラス（b）は、成功を偽装するものです。失敗を成功に変える catch（ログ出力の有無は問いません）、呼び出し元が実際の結果と見分けられないフォールバック、またはシークレット、依存関係、入力が欠けているときに、リクエストを通してしまうアクセス、支出、削除、カウント対象のシグナルに関するゲートが該当します。クラス（c）はプレースホルダーです。実コードパスから到達する未完成の実装が該当します。クラス（d）は意図されたものです。実装が実行時に選択されるシーム、呼び出し元が認識でき、対処できるよう設計された縮退動作（型付きの空の結果、フラグ、文書化されたステータスなど）、実コードパスでは既定で無効になっていると文書化されたオフラインモード、または本番ビルドから除外されるコードが該当します。（d）は証拠とともに残します。実コードパスに到達することを確認できない場合は、候補を分類して提案を示し、未検証と明記します。
5. （a）、（b）、（c）の各項目について修正を提案します。 実際に使うべき依存関係、または原因を明らかにする失敗を提案します。リクエストを通してしまうゲートには、拒否を提案します。偽物を別の偽物に置き換える提案は決してしません。
6. 停止して報告します。 検出事項と提案を報告し、スクリプトが見逃したパターンも含めて、実行を終了します。人は修正する項目を指定して承認します。それ以外は何も変更しません。
7. 承認された項目を一つずつ修正します。 まず偽物で失敗するテストを書き、実コードパスが実行されること、または失敗の原因が明らかになることを証明します。その後で項目を修正し、リポジトリのチェックを再実行します。

ルール

• 対象範囲は、人が指定したものに限ります。対象範囲を広げたり、自分で対象を選んだりしてはいけません。
• 候補となるパターンとデフォルトのテスト規約はスクリプトが管理します。見落としたパターンは、修正と同じ承認のもと、テストを添えてスクリプトの変更として提案します。
• テスト内のテストダブルには手を加えません。
• 境界でログを記録した後に再スローする処理は、正当なエラー処理であり、そのまま残します。
• 修正では、偽物を実際の依存関係または正当なエラー処理に置き換えます。別の偽物に置き換えてはいけません。
• 人の承認なしに修正してはいけません。また、修正ごとに、事前に失敗するテストが必要です。
• 検出事項がなかった実行では、何も変更しません。
• テストダブルの用語は、Gerard Meszarosのテストダブル分類（dummy、stub、spy、mock、fake）と、Martin Fowlerの「Mocks Aren't Stubs」に従います。

検証

完了前に、次の点を確認します。

1. すべての検出事項について、場所、実際の処理経路に到達することを示す証拠または未検証の表示、分類、提案が記載されている。
2. 人の承認なしに変更されたファイルがない。
3. 適用された修正にはすべて、事前に失敗するテストがある。
4. スクリプトを変更した場合、そのテストはスキルフォルダーへのジャンクションまたはシンボリックリンクを経由してCLIを呼び出し、成功する。