コード生成AI時代のテスト駆動開発

生成AI時代の テスト駆動開発 XP祭り2024 Sep. 28, 2024 Takeshi Yonekubo

About Me • 米久保 剛 (よねくぼ たけし) • SIer勤務のアーキテクト • X: @tyonekubo • 『アーキテクトの教科書 価値を生むソフトウェアのアーキテクチャ構築』

アジェンダ I. テスト駆動開発の現状と課題 II. コード生成AI概論 III. コード生成AIの実験 (1) IV. コード生成AIの実験 (2)

I. テスト駆動開発の現状と課題

TDDは死んだ？ • DHH氏の記事が話題となったのが10年前 • 日本においては、生死を問うほどTDDは普及していな かったし、現状も大きくは変わっていない • いまだに「テストファースト」と「TDD」が混同して 使われがちなことや、有用性の評価以前にチャレンジ に至らないことはもったいなく感じる https://dhh.dk/2014/tdd-is-dead-long-live-testing.html

• https://dhh.dk/2014/tdd-is-dead-long-live-testing.html

テストファースト／テスト駆動開発の壁 アウトサイドイン のテスト駆動開発 テスト駆動開発 テストファースト テストコードを 書く （本日は触れない） ← 第二の壁 ← 第一の壁 サービス開発、プロダクト開発では一般的に普及 テストコードを 書かない ※必ずしも上のレベルに到達すべきという意図はなく、実践の難易度を表現した図

第一の壁：テストファースト テストを先に書かない／書けない理由： • 面倒くさい、早くプロダクションコードを書きたい • 振る舞いの単位を（事前に）識別できない

振る舞いの単位の識別 • 多くの場合、複数の小さなコンポーネントの協調に よって振る舞いが提供される • 振る舞いの単位を事前に適切に識別できないと、テス トコードを先に書くことは難しい DOC テストコード SUT DOC 振る舞い SUT (System Under Test) : テスト対象 DOC (Depended-on Component) : SUTが依存するもの DOC (Test double)

テストコードを後から書くデメリット プロダクションコードを書いた後にテストコードを書く のは、ある意味楽ではあるが、デメリットがある • テスト容易性が低くなる傾向 • エッジケース的な振る舞いに後から気づくことで、大 きな手戻りが発生するリスク

テストファースト • 大きな振る舞いを構成する小さな振る舞いの単位を識 別し、コンポーネント分割を行う事前設計が必要 • 過度な設計、オーバーエンジニアリングのリスクは内 在する 振る舞い テスト コード 振る舞い テスト コード

第二の壁：テスト駆動開発 やり方は極めてシンプル （Red – Green – Refactor） だが、実践するのはそう簡単ではない

TDDの難しさ 「シンプルなテストケースから始めて、Red-GreenRefactorのサイクルを繰り返し、少しずつ設計を進化さ せる」とは具体的にどうすれば良いのか？ • ステップバイステップで進めたからといって、良い設 計が無から出現するわけではない

仮説としての事前設計 • 解決すべき問題（＝振る舞いを実現する）に対して、 仮説としてのラフな設計はある程度行う • 人間の認知の仕組み上、無の状態から始めるのは難し く、知識や過去の経験によって構築されたスキームや メンタルモデルにより、解決策の候補は想起される • ただしそれが、目の前にある具体的な（特殊な）問題 に対する最適解である保証はない

TDDの要点 • 大きくて複雑なタスクを、十分に小さくシンプルなサ ブタスクに分割することで、知識やパターンを正しく 選択して適用できるようになる • リファクタリングによって、より良い選択に変更する チャンスがある • 仮説に固執せず、Just In Timeで柔軟な設計を行う

例）アンクルボブのボウリングスコア集計 • 『アジャイルソフトウェア開発の奥義』の 第6章「プログラミングエピソード」 • ボウリングのスコア集計アプリケーションをTDDで開 発する例

例）アンクルボブのボウリングスコア集計 TDDで生まれた設計は事前設計から大きく変わった。 “このscoreForFrame関数を見てごらんよ！ これこそボ ウリングのルールをきわめて簡潔に記述した姿だよ！”

TDDの習得方法 • ひたすら練習あるのみ • 「事前に想定していた仮の設計より、TDDの結果生ま れた設計の方がシンプルですぐれていた」という成功 体験を重ねると、TDDがデフォルトになる • TDDの呼吸を身に付ける

II. コード生成AI概論

コード生成AIは群雄割拠時代 チャットサービスやAIコードエディタなどさまざまな サービス、ツールが登場し、しのぎを削る • v0 by Vercel • Claude Artifacts • Amazon Q • GitHub Copilot • Cursor etc..

プログラマーは不要になる？

思考実験：プログラマーが不要となった未来 • ソフトウェアは完全にブラックボックス化される • 仕様書やテストの大半をAIが生成し、人が最終チェック 仕様書 ユーザー エンジニア </ テスト > ソフトウェア （Black box)

これが可能となるのは数世代先の AI（LLMではない、何か） ※LLM：大規模言語モデル（Large Language Model）

当面は続くLLM時代 ⇒LLMの仕組み、能力、限界を 把握し、LLMを最大限に活用

LLMの（ざっくりとした）理解 利用者としては、詳細なメカニズム（Attention機構や Transformer）に立ち入らず、要はLLMとはこんなもの というメンタルモデルを構築しておけばOK https://poloclub.github.io/transformer-explainer/

• https://poloclub.github.io/transformer-explainer/

LLMのメンタルモデル • LLMは「大量学習データをもとに、与えられた文章の 続きを確率的に予測し、もっともらしい文章を完成さ せるマシン」 • ランダム性を有しガチャ要素はあるが、指示の与え方 （入力する文章）を工夫することで期待する回答を得 る可能性を上げられる（＝プロンプトエンジニアリン グ）

LLMとプログラミング • LLMの学習済みデータには、大量のソースコードや技 術文書が含まれるため、LLMはプログラミングに関す る知識を豊富に持っている • メジャーな言語やフレームワークの方が多くの知識を 学習しているため、得意である • 設計や実装についても、特殊な問題よりも一般的な問 題を解く方が得意である（特殊な問題には、より高度 な推論能力が必要。OpenAI o1に期待？）

実験 Claude 3.5 Sonnet に以下の推論問題を与える。

結果：正しく推論

コード生成AI • LLMの持つプログラミング能力を活用し、ユーザーの コーディング活動を支援することを目的としたAIシス テム • 単にチャットで回答するだけでなく、自律的に行動す るAIエージェントやそれを組み込んだAIエディタを使 うことで開発生産性の向上が可能（GitHub Copilot や Cursor） • とくにCursorは開発者体験が格段に優れている

III. コード生成AIの実験 (1)

実験の趣旨 • 「コード生成AIでXXアプリが一発で作成できた！」 →ガチャを引き続ければそれなりのものは生成できる • 一方で、正規表現やらシンプルな関数などは、LLMの 能力的にできて当たり前 われわれの関心事は「複雑なプログラムを、プロダク ション環境にデプロイ可能なレベルの品質で作ることが、 コード生成AIによってどの程度できるのか」 および「そのための具体的な手法、テクニック」 →ある程度複雑な題材で実験してみた具体例を紹介 ※以降の実験は全てCursor (Pro) + Claude 3.5 Sonnetを利用して行った

題材(1) each関数 • Jestでパラメーター化テストの記述に利用する、 test.each関数を模した関数を作成する • JavaScriptのタグ付きテンプレートリテラルを利用

試行1 テストファースト〜一発生成（NG） • テストスイートを示 し、全てをパスする コードの実装を指示 • 数回ガチャを回した が、一発で正解を出 すことはできなかっ た • 問題が複雑過ぎるた めに分解が必要と推 測

試行2 テスト駆動開発 デモ動画

考察 • 人間がテストコードを書き、AIがそれをパスする実装 コードを書くピンポンプログラミングによるTDDはう まくいった • 一発で正解を導くことができなかった複雑な問題に対 しても、分割して段階的に取り組むことで正解を導く ことができた • 段階的に進めることで、AIが生成したコードの理解や レビューもしやすくなる（必要に応じてリファクタリ ングのステップも盛り込むことも可能）

IV. コード生成AIの実験 (2)

題材(2) コード行数カウンター • ディレクトリ配下のソースコードの行数をカウントす るJavaScriptのCUIプログラムの生成 • 言語ごとにコード行数、コメント行数、空行数、トー タル行数をカウントして表形式で結果を出力する

プログラム仕様書 • 仕様書はマークダウン形 式で記述し、AIにファイ ル参照させる

Cursor Composer • 複数のファイルをまとめて生成したり、編集したりす ることができる機能 • Beta版機能（Pro以上で有効化することで利用可能）

試行1 一発生成 • 一発で動作するコードが生成される場合と、うまくい かない場合とがあった • 動作しない場合は修正を試みるよりやり直した方が早 い（ガチャ）

試行2 部品化＆テストコード生成 • 保守性、テスト容易性を考慮したプログラム分割と、 テストコード生成を指示

試行2 部品化＆テストコード生成 • プログラムは正しく動作したものの、テストコードは 失敗する状態

試行2 部品化＆テストコード生成 • Debug with AI機能で修正を試みるもうまくいかず • モックの多用によりテストコード読解が困難で、マ ニュアルでの修正も諦めた

試行3 部品化＆テストコード改善 • テスト容易性に関する具体的な制約を追加 • 「テストコードでスタブやモックを多用しなくて済む ように設計する」

試行3 部品化＆テストコード改善 • プログラムは正しく動作し、テストも全てパス

試行3 部品化＆テストコード改善 試行2で生成されたコードとの比較： • 個々の関数内で設定ファイルを読み込むのではなく、 読み込んだ設定内容をメイン関数から引数で渡すよう になった • ディレクトリやファイルへのアクセスは、引き続き モックによる検証となっていた 全体的には、コードの質はさほど改善されなかった。

試行4 テストファースト • 段階的な実装を指示（個々の関数は空実装から開始）

試行4 テストファースト • データの流れと処理を説明させるステップを追加 →具体例を、LLMに入力するコンテキストに含めるこ とで精度を上げる狙い

試行4 テストファースト • 個々の関数毎に、必要なテストケースを検討させ、実 際にテストコードを生成させる

試行4 テストファースト • テストコードをパスする関数の実装を指示する • この手順を、関数の数だけ繰り返す

試行4 テストファースト • テストが失敗する場合もあるが、処理が小さく分割さ れておりコードの可読性も高いため、「Debug with AI」機能で比較的容易に修正できた

試行4 テストファースト • 正しく動作するプログラムが完成し、テストケース数 も増加した

各試行の比較 試行1 一発生成 試行2 部品化＆テスト 試行3 部品化＆テスト改 試行4 テストファースト プロダクション コードの可読性 低い 普通 普通 普通 テストケース数 N/A 3ケース 5ケース 23ケース テストコードの可 読性 N/A 低い 普通 高い （モック未使用） ※可読性の判定は筆者の主観による ※実際のコードはGitHubリポジトリを参照 https://github.com/yonetty/xp-matsuri-gen-ai-tdd

• https://github.com/yonetty/xp-matsuri-gen-ai-tdd

考察 N=1ではあるが、実験結果から以下の仮説を持っており、 体感としてはおそらく間違ってはいない • 複雑なプログラムを一発で生成させることはガチャ要 素が大きい上、コードの品質も安定しないので避けた 方がよい（使い捨てのスクリプトや、プロトタイプの ような用途ならOK） • 処理を分割した上で、個々にテストファーストで進め た方が、テストコード、プロダクションコードともに 内部品質は向上する

まとめ

①分割統治の有効性 人間であれ生成AI（LLM）であれ、 複雑な問題をシンプルで小さな問題に 分割することで、一般解としての知識 やパターン適用をしやすくなる。

②生成AIエンジニアリング 実務で生成AIを活用するならば、 ガチャとならないようにLLMの特性を 把握してエンジニアリングを行う。 生成AIを用いる場合でも、テストファー ストやテスト駆動開発の手法は有効。

③副操縦士としての生成AI 開発するプログラムの複雑度やその他の 特性に応じて、人間の介在度合いを制御 する。現時点では、完全に生成AIに任せ ることは難しく、Copilot（副操縦士）の 役割が妥当である。

ご拝聴ありがとうございました fin