Claude Code でコードを書けるようになってきた。でも「テストコードって何？」「なぜ書かないといけないの？」という疑問を持っている方は多いはずです。

テストコードは「書かなくても動く」ものです。でも、書かずに開発を続けると、必ず「どこかを直したら別のところが壊れた」「リリース直前に大量のバグが出た」という状況に追い込まれます。

本記事では、テストコードとは何かという基礎から、なぜ重要なのか・何に気をつけるべきか、そして Claude Code を使ったコードレビューの方法まで、開発を始めた方が最初に知っておくべきことをまとめました。

スポンサーリンク

目次

1. テストコードとは何か
2. なぜテストコードが必要なのか
3. テストの種類と使い分け
4. テストコードの書き方（基本パターン）
5. テストコードを書くときに気をつけること
6. Claude Code でテストコードを生成する方法
7. Claude Code でコードレビューをする方法
8. テストを「書き続ける」習慣の作り方
9. まとめ

1. テストコードとは何か

テストコードとは、「自分が書いたコードが正しく動くかを自動で確認するためのコード」です。

たとえば、税込み価格を計算する関数を作ったとします。

// 税込み価格を計算する関数
function calcPriceWithTax(price) {
  return price * 1.1;
}

この関数が正しく動くかを確認するテストコードは、こんな形になります。

// テストコード
test('1000円の税込みは1100円になる', () => {
  expect(calcPriceWithTax(1000)).toBe(1100);
});

test('0円の税込みは0円になる', () => {
  expect(calcPriceWithTax(0)).toBe(0);
});

テストを実行すると「✅ 合格」または「❌ 失敗」が表示されます。このチェックを人間が毎回手で確認する代わりに、コンピュータが自動でやってくれるのがテストコードの役割です。

2. なぜテストコードが必要なのか

理由①「どこかを直したら別のところが壊れた」を防ぐ

開発が進むにつれて、コードは複雑になっていきます。あるファイルを修正したら、全然別の機能が壊れてしまう——これをデグレ（デグレード）と呼びます。テストコードがあれば、修正のたびに全テストを実行することで、デグレを即座に検出できます。

理由②「仕様の文書」としての役割

テストコードは「この関数はこういうときにこう動くべき」という仕様書になります。新しいメンバーがテストコードを読むだけで「このコードは何をするものか」が理解できます。コメントや README より正確で、常に最新の状態が保たれます。

理由③「自信を持ってデプロイできる」

テストがすべて通っている状態でリリースするのと、手動で「たぶん大丈夫」とリリースするのでは、精神的な安心感がまったく違います。CI/CD（自動デプロイ）と組み合わせると、テストが通らない限り本番環境にデプロイされない仕組みも作れます。

理由④「リファクタリングが怖くなくなる」

リファクタリング（コードの整理・改善）はテストがないと非常にリスクが高い作業です。「動いているコードを触って壊すかもしれない」という恐怖があるからです。テストがあれば、リファクタリング後にテストを実行して「合格」していれば動作が変わっていないことが保証されます。

3. テストの種類と使い分け

テストにはいくつかの種類があります。小さいものから順に理解しましょう。

ユニットテスト（最初に書くべきもの）

1つの関数・クラスが単体で正しく動くかを確認します。外部 DB や API に依存しないので非常に高速です。テストを書き始めたばかりの人はまずユニットテストだけ書けるようになることを目標にしましょう。

統合テスト

複数のモジュールが連携したとき・データベースと組み合わせたときに正しく動くかを確認します。「ユーザー登録 → メール送信 → DB 保存」のような一連のフローをテストします。

E2Eテスト（End-to-End テスト）

Playwright や Cypress などを使って、実際のブラウザを操作してユーザーの行動をシミュレートするテストです。最も現実に近いですが実行に時間がかかるため、重要な画面フローに絞って書きます。

4. テストコードの書き方（基本パターン）

JavaScript / TypeScript（Vitest・Jest）

// テスト対象の関数（src/utils/tax.ts）
export function calcPriceWithTax(price: number): number {
  if (price < 0) throw new Error('価格は0以上である必要があります');
  return Math.round(price * 1.1);
}

// テストコード（src/utils/tax.test.ts）
import { describe, it, expect } from 'vitest';
import { calcPriceWithTax } from './tax';

describe('calcPriceWithTax', () => {
  it('1000円の税込みは1100円になる', () => {
    expect(calcPriceWithTax(1000)).toBe(1100);
  });

  it('0円の税込みは0円になる', () => {
    expect(calcPriceWithTax(0)).toBe(0);
  });

  it('端数は四捨五入される', () => {
    expect(calcPriceWithTax(100)).toBe(110);
    expect(calcPriceWithTax(1)).toBe(1); // 1 * 1.1 = 1.1 → 1
  });

  it('負の値を渡すとエラーが投げられる', () => {
    expect(() => calcPriceWithTax(-1)).toThrow('価格は0以上である必要があります');
  });
});

Python（pytest）

# テスト対象の関数（utils/tax.py）
def calc_price_with_tax(price: float) -> int:
    if price < 0:
        raise ValueError("価格は0以上である必要があります")
    return round(price * 1.1)

# テストコード（tests/test_tax.py）
import pytest
from utils.tax import calc_price_with_tax

def test_standard_price():
    assert calc_price_with_tax(1000) == 1100

def test_zero_price():
    assert calc_price_with_tax(0) == 0

def test_negative_price_raises_error():
    with pytest.raises(ValueError, match="価格は0以上である必要があります"):
        calc_price_with_tax(-1)

テストの実行コマンド

# Vitest（JavaScript/TypeScript）
npm run test
npm run test -- --watch    # ファイル変更を監視して自動実行
npm run test -- --coverage # カバレッジレポートを出力

# Jest
npx jest
npx jest --watchAll

# pytest（Python）
pytest
pytest -v               # 詳細表示
pytest --cov=src        # カバレッジ計測

5. テストコードを書くときに気をつけること

① テストは「1テスト・1つの確認」にする

1つのテスト関数に複数の確認を詰め込むと、どこで失敗したか分かりにくくなります。

it('価格計算のテスト', () => {
  expect(calcPriceWithTax(1000)).toBe(1100);
  expect(calcPriceWithTax(0)).toBe(0);
  expect(calcPriceWithTax(-1))
    .toThrow();
});

it('1000円 → 1100円になる', () => {
  expect(calcPriceWithTax(1000))
    .toBe(1100);
});
it('0円 → 0円になる', () => {
  expect(calcPriceWithTax(0)).toBe(0);
});

② テスト名は「何をテストしているか」が分かるように書く

it('test1', () => { ... });
it('エラーテスト', () => { ... });
it('価格', () => { ... });

it('価格が1000円のとき1100円を返す', () => {...});
it('負の値を渡すとエラーを投げる', () => {...});
it('0円のとき0円を返す', () => {...});

③ 外部サービス・DBはモック（偽物）に置き換える

本物のデータベースや外部 API をテストで使うと、テストが遅くなり・環境によって結果が変わり・テストのたびにデータが増えます。ユニットテストではモック（偽の動作をするオブジェクト）に置き換えます。

// メール送信サービスをモックに置き換える例（Vitest）
import { vi } from 'vitest';
import { sendWelcomeEmail } from './email';

vi.mock('./email', () => ({
  sendWelcomeEmail: vi.fn().mockResolvedValue({ success: true })
}));

it('ユーザー登録時にウェルカムメールが送信される', async () => {
  await registerUser({ email: 'test@example.com' });
  expect(sendWelcomeEmail).toHaveBeenCalledWith('test@example.com');
});

④ 境界値・異常系を忘れずにテストする

多くのバグは「正常な入力」ではなく「端っこの値（境界値）」や「おかしな入力（異常系）」で発生します。

⑤ テストコードもリファクタリングする

テストコードもメンテナンスが必要なコードです。同じセットアップ処理が繰り返されているなら beforeEach でまとめる、重複したアサーションはヘルパー関数にまとめる、など読みやすく保つことが大切です。

⑥ カバレッジ100%を目指さない

6. Claude Code でテストコードを生成する方法

Claude Code はテストコードの生成が得意です。「このコードのテストを書いて」と指示するだけで、適切なテストケースを自動生成してくれます。

基本的な依頼方法

# シンプルな指示
"src/utils/tax.ts のテストコードを Vitest で書いて"

# より具体的な指示（精度が上がる）
"src/auth/login.ts のテストコードを書いて。
以下のケースを必ずカバーしてほしい：
- 正しいメールアドレスとパスワードでログイン成功
- 間違ったパスワードでエラーが返る
- 存在しないメールアドレスでエラーが返る
- メールアドレスが空のときバリデーションエラーになる
使用フレームワーク：Vitest + Testing Library"

既存テストを追加・改善してもらう

# テストケースの追加
"src/utils/tax.test.ts を読んで、
テストが不足しているケースを追加して"

# 境界値テストの追加
"この関数の境界値テスト（0・最大値・null・undefined）を追加して"

# テストの可読性向上
"src/auth/login.test.ts のテストコードをリファクタリングして。
beforeEach で共通の準備処理をまとめて、テスト名をより明確にして"

カバレッジレポートを元に依頼する

# カバレッジ確認
npm run test -- --coverage

# カバレッジが低いファイルのテストを書いてもらう
"coverage/lcov-report を確認すると、
src/lib/formatter.ts のカバレッジが40%しかありません。
不足しているテストケースを追加してください"

7. Claude Code でコードレビューをする方法

コードレビューとは「書いたコードを他の人に確認してもらうプロセス」です。バグの早期発見・コード品質の維持・知識の共有が目的です。Claude Code はこのレビュアーとしての役割も担えます。

コード全体のレビュー依頼

# 基本のレビュー依頼
"src/auth/ ディレクトリのコードをレビューして"

# 観点を指定したレビュー
"src/auth/login.ts をレビューして。
特に以下を重点的に確認してほしい：
1. セキュリティ上の問題（SQLインジェクション・XSS・認証の抜け穴）
2. エラーハンドリングの漏れ
3. パフォーマンスの問題
4. テストが書きにくい構造になっていないか"

PR 前のセルフレビュー

# 変更差分を確認してからレビュー依頼
"git diff origin/main...HEAD の変更内容を確認して、
プルリクエストを出す前に問題がないかレビューして。
特にバグ・セキュリティ・コードスタイルの観点で見てほしい"

# チェックリスト形式でレビューしてもらう
"以下の観点でこのコードをレビューして、
問題があれば箇条書きで指摘してほしい：
□ 変数名・関数名は意図を正確に表しているか
□ 同じコードが繰り返されていないか（DRY原則）
□ 関数が1つの責務に集中しているか
□ 適切なエラーハンドリングがされているか
□ コメントは不要な部分・不足している部分はないか"

セキュリティレビューを依頼する

"src/api/users.ts をセキュリティの観点でレビューして。
以下の脆弱性がないかチェックしてほしい：
- SQLインジェクション
- XSS（クロスサイトスクリプティング）
- 認証・認可の抜け穴
- 機密情報の露出（パスワード・APIキーのログ出力など）
- レート制限の欠如"

改善提案を求める

# リファクタリング提案
"このコードをリファクタリングする場合、
どんな改善ができるか提案して。
ただし動作は変えないこと"

# パフォーマンス改善
"このコードのパフォーマンスを改善できる箇所があれば指摘して。
特にN+1クエリ問題・不要な再レンダリングに注目してほしい"

レビュー結果を活用する

8. テストを「書き続ける」習慣の作り方

最初から完璧を目指さない

テストを書き始めた最初は、すべてのコードにテストを書こうとしなくて大丈夫です。「新しく書いた関数には必ずテストを書く」というルールから始めましょう。既存のコードへのテスト追加は、そのコードを修正するタイミングに合わせて少しずつ行います。

TDD（テスト駆動開発）を試してみる

TDD とは「テストを先に書いてから実装する」開発手法です。最初は慣れないかもしれませんが、「コードが正しく動くとはどういうことか」を先に考えることで、設計が自然とよくなる効果があります。

# TDD のサイクル
# 1. 失敗するテストを書く（まだ実装がないので当然失敗）
it('ユーザー名が空のときバリデーションエラーになる', () => {
  expect(validateUser({ name: '' })).toEqual({ valid: false, error: '名前を入力してください' });
});

# 2. テストが通る最低限の実装を書く
function validateUser(user) {
  if (!user.name) return { valid: false, error: '名前を入力してください' };
  return { valid: true };
}

# 3. リファクタリングしてコードをきれいにする
# → テストが通り続けることを確認しながら整理する

CI で自動実行する仕組みを作る

GitHub Actions などの CI（継続的インテグレーション）を設定すると、push のたびに自動でテストが実行されます。テストが失敗した PR はマージできない設定にしておくと、チーム全体のコード品質が自然に保たれます。

# .github/workflows/test.yml の基本形
name: Test

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run test
      - run: npm run lint

まとめ

テストコードは「書かなくても動く」ものです。でも、書かないと必ずどこかで大きなツケが回ってきます。まずは小さな関数1つにテストを1つ書くところから始めてみてください。最初の1つが書けるようになれば、あとは自然とテストを書く習慣が身についていきます。

Claude Code はテストコードの生成・コードレビューの両方で強力な助けになります。うまく活用して、安心して開発できる環境を作っていきましょう。