TestGen LLM

これをGoogle日本語翻訳で日本語訳しつつ、読んでいく。

2月に、Metaの研究者らはMetaで「大規模言語モデルを使用した自動ユニットテスト改善」と題する論文を発表し、TestGen-LLMというツールを紹介した。「既存のコードベースに対する改善が保証された」テストカバレッジを増やすための完全に自動化されたアプローチは、ソフトウェアエンジニアリングの世界に衝撃を与えた。

MetaはTestGen-LLMコードをリリースしていなかったので、オープンソースの一部として実装することにしました。カバーエージェント
3.6K
本日リリースいたします！

ここでは、これをどのように実装したかについていくつかの情報を共有し、いくつかの調査結果を共有し、実際のコードベースで TestGen-LLM を実際に使用したときに遭遇した課題の概要を説明します。

自動テスト生成: ベースライン基準

開発者が LLM を使用してテストを生成する際に陥りやすい落とし穴は、生成されたテストのほとんどが機能せず、価値を追加しないものが多いことです (たとえば、他のテストで既にカバーされている同じ機能をテストするなど)。

この課題を克服するために (具体的には、回帰ユニットテストの場合)、TestGen-LLM の作成者は次の基準を考案しました。

テストは適切にコンパイルされ、実行されますか?
テストによってコードカバレッジは増加しますか?

まず、TestGen-LLM は一連のテストを生成し、次にビルド/実行されないテストを除外して合格しないテストを削除し、最後にコードカバレッジを増加しないテストを破棄します。高度に制御されたケースでは、生成されたテストとすべてのステップに合格するテストの比率は 1:4 であり、実際のシナリオでは、Meta の著者は 1:20 の比率を報告しています。

自動化されたプロセスに続いて、Meta は人間のレビュー担当者にテストの承認または拒否を依頼しました。著者らは、平均承認率は 1:2 で、最も優れた報告例では 73% の承認率だったと報告しています。

「合計で、3 回のテストソンで 196 のテストクラスの改善に成功し、TestGen-LLM ツールは合計 1,979 のテストクラスに適用されました。そのため、TestGen-LLM は、適用されたテストクラスの約 10% を自動的に改善することができました。」

(訳者コメント)

自動生成したテストによってカバレッジが向上したかを見ていくらしい。賛否あるだろうけど、たしかに機械的に生成した場合、機械的な指標で判定したほうが無難に見える。

生成したテストは、通常のテストと同様に扱うんだろうか？カバレッジを上げるためだけの自動生成した領域として隔離しておく？

mizchi

アプローチ

Cover-Agent v0.1 は次のように実装されています。

次のユーザー入力を受け取ります。
1. テスト対象コードのソースファイル
2. 既存のテストスイートを強化する
3. 報道レポート
4. テストスイートを構築して実行するためのコマンド
5. コードカバレッジのターゲットと実行する最大反復回数
6. 追加のコンテキストとプロンプトオプション
同じスタイルでさらにテストを生成する
ランタイム環境を使用してこれらのテストを検証する
1. 彼らは構築して通過しますか?
コードカバレッジの増加などの指標を確認して、テストが価値を追加していることを確認します。
既存のテストスイートとカバレッジレポートを更新する
コードが基準に達するまで繰り返します: コードカバレッジしきい値を満たすか、最大反復回数に達するかのいずれかです。

(訳者コメント)

よくあるテスト修正フロー

mizchi

トライアル中に遭遇した特別なテスト要件と例外を確認した後、Cover-Agent フローの一部として LLM にプロンプトを出すための追加の入力や指示をユーザーが提供できるようにすることにしました。–additional-instructions オプションを使用すると、開発者はプロジェクトに固有の追加情報を提供できるため、Cover-Agent をカスタマイズできます。これらの指示は、たとえば、意味のあるエッジケースを含む豊富なテストセットを作成するように Cover-Agent を操作するために使用できます。

AI ベースのアプリケーションで Retrieval-Augmented Generation (RAG) が普及しつつあるという一般的な傾向と一致して、ユニットテスト生成に伴うコンテキストを増やすことで、テストの品質が向上し、合格率も高くなることがわかりました。テスト生成プロセスを強化するために、LLM のコンテキストとして追加のライブラリまたはテキストベースの設計ドキュメントを手動で追加したいユーザーのために、–included-files オプションを用意しました。

複数の反復を必要とする複雑なコードは、LLM にとって別の課題でした。失敗した (または付加価値のない) テストが生成されると、同じ受け入れられないテストが後の反復で繰り返し提案されるというパターンに気づき始めました。これに対処するために、プロンプトに「失敗したテスト」セクションを追加して、そのフィードバックを LLM に提供し、LLM が一意のテストを生成し、使用できないと判断されたテスト (壊れている、またはカバレッジの増加がないなど) を決して繰り返さないようにしました。

このプロセスを通じて生じたもう 1 つの課題は、既存のテストスイートを拡張するときにライブラリインポートを追加できないことです。開発者は、テスト生成プロセスにおいて近視眼的になり、テストフレームワークに対して 1 つのアプローチしか使用しないことがあります。さまざまなモックフレームワークに加えて、他のライブラリもテストカバレッジの達成に役立ちます。TestGen-LLM 論文 (および Cover-Agent) は既存のテストスイートを拡張することを目的としているため、テストクラス全体を完全に再構築する機能は範囲外です。これは、私の意見では、テスト拡張とテスト生成の制限であり、今後のイテレーションで対処する予定です。

(訳者コメント)

自分も通らないテストを何度も生成されるのに悩んでいたんだけど、通らなかったテストをプロンプトに追加して同じコードを生成しないように指示するの、だいぶ賢い

mizchi

結論

私を含め、多くの人が TestGen-LLM の論文とツールに興奮していますが、この投稿ではその限界について共有しました。私たちはまだ AI アシスタントの時代であり、完全に自動化されたワークフローを実行する AI チームメイトの時代ではないと私は考えています。

同時に、私たちがCover-Agentで開発して共有する予定の、適切に設計されたフローは、開発者がテスト候補を自動的に生成し、わずかな時間でコードカバレッジを増やすのに役立ちます。

私たちは、テスト生成ドメインに関連する最先端の方法の開発と Cover-Agent オープンソースリポジトリへの統合を継続していくつもりです。
テスト用の生成 AI に関心のある方は、ぜひ協力して Cover Agent の機能拡張にご協力ください。また、研究者がこのオープンソースツールを活用して新しいテスト生成手法を探求するよう促したいと思っています。

GitHub のオープンソース Cover-Agent リポジトリに開発ロードマップを追加しました。ロードマップに従って、または独自のアイデアに従ってリポジトリに貢献していただければ幸いです。

Cover-Agent のビジョンは、将来的にはすべての pre/post pull リクエストに対して自動的に実行され、動作が検証されコードカバレッジが増加する回帰テストの強化を自動的に提案することです。Cover-Agent がコードベースを自動的にスキャンし、テストスイートを含む PR を開くようになることを想定しています。

AI を活用して、やりたくないタスクをより効率的に処理しましょう。

AI はアシスタントであってチームメートになれない、というのは今の水準だと完全にそう。