Claude Codeでテストを書かせる実践手順
Claude Codeに既存コードのテストを書かせる手順を、カバレッジの薄い箇所の特定からエッジケースの追加、実行して直すところまでまとめます。
Claude Codeに既存コードのテストを書かせるとき、精度を左右するのは指示の細かさより順番です。カバレッジの薄い箇所を特定させ、既存のテストパターンに沿った雛形を作らせ、そのあとでエッジケースを積み増す。この順で進めると、書きっぱなしで終わらず実行して直すところまで一気通貫で回せます。
Claude Codeにテストを書かせるとはどういう作業か
ここで扱うのは、すでに動いているコードに後からテストを足す作業です。実装より先にテストを置くテスト駆動開発とは狙いが異なります。テスト駆動開発は「これから作る仕様」を先に固定するのに対し、こちらは「いま動いている挙動」をテストの形で記録します。テスト駆動開発の型そのものはClaude Codeでテスト駆動開発を回す手順にまとめているので、本稿では既存コードへの後付けに絞ります。
Claude Codeはこの作業を任せると、既存のテストファイルを読んでスタイル・フレームワーク・アサーションの書き方を確認したうえでテストを書きます。指示する側が「何を確認したいか」を具体的に伝えるほど、生成されるテストの粒度が安定します。逆に「テストを増やして」とだけ伝えると、対象の絞り込みから優先順位付けまでをClaude Code任せにすることになり、本当に必要な箇所が後回しになることがあります。
始める前に確認すること
着手前に2つだけ確認しておきます。1つは、テストを1コマンドで実行できることです。npm testでもpytest -qでも構いませんが、引数なしで走って終了コードを返す形にしておきます。Claude Codeはこのコマンドを何度も叩いて合否を読むため、手順が複数ステップに分かれていると、そのたびに判断が挟まり精度が落ちます。
もう1つは、Bashコマンドの実行許可です。テストの実行もテストファイルの編集も、既定では都度許可の確認が入ります。何度も同じ確認が出て流れを止めるようなら、Bash(npm test:*)のように対象コマンドを絞って許可リストに追加しておくと、以降は確認なしでテストを実行させられます。
手順1: カバレッジの薄い箇所を特定する
最初に、どこにテストが無いかをClaude Code自身に洗い出させます。ファイル名を1つ指定して聞くと、対象範囲が絞られて回答が具体的になります。
NotificationsService.swiftでテストされていない関数を見つけて対象がファイル単位で分からない場合は、機能名やモジュール名で聞いても構いません。ただし対象が広すぎると調査だけでコンテキストを消費するため、最初は1ファイルか1モジュールに絞るのが安全です。複数の対象を並行して洗い出したいときは、対象ごとに質問を分けて実行し、結果を都度確認してから次に進みます。
手順2: 既存パターンに沿った雛形を作らせる
対象が定まったら、テストの雛形をClaude Codeに生成させます。ここでClaude Codeは既存のテストファイルを読み、同じフレームワーク・同じアサーションの書き方に合わせてコードを書きます。プロジェクトに既存のテストが1つもない場合は、先にフレームワークとアサーションの方針を指示してから任せます。
通知サービスのテストを追加してこの段階で生成されるのは、正常系を中心にした最初の一群です。ここで満足せず、次の手順でエッジケースを足すところまでを1セットの作業として扱います。生成された雛形をひと通り眺め、意図と違うアサーションが混ざっていないかをここで確認しておくと、後段の修正が減ります。
手順3: エッジケースを追加させる
正常系だけのテストは、リファクタリング時の安全網としては不十分です。境界値・異常系・想定外の入力といった、書く側が見落としやすいケースを追加で聞き出します。
通知サービスのエッジケースのテストケースを追加してClaude Codeはコードのパス(条件分岐や早期returnの箇所)を解析し、エラー条件・境界値・想定外の入力に対するテストを提案します。人間が実装するときに見落としがちな分岐ほど、この段階で拾える価値が大きくなります。「エッジケースを追加して」だけでなく、「nullが渡された場合」「タイムアウトした場合」のように具体例を添えると、狙った分岐を確実に拾わせられます。
手順4: テストを実行して失敗を直させる
テストを書かせたら、必ず実行させて結果を読ませます。書いた本人に実行と修正まで任せることで、構文エラーやアサーションのずれをその場で潰せます。
新しく追加したテストを実行して、失敗があれば直してここで失敗が残る場合、原因はテストコード側の書き間違いのこともあれば、テストが本物のバグを検出したというケースもあります。後者であれば、テストを直すのではなく実装側の修正が必要かどうかを確認してから進めます。この切り分けを飛ばしてテストを実装に合わせて直してしまうと、バグを隠すだけのテストになってしまいます。判断に迷ったら、その関数が本来どう動くべきかを人間の言葉で確認してから、テストと実装のどちらを直すかを決めます。
よくあるつまずき
テストファイルが1つも無い状態から始めると方針がぶれる。参照できる既存パターンが無いため、フレームワークの選定やアサーションの書き方を毎回聞き直すことになります。最初の数本は人間が方針を決めて書き、以降をClaude Codeに引き継ぐほうが安定します。
「テストを追加して」とだけ伝えると正常系に寄る。手順2と手順3を分けずに1回の指示で済ませると、エッジケースが抜けやすくなります。雛形とエッジケースは別ターンで指示し、それぞれの結果を確認してから次に進みます。
カバレッジ計測ツールが無いプロジェクトでは「薄い箇所」の判定が曖昧になる。手順1の「テストされていない関数を見つけて」は静的な読み取りに頼っているため、実行時のパスカバレッジまでは保証しません。カバレッジレポートを出力できる環境なら、レポートのファイルパスを渡して優先順位をつけさせるとより正確です。
大きなモジュールをまとめて対象にすると、コンテキストが混みあって精度が落ちる。調査対象が広いと感じたら、サブエージェントに調査だけを委任する方法もあります。カバレッジの棚卸しをサブエージェントに任せ、実装のメインセッションには結果だけを持ち帰らせると、会話が汚れません。
既存コードにテストが無い理由が「壊れやすいから」であることもある。密結合していて1つの関数を差し替えるだけで広範囲に影響が及ぶようなコードは、テストを書く前にまず構造をほぐす必要があります。テストを足す前に軽くリファクタリングが必要なケースでは、テストが無いコードのリファクタリング手順を先に踏んでから本稿の手順に戻るほうが安全です。
よくある質問
テストの粒度はどこまで細かく指示すべきですか
最初は「通知サービスのテストを追加して」のように大まかな粒度で任せ、生成結果を見てから「タイムアウト時の挙動もテストに含めて」のように具体化するほうが効率的です。最初から粒度を細かく指定しすぎると、指示していないケースが抜け落ちやすくなります。
モックやスタブの扱いはどう指示すればいいですか
既存のテストファイルにモックの使い方があれば、Claude Codeはそのパターンを踏襲します。プロジェクトに前例が無い場合は、「外部APIの呼び出しはモックに置き換えて」のように扱い方を明示しておくと、実際にネットワークへ到達するテストが混ざるのを防げます。
生成されたテストが多すぎて読み切れません
1回の指示で複数のファイルにまたがるテストを一気に生成させると、レビューの負荷が上がります。ファイル単位、または関数単位で対象を区切り、都度実行と確認を挟みながら進めると、生成量とレビュー量のバランスが取りやすくなります。
テストカバレッジは何%を目指せばいいですか
数値目標を決めてClaude Codeに丸投げすると、意味の薄いテストで数値だけを埋める結果になりがちです。カバレッジ率そのものを目的にせず、「壊れたら困る挙動から優先してテストする」という基準で対象を選ぶほうが、後々の安全網として機能します。
統合テストとユニットテストのどちらを書かせるべきですか
対象の粒度による部分が大きいですが、まず個々の関数やメソッド単位のユニットテストから始めると、失敗時の原因特定が早くなります。複数のモジュールをまたぐ処理は、ユニットテストである程度の安全網ができたあとに統合テストで補うと、手戻りが少なくなります。既存のテストディレクトリにユニットテストと統合テストの区分がある場合は、その区分をClaude Codeに伝えると、どちらの層に書くべきかを判断させやすくなります。
まとめ
Claude Codeにテストを書かせる作業は、カバレッジの薄い箇所の特定→既存パターンに沿った雛形生成→エッジケースの追加→実行して直す、という4手順に分けると安定します。1回の指示で全部を済ませようとせず、手順ごとに結果を確認しながら進めるのが、書きっぱなしのテストを作らないための一番の近道です。テストが安全網として機能するかどうかは、手順の丁寧さで決まります。