AIが書いたコードを検収する仕組みをつくる書籍ガイド｜テスト技法・単体テスト・TDD・自動化の4冊

コーディングエージェントに任せる範囲が広がると、レビューの前提が静かに壊れます。人間が全部のコードを読んで、意図どおりかを目視で確かめる。この検収のやり方は、書かれる量が人間の読める量を超えた時点で成立しなくなります。読める量を増やす方向の改善には限界があるので、残る道は「読まなくても壊れたと分かる状態」を作ることです。それが自動テストで、いま急に必要になった技術ではなく、書く量が増えたぶん不足が露呈しやすくなった技術だと言うほうが正確です。この記事では、自動テストを学び直すための実在の日本語書籍を4冊、段階順に紹介します。可読性や設計、バージョン管理は別記事に譲り、ここでは主題を「動作を保証する仕組み」に絞ります。なお本記事は書籍紹介であり広告を含みます。価格・版・在庫・目次は変わるため、最新は各公式・書誌ページでご確認ください。

読む検収から、動かす検収へ#

まず何が起きているかを具体的にします。エージェントに実装を任せているチームで、テスト側に出てくる症状はだいたい次の5つです。

• 差分を全部は読んでいない。数百行の変更に対して、目立つ箇所と動作確認だけで通している。読んでいないという自覚があるぶん、マージのたびに不安が残る
• 壊れたことに後から気づく。手元では動いたが、別の入力や別の環境で落ちる。気づくのは誰かが困ったときで、原因の変更を特定するのに時間がかかる
• テストはあるが信用していない。落ちても「たぶんテスト側が古い」と判断され、期待値のほうが書き換えられる。落ちること自体が情報にならなくなっている
• テストがリファクタリングを止める。内部実装に密着したテストが大量にあり、構造を変えるたびに大量に壊れる。結果として、直すべき設計に手を入れられない
• カバレッジは高いのにバグが出る。数値は伸びているが、assertが緩い、あるいは境界値を通っていないため、実質的には何も保証していない

この5つは、どれもモデルを乗り換えるだけでは解決しません。効くのは、テストの観点を出す技法、どのテストに価値があるかを判断する基準、テストと実装を書く順番、そしてそれを継続的に回す運用です。いずれも変化の緩やかな領域で、一度身につけると長く使えます。

症状から、読む本を決める#

テスト関連の書籍は同じ棚に並んでいても、想定読者と踏み込む深さがかなり違います。テスト技法の本と単体テスト設計の本と自動化運用の本は、扱っている問題がほとんど重なりません。まず自分の症状がどの段階にあるかを決めてから選ぶと、読み違いが減ります。

症状と、効く技能と、対応する段階#

以下、この順で4冊を紹介します。守備範囲はそれぞれ違い、全部を通読する前提ではありません。

1. テストの観点を出す型を作る(ソフトウェアテスト技法練習帳)#

1冊目は、テスト技法を問題演習で身につける練習帳です。梅津正洋さん、竹内亜未さん、伊藤由貴さん、浦山さつきさん、佐々木千絵美さん、高橋理さん、武田春恵さん、根本紀之さん、藤沢耕助さん、真鍋俊之さん、山岡悠さん、吉田直史さんの共著で、技術評論社から2020年1月に刊行されました。B5判216ページ。副題は「知識を経験に変える40問」です。書誌ページの概要には、座学で学んだテスト技法を実務にどう適用すればよいか分からないという悩みに対して、実践的なシチュエーションを想定した問題を繰り返し解くことで知識の定着を目指す、と書かれています。想定読者は新人のテストエンジニアや、学んだ技法を実践する場がないテストエンジニアです。

目次はPart1からPart5の5部構成で、Part1が同値分割法と境界値分析、Part2がデシジョンテーブル、Part3が状態遷移テスト、Part4が組合せテスト、Part5が総合問題です。中身は一貫して問題で、たとえばPart1には「温度によって表示を変えるペット用室温計」「キッチンスケールの動作検証」「年齢によって変わる入園料金」「配達便の料金体系」といった題目が並びます。Part4には「タスク管理ツールの検証～ラルフチャートの利用」という項目もあります。

エージェントを使う立場から見ると、この段が効くのは「AIに投げる前の仕様の解像度」を上げる部分です。エージェントは「この関数のテストを書いて」と言えばテストを書きますが、境界がどこにあるか、状態遷移のどの経路が抜けているかは、仕様を読んだ人間しか判断できません。逆に、観点さえこちらで出せるなら、それを埋めるコードを書く作業はエージェントの得意分野です。観点は人間、記述はAI、という分担にすると、テストの質がいちばん安定します。

扱っていない範囲も書いておきます。公開されている目次を見る限り、本書はテストケースを設計する演習に集中しており、テストコードの書き方、テストフレームワークの使い方、CIでの実行といった自動化の話題は章として置かれていません。技法の理論を体系的に解説する教科書というより、手を動かして定着させるための問題集という位置づけです。理論の解説を厚く求める場合は、別の入門書と併読するほうが向いています。

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～(技術評論社)

広告

著者: 梅津正洋ほか12名 / 出版社: 技術評論社 / 2020年1月刊 / B5判216ページ。同値分割法と境界値分析、デシジョンテーブル、状態遷移テスト、組合せテスト、総合問題の5部構成で、実践的なシチュエーションの問題を解きながらテスト技法を定着させます。テストコードの書き方や自動化・CIの運用は目次にありません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

2. どのテストに価値があるかを判断する(単体テストの考え方/使い方)#

2冊目は、単体テストの原則と実践パターンを扱う一冊です。Vladimir Khorikovさん著、須田智之さん訳で、マイナビ出版から2022年12月に刊行されました。B5変416ページ。原書はManningの「Unit Testing: Principles, Practices, and Patterns」です。版元の内容紹介には、単体テストと統合テストの定義を明確にしたうえで、どのようなテストに価値があるのかを学び、どのテストをリファクタリングし、もしくは削除するのかを考える、と書かれています。コード例はC#ですが、どの言語にも適用できる内容だと明記されています。

目次は4部11章です。第1部が単体テストとは何かで、第3章が「単体テストの構造的解析」。第2部が単体テストとその価値で、第4章「良い単体テストを構成する4本の柱」、第5章「モックの利用とテストの壊れやすさ」、第6章「単体テストの3つの手法」、第7章「単体テストの価値を高めるリファクタリング」。第3部が統合テストで、第9章「モックのベスト・プラクティス」、第10章「データベースに対するテスト」。第4部が第11章「単体テストのアンチ・パターン」です。

AIに書かせる前提だと、この本の第5章と第9章の重みが上がります。エージェントにテストを書かせると、依存を片端からモックに置き換えた、通ることだけが保証された形になりがちです。そのテストは、実装の内部構造を写し取っているので、リファクタリングのたびに壊れます。壊れるたびに直す作業が発生し、やがて「テストがあるから設計を変えられない」という逆転が起きます。何をモックしてよくて何をモックすべきでないかに基準を持てるかどうかは、テストの本数よりはるかに効きます。同じ方向の指針は、E2Eの領域でも共有されています。Playwrightの公式ドキュメントは、自動テストはエンドユーザーにとってアプリケーションが動くことを検証すべきで、関数名やデータ構造、CSSクラスといった実装の詳細に依存することは避けるべきだと述べ、リファクタリングに耐えるテストを推奨しています。

扱っていない範囲も整理しておきます。本書は単体テストと統合テストの設計に主眼があり、目次を見る限り、テスト技法の演習(同値分割や状態遷移の洗い出し)、E2Eテストの導入手順、CIの構築といった話題は章として置かれていません。またコード例はC#なので、他言語の読者は書き換えながら読む必要があります。理屈の密度が高く、416ページを一気に読むのはしんどいので、第4章から第7章だけ先に読むという入り方でも十分に元は取れます。

単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略(マイナビ出版)

広告

著: Vladimir Khorikov / 訳: 須田智之 / 出版社: マイナビ出版 / 2022年12月刊 / B5変416ページ。原書はManningのUnit Testing: Principles, Practices, and Patterns。良い単体テストを構成する柱、モックの利用とテストの壊れやすさ、統合テストとの境界、アンチ・パターンまでを扱います。テスト技法の演習やE2Eの導入手順、CIの構築は目次にありません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

コード生成AIとの日々の付き合い方そのものは、別記事で整理しています。

3. 先にテストを書く進め方を体で覚える(テスト駆動開発)#

3冊目は、テスト駆動開発の原典です。Kent Beckさん著、和田卓人さん訳で、オーム社から2017年10月に刊行されました。A5判344ページ。原書は「Test-Driven Development By Example」です。版元の紹介には、テスト駆動開発とは単にテスト自動化を行うことではなく、ユニットテストとリファクタリングを両輪とした小さいサイクルを回すことで不確実性を制御し、不断の設計進化を可能にする手法である、と書かれています。

目次は3部構成です。第I部「多国通貨」が第1章から第17章までで、実例を通してサイクルを追体験する部分。章タイトルは「仮実装」「明白な実装」「三角測量」「意図を語るテスト」「テスト不足に気づいたら」「疑念をテストに翻訳する」「歩幅の調整」「テストに聞いてみる」「不要になったら消す」「実装を導くテスト」「将来の読み手を考えたテスト」といった具合で、進め方そのものが章名になっています。第II部「xUnit」が第18章から第24章で、テスティングフレームワーク自体をテスト駆動で作ります。第III部「テスト駆動開発のパターン」が第25章から第32章で、レッドバーのパターン、グリーンバーのパターン、リファクタリング、TDDを身につける、と続きます。付録Cには訳者による「テスト駆動開発の現在」が収録されています。

エージェント運用でこの本が効くのは、順番の意味を体で理解できる点です。テストを後から書くと、テストは実装の写しになります。実装が間違っていれば、テストも同じように間違います。エージェントに「テストも書いて」と一度に頼むと、この失敗の形がそのまま出ます。先に失敗するテストを用意し、それが確かに失敗することを人間が確認してから実装に進むと、少なくとも「テストが何も検証していない」状態は避けられます。第4章「意図を語るテスト」や第16章「将来の読み手を考えたテスト」は、テストを仕様の記述として扱う視点で、AIが量産したテストを人間が後から読むときにも効きます。

扱っていない範囲は、現代の周辺環境です。2017年の刊行で、原書は2002年です。CIサービス、E2Eツール、モックライブラリの現在の選択肢、Webアプリケーション特有の話題は本書の範囲外です。本書は手順書ではなく、進め方の考え方を得るために読む本だと割り切ったほうが、得られるものが多くなります。実行の詳細は、使っている言語のテストフレームワークの公式ドキュメント(たとえばPythonならpytest)で補ってください。

テスト駆動開発(オーム社)

広告

著: Kent Beck / 訳: 和田卓人 / 出版社: オーム社 / 2017年10月刊 / A5判344ページ。原書はTest-Driven Development By Example。第I部で実例を通してサイクルを追体験し、第II部でテスティングフレームワーク自体をテスト駆動で作り、第III部でパターンを整理します。付録に訳者解説「テスト駆動開発の現在」を収録。CIやE2E、現代のツール選択は扱っていません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

4. 継続的に回す運用にする(テスト自動化実践ガイド)#

4冊目は、Webアプリケーションに自動テストを導入し、継続的に改善していくための実践書です。末村拓也さん著、翔泳社から2024年7月に刊行されました。B5変352ページ。版元の紹介では、テスト担当者や開発者が自身のプロジェクトにスムーズに自動テストを導入できるようにするガイドブックであり、「なぜ自動化が必要なのか」という目的の理解に重きを置いている、と説明されています。

目次は3部12章です。第1部「自動テストに取り組む前に」は第1章「テストの目的」、第2章「開発を支える自動テスト」、第3章「見つけたいバグを明確にする」、第4章「E2Eテストとは何か」。第2部「アプリケーションにE2Eテストを導入する」は第5章のセットアップから、第6章「最小限のテストをデプロイする」、第7章「ビジネスプロセスをカバーするテストを作成する」、第8章「ユーザーストーリーをカバーするテストを作成する」、第9章「テストコードに意図を込める」まで。第3部「自動テストを改善するテクニック」は第10章「トラブルシューティング」、第11章「もっと幅広くE2Eテストを使う」、第12章「成果を振り返る」です。ハンズオンの実装手段にはCodeceptJSとPlaywrightが使われていますが、版元ページでは特定のフレームワークでのみ適用可能な手法ではなく、汎用的なテクニックを紹介していると説明されています。

AIにコードを書かせる運用では、この段が実質的な検収装置になります。人間のレビューは差分が増えるほど密度が下がりますが、テストの実行回数は増えても質が落ちません。ただし、自動テストは置いた瞬間に価値が出るものではなく、落ちたときに原因を切り分けられること、不安定なテストを放置しないこと、実行時間が現実的であることが揃って初めて信頼されます。第10章「トラブルシューティング」や第12章「成果を振り返る」に紙幅が割かれているのは、そこが実際の詰まりどころだからです。第3章「見つけたいバグを明確にする」は、この記事の文脈でとくに重要です。何を見つけたいか決めずに自動化すると、AIが増やしたテストの本数だけが増えて、見つけたいバグは通り抜けます。

扱っていない範囲は、単体テストの設計理論とテスト技法の演習です。本書はE2Eを軸にした自動テストの導入と運用が主題なので、モックの使い分けや単体テストの価値判断は2冊目、観点の洗い出しは1冊目が担当します。またCIの構築そのもの(ワークフローの設計やブランチ保護)は別領域で、そちらはバージョン管理と自動化の記事で扱っています。

テスト自動化実践ガイド 継続的にWebアプリケーションを改善するための知識と技法(翔泳社)

広告

著者: 末村拓也 / 出版社: 翔泳社 / 2024年7月刊 / B5変352ページ。テストの目的と見つけたいバグの明確化から、E2Eテストの導入、意図を込めたテストコード、トラブルシューティング、成果の振り返りまでを扱います。ハンズオンはCodeceptJSとPlaywrightを使用。単体テストの設計理論やテスト技法の演習、CIワークフローの構築は扱っていません。

Amazonで見る楽天で見るYahoo!ショッピングで見る

※価格・在庫は変動します。最新の情報は各販売サイトでご確認ください。

テストを回す土台としてのバージョン管理と自動チェックの運用は、別記事にまとめています。

4冊の使い分け#

役割と、いま出ている症状から選ぶための対応表です。刊行時期は、ツールや画面の説明が現行とどれくらいずれる可能性があるかの目安になります。

読む順序としては、いま止まっている場所から1冊だけ選ぶのが現実的です。4冊を順に通読する計画は、たいてい2冊目で止まります。あえて順序をつけるなら、テストがまだほとんどない現場は4冊目から入って「壊れたら気づける」状態を先に作り、テストはあるが信用されていない現場は2冊目から入るのが早いはずです。

AIにテストを書かせるときに起きること#

テストもAIに書かせられるなら、検収の問題は自動的に解決するのではないか。実際にやってみると、そう単純ではありません。起きやすい空洞化のパターンを3つ挙げます。

テストが実装に追従するだけになる#

実装を書いてからテストを書かせると、テストは実装の写しになります。実装が仕様を取り違えていれば、テストも同じ取り違えを固定します。この状態のテストは、リグレッションの検知には効きますが、仕様との一致は何も保証しません。さらに悪いのは、テストが落ちたときに実装ではなく期待値のほうを直させてしまう運用です。Claude Codeの公式ドキュメントには「Work with tests」という節があり、未カバーの関数を探す、テストの雛形を生成する、エッジケースのテストを追加する、実行して失敗を直す、というレシピが並んでいます。同ドキュメントは、テストを頼むときは検証したい振る舞いを具体的に伝えること、Claudeは既存のテストファイルを読んでスタイルや使用中のフレームワーク、アサーションのパターンに合わせることを述べています。裏を返せば、検証したい振る舞いを言語化する部分は依頼者に残っている、ということです。

対策は単純で、テストの生成と実装の生成を同じ一手にしないことです。先にテストだけを書かせ、それが確かに失敗することを確認してから実装に進む。テストファイルの変更と実装ファイルの変更は別コミットにする。期待値を変える提案は、理由込みで説明させてから承認する。TDDの本が扱っているのは、まさにこの順番の話です。

モックが増えすぎて、リファクタリングできなくなる#

エージェントは「通るテスト」を最短で作ろうとするため、外部依存を片端からモックに置き換える傾向があります。結果として、テストは実装の内部構造に密着します。内部構造が変われば全部落ちるので、落ちたテストを直す作業が定常業務になり、やがて設計を変えること自体が避けられるようになります。モックの使いどころに基準を持つこと、そしてテストは実装の詳細ではなくユーザーに見える振る舞いを対象にすること。この2つは、単体テストの本とPlaywrightの公式ドキュメントの両方が同じ方向を指しています。

カバレッジの数値が目標になる#

いちばん起きやすいのがこれです。カバレッジを目標値にすると、エージェントは確実に達成します。ただし達成のされ方が問題で、実行はされるがアサートが緩いテストや、同じ経路を通るだけのテストが量産されます。Martin Fowlerさんは「Test Coverage」で、特定のカバレッジ水準を目標にすれば人はそれを達成しようとするが、高いカバレッジ数値は低品質なテストでも容易に到達できると書いています。同記事は、思慮深くテストしていればカバレッジは80台後半から90台になると予想する一方で、100%のような数値はテストの数値を満たすために書かれている疑いがあるとし、カバレッジの価値は「コードのどの部分がテストされていないかを見つけること」にあると位置づけています。

Google Testing Blogの「Code Coverage Best Practices」も同様の整理をしています。カバレッジはテスト品質の完全な指標ではないが、客観的で行動につながる指標ではある。ただし高いカバレッジ率がテストの品質を保証するわけではなく、100%に近づけることに集中すると誤った安心感を生み、維持が必要な低価値のテストという技術的負債を作りうる。カバレッジが保証するのは、その行が正しくテストされたことではなく、テストによって実行されたことだけである。同記事は、カバレッジ値を上げるためだけにテストをコピー&ペーストすることを戒め、テストが行を十分に検証しアサートできているかを評価するより良い手法としてミューテーションテストを挙げています。目安としてGoogleは60%を「acceptable」、75%を「commendable」、90%を「exemplary」という一般的なガイドラインを示していますが、あらゆるチームに一律のパーセンテージを課すことはできず、これは製品のオーナーがドメイン知識に基づいて行うビジネス判断だとも書いています。

ミューテーションテストは、コードにわざと小さな変更(演算子の反転など)を加え、テストがそれを検知できるかを測る手法です。JavaならPIT、JavaScriptやTypeScriptなどではStryker Mutatorといったツールがあります。全コードベースに常時かけるものではありませんが、AIに量産させたテスト群に対して一度かけてみると、どのテストが実質的に何も検証していないかが分かります。

LLMの出力そのものを評価する話は、コードの自動テストとは別の設計が要ります。混同しやすいので、そちらは別記事で扱っています。

本記事に記載した書名・著者・訳者・出版社・刊行時期・ページ数・判型・目次は、各出版社の公式書誌ページ(frontmatterのsources)で確認できた範囲の情報です。版・価格・在庫・目次は改定されるため、購入前に各公式ページで最新情報をご確認ください。各書籍の「扱っていない範囲」は、公開されている目次と出版社の内容紹介から判断できる範囲の整理であり、本文全体を網羅的に検証したものではありません。カバレッジやミューテーションテストに関する記述は、各出典の公開時点の内容に基づきます。

明日の運用に落とす最初の一歩#

本を読み終えてから運用を作り直そうとすると、たいてい着手できません。いま動いているリポジトリに、小さく順番に足していくほうが現実的です。

この順序は、4冊が扱う内容をエージェント運用の文脈に置き換えたものです。2は技法練習帳、3と4はテスト駆動開発、5と6は単体テストと自動化の本が対応します。逆に言えば、どの手順で手が止まったかで、読むべき本が決まります。

人間がどこで確認を挟むかという設計そのものは、テストの話と地続きです。この点は別記事で扱っています。

よくある質問#

まとめ#

エージェントを入れて速くならないチームは、書く速度ではなく検収でつまずいていることが多いはずです。人間が読む量は増やせません。増やせるのはテストの本数と実行回数のほうで、だからこそ「何をテストするか」を決める力が、いままで以上に効きます。

今回紹介した4冊は守備範囲が違います。観点を洗い出す練習帳、どのテストに価値があるかを判断する本、テストと実装を書く順番を体得する本、そして自動テストを継続して回す運用の本。いずれも「これ1冊でAI時代の開発が回る」種類の本ではなく、自分がどこで止まっているかを明確にしてくれる本です。まずは症状に対応する1冊を選び、次のタスクで観点を先に書き出すところ、あるいは壊れたら困る経路を1本だけ自動化するところから始めてみてください。読まずに済ませられる範囲が増えた分だけ、エージェントに任せられる範囲も広がります。