「Claude Codeにテスト書いてもらえるの便利ですよね、でも品質ってどうやって担保するんですか」 — 業務委託先のエンジニアから来た質問です。生成は速い。問題は「保守できるテスト」になるかどうかです。

この記事は、Claude Codeで自動テストを生成・保守する実用ルールを、私の半年の運用から整理したものです。

画面を実際に操作して確かめる種類のテストはClaude CodeとPlaywrightに分けました。

「テストファースト」と「事後追加」の使い分け

Claude Codeでテストを書く時の入り口は2つあります。

ひとつめは、テストファースト。実装する前に「このAPIに対するテストを書いて」と頼んで、その後で実装に進む流れ。

ふたつめは、事後追加。既存のコードに対して「このファイルにテストを足して」と頼む流れ。

私の運用では、新規機能はテストファースト、既存コードへの追加は事後、と使い分けています。テストファーストのほうが Claude が実装に集中しやすく、生成されるテストの質も上がる傾向があります。

フレームワーク別の頼み方

テストフレームワークごとに、Claude Code への頼み方は少し違います。代表的なものを並べます。

言語

フレームワーク

頼み方のコツ

Python

pytest

fixtureを共有させる前提でファイル分割を指示

JavaScript

jest

mock の戦略(jest.fn vs spy)を最初に握る

TypeScript

vitest

型定義との整合性を意識させる

Go

testing

table-driven test の形式を指定

Rust

cargo test

#[cfg(test)] とインライン配置の方針を握る

CLAUDE.mdに「テストは○○フレームワークを使う」「table-driven形式を優先する」のような規約を書いておくと、Claudeが毎回その形式に沿ってくれます。

CLAUDE.mdの書き方テンプレート

claudecodelab.jp

失敗テストの修正ループ

Claude Codeでテストが一番効くのが、失敗テストの修正ループです。

「テストを走らせて、失敗したら直して、また走らせて」と頼むと、pytest や jest を実行→失敗箇所を読み→修正→再実行、というサイクルをClaudeが回します。

$ claude
> pytest を走らせて、失敗したテストを順番に直してください。
> ただし、テスト側ではなくプロダクションコード側を直してください。
> 5回まで試して、それでも全部通らなければ報告してください。

「テスト側を直すな、プロダクションコード側を直せ」という指示が大事です。これがないと、Claudeが「テストが間違っている」と判断して、テストのassertionをいじって通そうとする事故が起きます。

「テストの質」を担保する3つの指示

生成されたテストの質を保つために、私がよくCLAUDE.mdに書いている指示が3つあります。

ひとつめ。「テストは1つにつき1つのことだけを確認する」。テストごとの責任範囲を狭く保つ。

ふたつめ。「テスト名は何をどんな条件でテストしているかが分かる形にする」。命名が雑だと、半年後に自分が読めなくなります。

みっつめ。「Given-When-Then 構造で書く」。準備・実行・検証の3段階に分けて書かせる。

これら3つを CLAUDE.md に書いておけば、Claudeが生成するテストの品質が一段上がります。

モックの戦略を最初に握る

外部依存(API、DB、ファイルシステム)があるコードのテストでは、モックの戦略が重要です。

「全部本物のDBに対してテストするのか」「全部モックにするのか」「重要なところだけ実DBで他はモックか」を最初に握っておかないと、Claudeが場当たり的にモックを書いて、半年後に保守不能になります。

私の研修先で勧めているルールは「ユニットテストは全部モック、結合テストは実物に対して」というシンプルな分け方。CLAUDE.mdに書いておけば、毎回のテスト生成でこのルールに沿ってくれます。

Claude Codeを安全に運用する3層チェック体制の作り方

claudecodelab.jp

カバレッジは目安、信頼性が本質

最後に、テストの「量」の話を。

「テストカバレッジを80%にして」と頼めば、ClaudeはカバレッジツールでX%を満たすテストを生成します。ただ、これは数字を満たすための作業になりがちです。

私の運用では、カバレッジは「足りないところを見つけるための目安」として使い、「重要なロジックに信頼性のあるテストがあるか」を最終判断にしています。Claudeに「カバレッジ80%」と頼むより、「このビジネスロジックの主要パターンを網羅して」と頼むほうが、結果として保守しやすいテストになります。

CIとの組み合わせ

最後に、CIとの組み合わせ。テスト生成と保守はClaude Code側で、CIで通すのは別の話です。

ultrareview(/code-review ultra)とは クラウドで動く多エージェントコードレビュー

claudecodelab.jp

ローカルでテストが通っても、CI上の環境差で落ちることはある。CIに /code-review ultra を組み込んでおくと、テスト不足や見落としをマージ前に検出しやすくなります。

まとめ

  • 新規機能はテストファースト、既存コードへの追加は事後の使い分けが効く
  • CLAUDE.mdにフレームワークとテスト規約(table-driven, Given-When-Then等)を明示
  • 失敗テストの修正は「テストではなくプロダクション側を直せ」と指示する
  • テストの質は「1つにつき1つの確認」「分かる命名」「Given-When-Then」の3点で担保
  • モックの戦略(ユニット=モック / 結合=実物)を最初に握る
  • カバレッジは目安、信頼性のあるテストが本質
  • ローカルテスト+CIでの ultrareview の組み合わせでマージ前の網羅性を上げる