https://arxiv.org/abs/2402.09171

論文の概要（超要約）

Meta が社内で運用している ### TestGen-LLM は、LLM を使って ### 既存の Kotlin 単体テストを“改良” するツールです。 「生成したテストが本当に価値を足しているか」を自動で検証し、合格したものだけをエンジニアにプルリクとして提示します。

仕組み - Assured Offline LLMSE

1. 候補生成

• 2種類の社内 LLM（論文では LLM-1/LLM-2 と表記）に複数プロンプトを投げ、既存テストクラスに追加するテストケースを大量生成。

2. 3段フィルターで保証を付与

   1. Builds → コンパイルを通るか
   2. Passes → 5回連続で安定パス（フレーク防止）
   3. Improves→ 命令網羅や分岐網羅が増えたか
      • 合格したテストだけが“改善”とみなされ、ドキュメント付きの diff が自動作成される。
3. 人間レビュー
   • フィルターを通過した diff は通常のコードレビューに載り、最終承認だけ人間が行う。

導入・評価結果

• 社内ベンチマーク（Instagram Reels & Stories）
  • 生成テストの 75 % がビルド合格、57 % が安定パス、25 % がカバレッジ増加
• Test-a-thon①（Instagram, 2023-11）
  • 17 diff 中 16 diff が本番導入。行カバレッジ中央値 +2.5 行／テスト。
• Test-a-thon②（Instagram+Facebook, 2023-12）
  • 適用したクラスの 11.5 % を改善。エンジニアが 73 % の提案を受入れ。

何が新しいのか

• 「生成」ではなく「改良」
  • 既存テストに corner-case を追加するため、実プロダクトにマージされやすい。
• LLM ハルシネーションを“工学的に”封じ込め
  • 失敗・フレーク・カバレッジ不足を段階的に落とすことで保証付きコード生成を実現。
• 産業規模での採用報告
  • LLM 生成テストが大規模コードベース（Instagram/Facebook）に本番導入された初の公開事例と主張。

技術・運用上の教訓

• テスト oracle が無い領域では「失敗したら捨てる」戦略が有効
  • バグ検出よりもリグレッション防止を優先し、初回失敗テストは全て破棄。
• フレーク排除は必須
  • 5 回連続パスの簡易チェックでも効果大。CI 安定性を崩さず導入できた。
• LLM & プロンプトは“アンサンブル”で
  • 同一 LLM でも温度・システムプロンプト差分を並列実行し、多様な候補を確保。
• カバレッジメトリクスを DevEx に翻訳
  • diff に自動で「何行増えたか」「未カバー分岐を取ったか」を添付するとレビュー速度が向上。

限界と今後の課題

• Oracle 不在領域の網羅拡大
  • 現状は「パスする＝正しい」と仮定。仕様ベースアサーション生成などが今後のテーマ。
• より深いセマンティック保証
  • カバレッジ以外にミューテーションスコアやプロパティベーステストを組み込みたい。
• 他言語・モノレポ統合
  • Kotlin(Android) 以外のサービス層や C++ など多言語環境への適用検証が未着手。

ざっくり感想

「LLM にテストを書かせると壊れる」という先入観に対し、### “保証付きパイプライン”をはさめば実務投入できる ──という実証が最大の貢献。 特に ### Build→Pass→Improve の 3 段フィルターは、小規模プロジェクトでも応用しやすい設計パターンです。

関連

• cover-agent を使ってみる
  • cover-agent / mizchi