ln-635-test-isolation-auditor

パス： ファイルパス（references/、../ln-*）は、このスキルディレクトリからの相対パスです。

Trustworthiness Auditor（L3 ワーカー）

タイプ： L3 ワーカー

自動テストの結果が決定的で、分離され、信頼できるかどうかを監査する専門ワーカーです。

目的と範囲

• テストの信頼性（カテゴリ 5：中優先度）を監査します
• 決定性、分離、依存関係の制御を確認します
• 不安定なテスト、時間／乱数／順序への依存、共有状態、実際の外部依存関係を検出します
• REWRITE_FOR_DETERMINISM または DELETE_IF_LOW_VALUE を出力します
• 準拠スコア（X/10）を算出します

入力

必ず読み込むこと： references/audit_worker_core_contract.md を読み込みます。

次の情報を含む contextStore を受け取ります：tech_stack、testFilesMetadata、codebase_root、output_dir。

ワークフロー

検出ポリシー：2 層検出（候補のスキャン、その後のコンテキスト検証）を使用します。検証方法が不明確な場合に限り、references/two_layer_detection.md を読み込みます。

1. コンテキストの解析： contextStore から技術スタック、信頼性チェックリスト、テストファイル一覧、output_dir を抽出します
2. 分離の確認（レイヤー 1）： 6 つのカテゴリ（API、DB、FS、時間、乱数、ネットワーク）について分離を確認します 2b) コンテキスト分析（レイヤー 2 -- 必須）： 分離違反ごとに、次を確認します：
   • 統合テストですか？（実際の依存関係の使用が意図されています）-> フラグを立てないでください。分離の問題としてフラグを立てるのは単体テストに限ります
   • テスト設定でインメモリ DB が構成されていますか（grep では確認できない場合があります）？-> スキップ
   • ほかのテスト用にモックを設定するテストヘルパーですか？-> スキップ
3. 決定性の確認： 不安定なテスト、時間に依存するアサーション、順序に依存するテスト、変更可能な共有状態を確認します
4. 対応方針の評価： デフォルトでは REWRITE_FOR_DETERMINISM を使用します。明白なローカルの根拠に基づき、テストの信頼性が低く、かつ価値も低い場合に限り DELETE_IF_LOW_VALUE を使用します
5. 検出結果の収集： 違反ごとに、重大度、場所（ファイル:行）、工数見積もり（S/M/L）、対応、推奨事項を記録します
6. スコアの算出： 重大度ごとに違反数を集計し、準拠スコア（X/10）を算出します
7. レポートの作成： references/templates/audit_worker_report_template.md に従って完全な Markdown レポートをメモリ内で作成し、単一の Write 呼び出しで {output_dir}/ln-635--global.md に書き込みます
8. 概要の返却： 調整役に最小限の概要を返します（出力形式を参照）

監査ルール：テストの分離

1. 外部 API

良好： モックを使用（jest.mock、sinon、nock） 不良： 外部 API への実際の HTTP 呼び出し

検出方法：

• モックなしでの axios.get、fetch(、http.request を grep します
• テストが実際にネットワーク呼び出しを行うか確認します

重大度： 高

推奨事項： 外部 API 呼び出しを制御（モック、スタブ、またはテストサーバーを使用）してください。ツールの選択はプロジェクトのスタックによって異なります。例外： 統合テストでは実際の依存関係を使うことが想定されています。フラグを立てないでください

工数： M

2. データベース

良好： インメモリ DB（sqlite :memory:）またはモック 不良： 実際のデータベース（PostgreSQL、MySQL）

検出方法：

• DB 接続文字列を確認します（localhost:5432、実際の DB URL）
• :memory: を使用せずに beforeAll(async () => { await db.connect() }) を grep します

重大度： 中

推奨事項： DB の状態が制御され、テスト実行間で分離されるようにしてください。例外： 設定を通じてインメモリ DB を使用する統合テストはスキップします

工数： M-L

3. ファイルシステム

良好： モックを使用（mock-fs、vol） 不良： 実際のファイルの読み書き

検出方法：

• モックなしでの fs.readFile、fs.writeFile を grep します
• テストが実際のファイルを作成または削除するか確認します

重大度： 中

推奨事項： ファイルシステム操作を分離（モック、一時ディレクトリ、またはクリーンアップを使用）してください。ツールの選択はプロジェクトのスタックによって異なります

工数： S-M

4. 時刻／日付

良い例： モックを使用（jest.useFakeTimers、sinon.useFakeTimers） 悪い例： モックなしで new Date()、Date.now() を使用

検出方法：

• useFakeTimers を使用していないテストファイル内で new Date() を検索します

重要度： 中

推奨事項： 時刻に依存するロジックでは、制御可能なクロック（フェイクタイマー、注入されたクロック、または時刻プロバイダー）を使用してください。ツールの選択はプロジェクトのスタックによって異なります。

工数： S

5. 乱数

良い例： シード付きの乱数（Math.seedrandom、固定シード） 悪い例： シードなしで Math.random() を使用

検出方法：

• シード設定なしで Math.random() を使用している箇所を検索します

重要度： 低

推奨事項： 決定論的なテストにはシード付きの乱数を使用してください。

工数： S

6. ネットワーク

良い例： モックを使用（Express 用の supertest、実際のポートを使用しない） 悪い例： 実際のネットワークリクエスト（localhost:3000、ポートへのバインド）

検出方法：

• テスト内で app.listen(3000) を検索します
• 実際の HTTP リクエストがないか確認します

重要度： 中

推奨事項： supertest を使用してください（実際のポートは不要です）。

工数： M

監査ルール：決定性

1. 不安定なテスト

内容： ランダムに成功したり失敗したりするテストです。

検出方法：

• テストを複数回実行し、結果に一貫性がないか確認します
• 適切な await を伴わない setTimeout、setInterval を検索します
• 競合状態（非同期処理が await されていない状態）がないか確認します

重要度： 高

推奨事項： 競合状態を修正し、適切な async/await を使用してください。

工数： M-L

2. 時刻依存のアサーション

内容： 現在時刻に対するアサーション（expect(timestamp).toBeCloseTo(Date.now())）です。

検出方法：

• アサーション内の Date.now()、new Date() を検索します

重要度： 中

推奨事項： 時刻をモックしてください。

工数： S

3. 実行順序に依存するテスト

内容： 異なる順序で実行すると失敗するテストです。

検出方法：

• テストをランダムな順序で実行し、失敗するか確認します
• テスト間で共有される変更可能な状態を検索します

重要度： 中

推奨事項： テストを分離し、beforeEach で状態をリセットしてください。

工数： M

4. 共有される変更可能な状態

内容： 複数のテストで変更されるグローバル変数です。

検出方法：

• モジュールレベルの let globalVar を検索します
• テスト間で状態が共有されていないか確認します

重要度： 中

推奨事項： beforeEach を使用して状態をリセットしてください。

工数： S-M

監査ルール：信頼性を損なう要因

1. 共有セットアップを含む過大なテスト（>100行）

内容： 100行を超え、多数のシナリオをテストするテストです。

検出方法：

• テストごとの行数を数えます
• 100行を超える場合は巨大なテストです

重要度： 中

推奨事項： テストを分割し、対象を絞ってください（1テストにつき1シナリオ）。

工数： S-M

2. 動作の遅いテスト（>5秒）

内容： 実行に5秒を超えるテストです。

検出方法：

• テストの実行時間を測定します
• 5秒を超える場合は動作の遅いテストです

重要度： 中

推奨事項： プロジェクトのスタックから選択したテストダブルまたはインメモリサービスを使って外部依存を制御してください。分離を確認した後に限り、並列化してください。

工数： M

3. 似て非なるもの（依存関係を制御していない単体テスト）

内容： 「Unit」とラベル付けされているものの、依存関係をモックしていないテストです。

検出方法：

• テスト名に「Unit」が含まれているか確認します
• すべての依存関係がモックされているか確認します
• モックがない場合は、実際には結合テストです

重要度： 低

推奨事項： 依存関係をモックするか、結合テストに名前を変更してください。

工数： S

4. デフォルト値の見落とし（デフォルト設定を使うテスト）

内容： デフォルト設定値のみを使うテストです。references/risk_based_testing_guide.md に記載されているデフォルト以外の設定ルールを使用してください。例が必要な場合に限り、references/risk_based_testing_methodology.md を読み込んでください。

検出方法：

• テストのセットアップでよく使われるデフォルト値（:8080、:3000、30000、limit: 20、offset: 0）を検索します
• テストの設定値がフレームワーク／ライブラリのデフォルトと一致するか確認します
• ソースコード内の || DEFAULT パターンと、それに一致するテスト値を確認します

重要度： 高

工数： S

スコアリングアルゴリズム

必読： references/audit_scoring.md を読み込んでください。

重大度の対応付け：

• 不安定なテスト、制御されていない外部 API、デフォルト値の見落とし → HIGH
• 実データベース、ファイルシステム、時刻／日付、ネットワーク、過大な共有セットアップ、遅すぎるテスト → MEDIUM
• シードのない乱数、順序依存、密結合した依存関係 → LOW

出力形式

必読： references/templates/audit_worker_report_template.md を読み込んでください。

references/audit_summary_contract.md に従って JSON サマリーを作成してください。管理モードでは、呼び出し元から runId と summaryArtifactPath の両方が渡されます。スタンドアロンモードでは、ワーカーが共通の契約に従って、実行ごとの成果物パスを生成します。

{output_dir}/ln-635--global.md に、category: "Test Trustworthiness" および次のチェック項目を含むレポートを書き込んでください：api_isolation、db_isolation、fs_isolation、time_isolation、random_isolation、network_isolation、flaky_tests、order_dependency、shared_state、default_value_blindness。

references/audit_summary_contract.md に従ってサマリーを返してください。

summaryArtifactPath がない場合は、スタンドアロンの実行時サマリーを .hex-skills/runtime-artifacts/runs/{run_id}/evaluation-worker/{worker}--{identifier}.json に書き込み、必要に応じて同じサマリーを構造化出力にも含めてください。

Report written: .hex-skills/runtime-artifacts/runs/{run_id}/audit-report/ln-635--global.md
Score: X.X/10 | Issues: N (C:N H:N M:N L:N)

注： 検出結果は単一の配列にまとめられます。principle フィールドの接頭辞（Isolation／Determinism／Dependency Control）を使って、問題のカテゴリを特定してください。各検出結果には、action: "REWRITE_FOR_DETERMINISM" または action: "DELETE_IF_LOW_VALUE" が含まれます。

重要なルール

すでに読み込まれている references/audit_worker_core_contract.md を適用してください。

• 自動修正しない： 報告のみ行います
• 工数の目安： S = 1 時間未満、M = 1～4 時間、L = 4 時間超
• 検出結果をフラット化： 分離性、決定性、依存関係制御に関する検出結果を単一の配列にまとめ、principle の接頭辞で区別します
• コンテキストを考慮： 実際の Express アプリを使用する Supertest は、統合テストとして許容されます
• 独自の観点： テスト結果の信頼性のみを監査してください。製品の動作、E2E ジャーニーの価値、ポートフォリオの価値、カバレッジの不足、オラクルの強さ、手動の証拠、構造は評価しないでください
• アクション必須： テストの価値も十分に低いという証拠があり、DELETE_IF_LOW_VALUE を使用する場合を除き、すべての検出結果で REWRITE_FOR_DETERMINISM を使用してください

モニタリング（2.1.98+）： 1 回の実行に 30 秒超かかると予想されるテストを繰り返し実行する場合は、Monitor を使用してください。代替手段：Bash(run_in_background=true)。

完了の定義

すでに読み込まれている references/audit_worker_core_contract.md を適用してください。

• contextStore が正常に解析された（output_dir を含む）
• 3 つの監査グループをすべて完了した：
  • 分離性（6 カテゴリ：API、DB、FS、時刻、乱数、ネットワーク）
  • 決定性（4 項目：不安定、時刻依存、順序依存、共有状態）
  • 依存関係制御（過大な共有セットアップ、遅いテスト、密結合した依存関係、デフォルト値の見落とし）
• 重大度、場所、工数、アクション、推奨事項を含む検出結果を収集した
• ペナルティアルゴリズムを使用してスコアを計算した
• {output_dir}/ln-635--global.md にレポートを書き込んだ（Write 呼び出し 1 回でアトミックに書き込み）
• 契約に従ってサマリーを書き込んだ

---

バージョン： 3.0.0 最終更新日： 2025-12-23