エージェントに「テスト技法を使え」と指示しても、品質は向上しない——Dan Luu氏の実証実験

私の経験では、エージェントはユニットテストを書く際に、人間よりも多くのエッジケースを考えることがよくあります。しかし、特定のスキルの指示に従うと、機械的になり、ビジネスロジックを見失うことがあります。

例えば、Superpowersスキルセットを使うと、エージェントは新しい機能ごとに積極的にTDDを採用します。しかし、テストに対する理解は表面的なままであることが多いです。ユーザーが「送信」ボタンがある画面を要求した場合、まずボタンが存在するかどうかをチェックするテストを書き、そのテストが失敗するので、ボタンを追加してパスさせます。

その結果、テストスイートはプロパティが存在するか、文字列が完全に一致するかをチェックするような、価値の低いケースで埋め尽くされます。エージェントは「失敗するテストを書いてから機能を実装する」というワークフローに従いますが、ビジネス上の振る舞いを実際にテストすることはありません。送信はいつ許可されるべきか？成功または失敗の後には何が起こるべきか？重複送信はどのように処理されるべきか？

問題は、エージェントがテストを書けないことではありません。TDDを硬直した一連のステップに還元しがちで、ビジネス要件から意味のあるテストケースを自律的に導き出し、それを開発の推進に使うことに苦労していることです。

まだ初期段階ですが、この実験はほとんど意味がなく、ほとんど役に立たないと感じています。

コードのテスト方法は、コード自体のアーキテクチャ方法から切り離すことはできません（また、切り離すべきではありません）。効果的なテストの80%以上は、テストフレームワークではなく、コードアーキテクチャにあります。

著者は、コードがどのようにアーキテクチャされ、管理されているかについて言及していません。

私の経験では、エージェントにDI/ヘキサゴナルアーキテクチャを強制し、些細なカバレッジチェックを強制することは非常に有用であり、比較的少ない労力で全体的に十分なコードを生成できます。

これは私が行ったどのテストよりもはるかに徹底しており、まったく異なる分野ですが、Hypothesisをエージェントに使わせた私の逸話的な経験はかなり悪いものでした。

エージェントは、コードとそれがモデル化すべき実際のビジネスルールとの間のギャップを埋めるのに本当に苦労しました。また、どのレイヤーのどの関数に対してテストを書くのが適切かを判断するのにも苦労しました。そのため、そのテストはドメインロジックの変更に対して非常に脆弱になる傾向がありました。

基本的に、エージェントはモジュール性と問題の分解に常に苦労しているように見えます。優れたテストとは、テストすべき適切なものを見つけることであり、それは入力状態を適切な積状態に分割し、各振る舞いを独立してチェックする方法を考えることを意味します。私の意見では、これはプログラミングの中で最も難しく複雑なことなので、人間よりも苦労したとは言いませんが、人間には一晩寝て考えるという利点があります。

観察した小さな点として、浮動小数点のエッジケース（NaN、無限大）に非常にこだわる傾向がありました。おそらく、プロパティベーステストのトレーニングデータでは浮動小数点のエッジケースが過剰に表現されているのでしょうが、少なくともビジネスルールに関しては、私のユースケースでは本質的に無関係です。

エージェントは、自分が得意なことは苦手で、苦手なことは得意だと誰もが思っているのをご存知ですか？結局、私はテストが苦手なんだと思います。なぜなら、彼らはかなり良い仕事をしていると思ったからです。