技術的概要：MocklessTester

問題定義

大規模言語モデル（LLM）は自動テスト生成の可能性を示しているが、Java における既存のアプローチは、テスト対象メソッド（MUT）をその依存関係から隔離するために、主にモックフレームワーク（例：Mockito）に依存している。この依存関係は、以下の 2 つの根本的な限界をもたらす：

1. 浅いカバレッジ：モックされたテストは MUT を孤立して実行するため、依存クラスの実動作はテストされない。
2. モックの脆弱性：テストは想定された API の動作に密結合するため、依存関係が変化しても実動作が互換性を保っていれば、テストは破綻する。

実依存関係をインスタンス化して実行する「モックレステスト」は解決策を提供するが、重大な課題に直面している。有効なモックレステストを生成するには、言語制約の厳密な遵守、正しいオブジェクトのインスタンス化、および有効な API 呼び出しシーケンスが必要である。現在の LLM ベースのアプローチは、幻覚（ハルシネーション）の 2 つの根本原因により、ここで苦戦している：

• 知らない（Not Knowing）：LLM が正しいコードを生成するために必要なプロジェクト固有のコンテキスト（有効なコンストラクタ、ファクトリメソッド、または使用パターンなど）を欠いている。
• 従わない（Not Following）：制約が提供されていても、LLM がそれらに従わない（例：記号の有効性や API 呼び出しプロトコルの違反）。これはしばしば強制メカニズムの欠如に起因する。

手法：MocklessTester

著者らは、反復的な「計画－生成－検証－修正」ワークフローを採用する、Java 向けのモックレス単体テスト生成手法であるMocklessTesterを提案する。このシステムは、特定された根本原因に対処するための 2 つの中核戦略、すなわちコンテキスト強化生成と制約強制修正を中心に構築されている。

1. 準備段階

テスト生成開始前に、MocklessTester は対象リポジトリを分析し、3 つのプロジェクト固有のアーティファクトを構築する：

• コードプロパティグラフ（CPG）：Joern を使用して構築され、依存関係の使用を捕捉する。これにより、プログラムスライシングを通じて、実オブジェクトの構築と API 呼び出しの例を取得できる。
• ClassIndex：プロジェクトから可視なすべてのクラス、メソッド、コンストラクタ、およびインポートの記録。修正中の記号の検証と型の解決における真実の基準として機能する。
• マルコフ型状態モデル：状態を持つ API に対する有効なメソッド呼び出し順序を捉える確率モデル。ソースコードの証拠から初期化され、テスト結果に基づいて動的に更新され、不正な呼び出しシーケンスを検出する。

2. 反復的マルチエージェントループ

生成プロセスには 5 つのエージェントが関与する：Initializer、Planner、Generator、Validator、およびFixer。

• コンテキスト強化生成：「知らない」を緩和するため、Generatorは CUT ソースコードのみに依存しない。代わりに、プログラムスライサーがプロジェクトの生産コードとテストコードから依存関係の実インスタンス化と使用パターンを採掘する。これらのパターンはプロンプトに注入され、LLM が妥当なオブジェクトインスタンス化を作成するよう導く。
• 制約強制修正：「従わない」を緩和するため、Fixerは失敗したテストに対して 2 段階の修復メカニズムを採用する：
  • 段階 I（Fixer I）：実行フィードバック（コンパイル/ランタイムエラー）に基づいて初期の修正を生成する。
  • 段階 II（Fixer II）：初期の修正が制約に違反する場合、2 回目の修復がトリガーされる。LLM は 3 つのレベルの制約を満たす修正を生成し、その修正がどのように失敗を解決し、ルールに準拠しているかを説明する構造化された正当化を提供しなければならない：
    • 記号レベル：すべてのクラス、メソッド、およびインポートがClassIndexに存在することを保証する。
    • プロトコルレベル：API 呼び出しシーケンスがマルコフ型状態モデルを尊重することを保証する（例：使用前に状態を初期化する）。
    • 反復レベル：経験メモリを活用する。これは成功した修復パターン（ゴールドテスト）、修復レシピ、および回避すべきアンチパターンを保存し、既知の失敗の繰り返しを防ぐ。

主要な貢献

1. コンテキスト強化プロンプティング：著者らは、依存関係の使用パターンを重要なコンテキストとして特定する。ターゲットプロジェクトから採掘された実依存関係のインスタンス化例で LLM を拡張する戦略を提案し、知識不足に起因する幻覚を大幅に減少させる。
2. 制約強制修正メカニズム：記号レベル、プロトコルレベル、および反復レベルの制約を強制する、新規の 2 段階修復プロセス。重要なのは、第 2 段階においてモデルが修正の正当性を構造化して生成することを要求し、直接「従わない」幻覚を対象としている点である。
3. Java 向け初のモックレス LLM アプローチ：MocklessTester は、外部依存関係を明示的に対象とする Java 向けの最初の LLM ベースアプローチとして提示され、モック単体テストから現実的な実行へと自動テストを前進させる。
4. 包括的な実証評価：本研究は、テスト対象クラス（CUT）を超えた実プロジェクトコードの実行範囲を測定する新しい指標として**依存行カバレッジ（DepLC）**を導入する。

実験結果

このアプローチは、Defects4J（14 プロジェクト、130 クラス）と、新しいベンチマークであるDeps4J（5 つの最近のマルチモジュールプロジェクト、30 クラス）において、最先端のベースラインPANTAに対して評価された。

• 有効性：

  • Defects4Jにおいて、MocklessTester は平均行カバレッジを19.99%（68.83% → 88.82%）、ブランチカバレッジを24.90%（58.84% → 83.74%）向上させた。変異スコアは**13.67%**増加した。
  • Deps4Jにおいて、行カバレッジを22.69%、ブランチカバレッジを**15.78%**向上させ、変異スコアは同等を維持した。
  • 依存カバレッジ：MocklessTester は実依存コードを大幅に多くカバレッジし、Defects4J ではベースラインと比較してプロジェクト DepLC を378 行、Deps4J では55 行増加させた。
  • テスト効率：プロジェクトあたりの生成テスト数が平均して少ないにもかかわらず、MocklessTester はより高いカバレッジを達成し、テストあたりの品質が高いことを示している。

• 効率性：

  • MocklessTester は、より高いカバレッジに到達するためにより多くの反復を行うため、総トークン数と時間コストが高かった。
  • しかし、コストは実用的な範囲内である：Defects4J においてメソッドあたり平均108.97 秒、26.59k トークン。
  • 注目すべきは、MocklessTester は反復あたりの処理がベースラインよりも大幅に高速（約 58% 時間短縮）であったことで、反復数が多くても時間効率的であることを示唆している。

• アブレーション研究：

  • **使用取得（Usage Retrieval）**を除去すると、パフォーマンスが最も大きく低下し、コンテキストの重要性が確認された。
  • プロトコルレベル制約を除去すると、2 番目に大きな影響があり、明示的な強制なしに状態を持つオブジェクトを管理することの難しさが浮き彫りになった。
  • 記号レベルおよび反復レベルの制約も、やや小さいものの、有意な改善をもたらした。

意義と主張

本論文は、MocklessTesterが実プロジェクト依存関係を行使するテストの生成を可能にすることで、モックベーステストの限界を成功裏に克服したと主張する。「知らない」をコンテキスト強化によって体系的に、「従わない」を制約強制によって体系的に対処することで、このアプローチは確立されたベンチマークおよび新しいベンチマークの両方で、行カバレッジ、ブランチカバレッジ、変異スコアにおいて最先端の結果を達成する。

著者らは、このアプローチがベースライン手法よりも高い計算リソースを必要とするが、そのトレードオフは、カバレッジにおいてより包括的であるだけでなく、依存関係の進化に対してより堅牢なテストをもたらすと強調している。DepLCの導入は、テストスイートを評価する新たな次元を提供し、CUT を超えてより広範なシステムの実行を測定する。この研究は、将来の改善には、より豊かなメモリメカニズムと、パーサ中心コンポーネントのための文法意識入力生成が含まれる可能性を示唆している。