テスト戦略全体をClaudeと設計する

テスト戦略の設計をClaudeに相談する

テストをどこから書き始めるか迷ったことはありませんか？ユニットテストだけ書いていたら統合テストが抜けていた、E2Eテストが重複していてCIが遅い——そういった問題をClaudeと一緒に解消できます。

まずはプロジェクトの構成をClaudeに見せて、テスト戦略全体を相談しましょう。次のようにプロンプトを入力してみてください。

このリポジトリのディレクトリ構成とpackage.jsonを読んで、
テストピラミッドに基づいたユニット・統合・E2Eテストの
バランスを提案してください。現在のカバレッジの課題も指摘してください。

Claudeはファイル構成を解析したうえで、「ビジネスロジックはユニットテストを厚くし、API境界は統合テストで、ユーザーフローはE2Eで薄く絞る」といった具体的な方針を返してくれます。

※E2Eテスト: End-to-End テストの略。ユーザー操作を再現してブラウザ全体の動作を検証するテスト手法。※リポジトリ: Gitでコードと変更履歴を管理するフォルダ。GitHubなどのサービスで共有できる。※プロンプト: AIへの指示文。Claude Codeへの指示の質がそのまま出力の質に影響する。※API: Application Programming Interface の略。外部サービスとプログラム間でデータをやりとりするための接続口。

TDDサイクルをClaudeと回す

戦略が決まったら、TDD（テスト駆動開発）のサイクルをClaudeと一緒に回しましょう。新機能を追加するとき、まず「失敗するテストを書いてほしい」と依頼するのがコツです。

// Claudeへの指示例
// 「CartServiceのdiscount計算ロジックに対して、
//  まず失敗するユニットテストをJestで書いてください」

describe('CartService', () => {
  it('10点以上の購入で10%割引が適用される', () => {
    const cart = new CartService();
    cart.addItem({ price: 100, quantity: 10 });
    expect(cart.getTotalWithDiscount()).toBe(900);
  });
});

このテストを渡して「このテストが通る実装を書いてください」と続けるだけで、Red→Green→Refactorのサイクルをスムーズに進められます。

統合テストとE2Eテストの設計を依頼する

ユニットテストが充実してきたら、統合テストとE2Eテストの設計もClaudeに任せましょう。次のように依頼すると、モックの使いどころまで含めて提案してもらえます。

# 実際のターミナルで実行しながらClaudeに相談する流れ
$ npx jest --listTests          # 現在のテスト一覧を確認
$ npx jest --coverage --json    # カバレッジをJSON出力
# → この出力をClaudeに貼り付けて「E2Eで補うべき箇所はどこですか？」と聞く

Claudeはデータベース層はモックせず本物を使う統合テスト、外部APIはモックするE2Eテストというように、費用対効果を考えた設計を提示してくれます。テスト戦略は一度作って終わりではなく、Claudeと継続的に見直しながら育てていくものと捉えると、開発速度と品質の両立がぐっと楽になります。

※モック: テスト時に本物の代わりに使う偽のオブジェクトや関数。外部APIや DBへの実際の通信を避けるために使う。