Claude Codeでテストを実行・修正するときの使い方

Claude Codeにtestの実行や修正を頼むときは、「失敗を消す」ことではなく、「仕様どおりに動く根拠を増やす」ことを完成条件にします。testがgreenでも、assertionを弱めた、問題のcaseをskipした、fixtureを現実と違う形に変えたなら、品質が上がったとは限りません。まず変更前のfailureを再現し、原因とtestの期待を分けて調べます。

AnthropicのCommon workflowsは、error再現に使うcommand、stack trace、発生手順を共有して修正し、意味のあるtestを実行する流れを示しています。Claude Codeは既存test patternを読んでtestを作成・実行できますが、project固有のscriptや外部serviceの状態はrepositoryで確認してください。

Testの失敗を三つに分ける

最初の失敗は、すぐに「実装bug」と決めつけません。出力とbaselineを見て、次のどれかに分類します。

表は横にスクロールできます

分類	典型的な証拠	次にすること
Product code	実際の入力でも同じ誤動作、期待仕様と実装が違う	原因を直し、回帰testを追加
Test expectation	testが古い仕様や誤った前提を固定している	仕様とownerを確認し、必要なtestだけ更新
Environment / fixture	version、timezone、network、seed data等が異なる	再現条件を固定し、環境差を記録

まず現在のbranch、working tree、test commandを確認し、対象testを単独で走らせます。前から失敗していたcaseがある場合は、今回の変更が原因と断定しません。テストを実行しただけで原因が再現したことにはならないため、入力、環境、期待値も記録します。

このtest failureを修正する前に、完全なcommand、関連するassertion、実際の値、期待値、再現条件を整理してください。今回の変更前にも起きるfailureか分け、仕様とtestの不一致があれば示してください。最初は変更しないでください。

Testは実装の意図を言葉にする

testを追加するときは、対象functionを通して何を守るかを明確にします。「正常に動く」だけでなく、境界値や失敗経路を含めます。入力制約、認可、二重実行、外部依存、部分成功など、機能のriskに合わせてtestを選びます。

表は横にスクロールできます

Test case	何を確かめるか	結果の記録
正常入力	条件を満たす入力が期待出力になる	outputと状態変化
空・欠損	必須値がないと安全に失敗する	error typeと副作用
境界値	上限・下限で契約どおり	境界値の具体値
不正形式	想定外の型やformatを拒否	response、保存なし
外部failure	timeout / 5xx時の振る舞い	retryと部分更新
二回実行	idempotencyや重複送信	重複dataの有無

同じtestを多数作るより、異なるfailure modeを一つずつ押さえる方が有用です。test dataは意図が分かる最小fixtureを用い、production dataや実secretを使いません。randomized testではseedを記録し、失敗時に同じ入力へ戻れるようにします。

Root causeを探す順序

1. testを失敗させた入力と期待値を読む。

2. assertionが参照する実装・fixture・mockをたどる。

3. failureが決まる最初の境界を探す。

4. 実装bug、test bug、environment差を切り分ける。

5. 反証可能な仮説を立てる。

6. 最小変更を行い、対象testを再実行する。

failureの最後のstack frameがroot causeとは限りません。たとえばassertion failureは、前段でparseした入力が既に欠けていた可能性があります。逆に、testを直すべきなのにproduct codeを変えると、意図しないbehaviorを追加します。

仮説は「原因はcache」だけでなく、「cacheを無効にした時だけ再現しなくなるならcache経路が関係する」と反証条件まで書きます。条件を変えた結果が仮説を支持しなければ、別の原因を調べます。Claude Codeに結論を一度に出させるより、観測→仮説→小さい実験を分けます。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Claude Code

  公式サイトを見るTool詳細を見る比較を見る

Claude Codeにtestを頼むbrief

対象：［test / function］

期待仕様：［契約］

まず変更前のtestを実行し、commandとbaselineを記録してください。

Failureごとに実際値・期待値・再現条件を整理してください。

testを削除・skip・緩和せず、根拠があるgeneral fixを提案してください。

修正後は対象test、関連test、必要なtypecheckを実行し、実行しなかったcheckも明記してください。

External serviceやProduction dataを使わず、必要なら既存fixture patternを使ってください。

「一般的な修正をして」というだけでは範囲が広すぎます。valid inputをどう扱うか、失敗時に状態が残るか、backward compatibilityを保つかを仕様に加えます。AnthropicのBest practicesにもtestだけを通すhard-codeやworkaroundを避けるよう促す記述がありますが、実装契約はこの記事ではなく対象repositoryの仕様で決まります。

Test変更の危険信号

次の差分が見えたら、なぜ必要か確認します。

• failing testを削除、skip、timeout延長で隠す

• assertionの比較を厳密値から部分文字列へ弱める

• fixtureを削り、本番で起きる条件が消える

• mockのresponseを実API契約と異なる形にする

• retryを無制限にして、failureが見えなくなる

• snapshotを理由なく再生成し、意図しないUIを承認する

• testのためだけにproduction codeへ特殊な分岐を足す

これらは常に間違いではありません。仕様変更で古いassertionを直す、flaky testの環境条件を固定するなど合理的な場合もあります。判断材料は、変更後のtestが元のreader/user behaviorを依然として検証できるかです。変更理由と、新しいtestがどのfailureを捕まえるかを記録します。

回帰testと既存suiteを使い分ける

直したbugの再発を防ぐtestをまず作り、関連moduleのtest、さらに必要に応じて統合testへ広げます。小さいbugのたびに全suiteを実行する必要はありませんが、広範囲のcontractやshared componentに触れるなら、その範囲に合うcheckが必要です。

表は横にスクロールできます

変更内容	最初の確認	広げる確認
pure function	unit test	型・関連module
API handler	request/response test	auth、integration、error path
database logic	transaction / rollback	migration・consumer
UI behavior	component interaction	route、responsive、console
shared type	typecheck	package build、consumer
dependency update	affected tests	lockfile、security、build

testが長時間かかるときは、短いsubsetを先に使い、その後に必要な統合testを行います。実行できない外部integrationやbrowser QAは別項目として未確認にします。

Error messageと修正後の確認

Claude Codeがtestを通したときも、出力だけを読むのではなく、実行command、対象、exit statusを確認します。成功したsuiteの範囲を正確に伝えさせます。失敗が残った場合は、未解決caseと次の切り分けを報告し、成功扱いにしません。

修正後には、当初失敗した同じ入力で再現しないことを確かめます。似た入力で広く壊れていないか、関連する既存testで確認します。固定日時、timezone、言語設定、外部API mockなどを使ったなら、その前提がtestに残るようにします。

AIものさしの判断

Claude Codeでtestを扱うときは、greenの数ではなく、仕様に対する観測可能な根拠を増やすことが目的です。failureのbaseline、実装とtestの境界、反証できる原因仮説、必要な回帰case、差分を順に確認します。testを直した場合も、変更後に何が検証されているかを説明できて初めて完了です。