Metaの新しいLLMベースのテスト生成器

Metaの新しいLLMベースのテスト生成器は、開発の未来を垣間見る機会

• Metaは「Automated Unit Test Improvement using Large Language Models at Meta」という論文を発表。
• この論文は、AIを使って開発速度を高め、ソフトウェアのバグを減らす方法を示している。
• LLMを開発者のワークフローに統合しつつ、現在のコードカバレッジを改善する正確で完全なソフトウェア改善案を提案する。

主なポイント

• TestGen-LLMは「Assured LLM-based Software Engineering」（Assured LLMSE）アプローチを使用。
• 複数のLLM、プロンプト、ハイパーパラメータを用いてコード改善案を生成し、最良の改善案を選ぶアンサンブル手法を採用。
• TestGen-LLMは、既存の人間が書いたテストを改善するために特別に設計されている。

統計

• InstagramのReelsおよびStories製品評価では、TestGen-LLMが生成したテストケースの75%が正常にビルドされ、57%が安定して通過し、25%がカバレッジを増加させた。
• TestGen-LLMは適用されたすべてのクラスの10%を改善でき、開発者は73%のテスト改善案を受け入れて本番環境に適用した。
• MetaエンジニアがInstagramのテストカバレッジを増やすためにテストを生成する「test-a-thon」では、TestGen-LLMのテストが追加したコード行数の中央値は2.5だった。

実践的なインサイト

• LLMを使って開発生産性とソフトウェア信頼性を効率的に高められる好例。
• LLMの真の価値は、予想外のエッジケースを見つけて捉えることにある。
• LLMを本番利用するには、オーケストレーション、パイプライン、処理が必要。

TestGen-LLMの動作方式

• TestGen-LLMは、Metaの社内LLMによって生成された候補ソリューションに一連のセマンティックフィルタを適用し、最も価値の高いテストだけを保持する。
• フィルタ1: ビルド可能性、フィルタ2: 実行（テスト通過可否）、フィルタ3: 不安定さ、フィルタ4: カバレッジ改善。
• こうした処理フィルタによって、テストスイートの改善を保証する。

結論

• この論文は、多くの開発者がすでにLLMを使っている中で、ソフトウェア信頼性の領域におけるLLMの進展を追う良い方法となっている。
• LLMは今後、ますます複雑なソフトウェアシステムでバグを見つけ、テストできるようになるだろう。

GN⁺の見解

• この記事は、人工知能がソフトウェア開発の未来にどのような影響を与えうるかについて興味深い洞察を提供する。
• TestGen-LLMのようなツールは、開発者の作業を自動化し、効率性を高めるうえで大いに役立つ可能性がある。
• こうした技術の進歩は、ソフトウェア開発の複雑さを減らし、品質を向上させ、開発者の時間を節約する方向へ進んでいる。

[GN⁺]

Hacker Newsの意見

• LLM（大規模言語モデル）を使ってテストコードを書くことが、実装より優先される傾向にあるのは興味深い、という意見がある。テストはシステムがどのように動作すべきかを説明する役割を果たすため、人間が定義すべき部分だという見方がある。しかし、LLMは明示されていない領域を指摘するのに有用であり、そのような領域に対する単体テストを提案することが、LLMの適切な使い方かもしれない。
• MetaのTestGen-LLMが生成したテストケースの大半は、追加でカバーしたコードがわずか2.5行にすぎなかった一方で、ある1つのテストケースは実に1326行をカバーした、というブログ記事への批判がある。これは例外的なケースであり、ほとんどのテストケースが期待されるコードカバレッジを大きく下回っていることは論文でも明記されている。論文の著者らはこれを「ジャックポット」と表現しており、このような結果が一般的ではないことを明確にしている。
• 良いテストを書くのは難しい、という意見がある。コードカバレッジが必ずしも良いとは限らず、テストを書きすぎるとプログラムを硬直化させる可能性がある。LLMを使ってテストを再生成することは前進のように見えるかもしれないが、結局は変更検知プログラムを作っているにすぎない可能性がある。
• TestGen-LLMに関する論文の要約が、実際の内容と一致していないという指摘がある。論文の要約ではテストケースに対する成功率に言及しているが、実際の報告書が扱っているのはテストクラスに対する成功率であり、これはまったく異なる主張である。結論でもこの違いが誤って表現されている。
• LLMによって生成されたコードを保守しなければならない未来の開発者たちへの同情がある。このようなコードは管理が難しいだろうという懸念がある。
• LLMで生成されたテストコードが、開発者にとって敵対的な環境を作り出しかねないという懸念がある。管理の難しいLLM生成テストコードについて、毎回承認を求められる状況が生じるかもしれない。テスト作成は加速できるとしても、保守が必ずしも容易になるわけではない。テストはコード設計を見直すのに役立ち、テストしやすくないなら良い設計ではないかもしれない。テストは自動化された安心感を提供し、潜在的な不具合を防ぐ役割を持つが、カバレッジが高くなるほど投資対効果は低下する。LLMは、経験豊富な開発者が何をテストすべきかをすでに分かっている場合にのみ、時間を節約できる。
• GPT-4を使ってTypeScriptモジュール向けの単体テストを生成してみたところ、正常に動作するテストを作れた、という体験談がある。
• AIがどのテストを書くべきかを、どうやって知るのかという疑問がある。AIがソフトウェア開発を支援する最善の方法は、プログラマーがコードについて質問したときにAIが答えを返すことであり、そこにはコード提案が含まれることもあれば、含まれないこともある。AIは、コードを理解し、改善方法を理解する助けになるべきだ。
• AIコードに関する意見は、実際のツールを使い、よく知っているコードベースでその出力を検証したという実践的な経験がなければ、価値あるものにはなりにくい、という意見がある。AIコードは非常に政治的な話題で、多くの人が強い意見を持っている。しかし、実際に試してみたいという気持ちはある。こうした技術は開発コストが非常に高いため、AIツールが大きく改善しない限り、そのコストを正当化するのは難しいかもしれない。それでも、将来実現されることについては楽観的である。
• 論文のオーディオブック要約へのリンクが提供されている。