Metaの大規模言語モデルを活用した自動単体テストの改善

Metaの自動化された単体テスト改善ツール: TestGen-LLM

• Metaが開発したTestGen-LLMは、大規模言語モデル（LLM）を用いて、従来は人手で作成されていたテストを自動的に改善する。
• TestGen-LLMが生成したテストクラスは、元のテストスイートに対して測定可能な改善を保証する一連のフィルターを通過し、LLMのハルシネーション問題を解消した。
• MetaのInstagramおよびFacebook向けプラットフォームで実施したテスト・コンテスト（test-a-thons）におけるTestGen-LLMの導入を説明している。

TestGen-LLMの性能評価

• InstagramのReelsとStories製品に対する評価では、TestGen-LLMのテストケースの75%が正しくビルドされ、57%が信頼性をもって通過し、25%がカバレッジを向上させた。
• MetaのInstagramおよびFacebookのテスト・コンテストでは、TestGen-LLMにより対象クラス全体の11.5%が改善され、Metaのソフトウェアエンジニアは導入のために73%の推奨事項を採用した。
• これは、LLMが生成したコードの産業規模での導入についての初めての報告であり、コード改善に対するこの種の保証が示されたものである。

GN⁺の意見

• TestGen-LLMは、ソフトウェアテストの自動化と品質向上を革新し得るツールであり、大規模言語モデルを活用して既存テストを改善することに成功している。
• このツールは実環境でテストカバレッジを向上させ、信頼性の高いテストケースを生成することで、ソフトウェアエンジニアリングコミュニティに重要な貢献をしている。
• Metaのテスト・コンテストでの成功事例は、TestGen-LLMが実際の製品開発へ統合される可能性を示しており、ソフトウェア開発の効率と安定性を向上させる重要な進展となる。

[GN⁺]

Hacker Newsの意見

• ある大手保険会社で、管理者が全体のコードベースに対して80%のテストカバレッジ目標を設定した。そこで開発者はその目標を達成するため、JavaのDTOのゲッターとセッター向けの単純なユニットテストを書き始めた。若手開発者だった私はこの経験から、KPIの達成だけにフォーカスすると本来の目的と一致しない行動を招きやすいことを痛感した。いくつかのよく設計されたE2Eテストシナリオのほうが、ソフトウェア品質によりよい影響を与えていたはずだ。
• LLMで生成したテストの問題点は、バグを含む振る舞いを「承認」してしまう可能性が高いことだ。コードベースのテストカバレッジが低い場合に特に起こりやすい。手作業で新規テストを作成する場合は、システムが問題を起こしているのかテスト自体が間違っているのかを判断できる人がいる。少なくともそのようなテストは専用のテストフォルダに分離し、適切なレベルで疑って扱うべきだ。
• PDFを読むと、これはただ反復的に通過する、つまり気まぐれに失敗しないテストを生成することのように見える。主な目的は、既存コードの振る舞いを固定化する回帰テストスイートを作ることだ。これは開発者が書いたテストを置き換えるものではなく、開発者のテストは機能要件を把握していると想定している。
• 約20年前に勤務していた会社でAgitarOneを試したことがある。これはJavaコード向けにテストケースを自動生成し、その振る舞いを探索するのに役立つと約束していた。だがAgitarはまた、自動で通過するテストを生成することもでき、それを回帰スイートとして利用できた。個人的にはあまり好きではなかった。管理者は、テストカバレッジが増えたから品質が向上したと思った。LLMのアプローチがAgitarよりどの程度良いのか、気になる。
• テストを作成することは、一般にコード品質を判断する優れた方法だ。テストが複雑で、カバレッジ達成が難しいなら、そのテスト対象コードに改善が必要な可能性が高い。
• unlogged.ioでは、しばらくの間、JUnitテストを自動生成することに集中していた。いくつかの理由でこのアプローチは成功しなかった：1) 開発者が管理したがらない大量の生成テストコード、2) 実世界シナリオをシミュレートしない生成テスト、3) バニティ指標としてのコードカバレッジ。現在は、すべての固有のプロダクションシナリオを再現するノーコードのリプレイテスト提供に注力している。参考までに、私はunlogged.ioの創業者だ。
• 反対にアプローチしたい。受け入れ基準を入力して、それを検証するテストを生成し、テストに合格するコードだけを生成したい。Copilotを使うと時々限定的にその方向に近づけるが、なぜこのやり方に力を入れる人がいないのか疑問だ。
• TestGen-LLMは奇妙な産物だ。リファクタリングやリライトの第一段階としては使えると思うが、論文でのコードカバレッジへのこだわりは完全にブレているように見える。組織がすでにそういう（高いカバレッジを求める）状態ならよいのだろうが、TestGen-LLMはプロジェクトのコードを何も改善せず、実際の改善実装に伴う摩擦を増やすだろう。コンパイラエラーと失敗したテストに依存してLLMゴミをふるい分けるTestGen-LLMは、通過するかどうか曖昧なエッジケーステストを生成する方がはるかに有用だろう。論文に生成テストの例がないので、それらは私が見た他のLLM生成コードと同じく、アマチュアっぽいものだと疑っている。
• 将来、巨大な自動生成テストコーパスを維持するコストがどのくらいになるのか気になる。ケースを生成することだけでなく、更新するための自動化手法も提供しなければならない。
• Metaの従業員が開発者向けAIをプロモートするために12ページの論文を出したことは興味深い。しかもサンキー図まで使っている。おそらく間違っている可能性はあるが、このように公表するなら再現可能な情報を提供すべきではないか。Metaが学習に使えるデータが必要だからだ。何かを公開したのだろう。
• InstagramのReelsとStories製品の評価では、TestGen-LLMのテストケースの75%が正しく構築され、57%が信頼性高く通過し、25%がカバレッジを増やした。あまり良い結果とは言えないようだ。