テストって結局何のために書くんでしょうか？カバレッジを上げるため？上司に言われたから？いいえ、違います。

テストの本質は「保証」と「検知」です。この関数は正しい入力に対して正しい出力を返す、というシンプルな約束を守り続けること。そして、誰かがコードを変更したときに、その変更が意図しない場所に影響を与えていないかを検知すること。この2つがテストの核心です。

参考: Martin Fowler - Testing Guide

参考: pytest - Good Integration Practices

実際のコードで見てみましょう。Pythonとpytestを使った例です。

def test_always_passes(self):
"""常にパスするテスト"""
assert True  # 何も検証していない


def test_implementation_detail(self):
"""実装の詳細をテスト"""
todo = Todo.objects.create(title="Test")
# Djangoの内部実装に依存
assert todo._state.db == "default"
assert hasattr(todo, "_meta")


def test_django_framework_behavior(self):
"""フレームワークの動作をテスト"""
todo1 = Todo.objects.create(title="First")
todo2 = Todo.objects.create(title="Second")
# Djangoが既に保証している機能
assert todo2.id > todo1.id

def test_title_boundary_max_length(self):
"""境界値テスト: 最大200文字"""
max_title = "a" * 200
todo = Todo.objects.create(title=max_title)
assert len(todo.title) == 200


def test_title_boundary_exceeds_max_length(self):
"""境界値テスト: 201文字はエラー"""
todo = Todo.objects.create(title="a" * 201)
# SQLiteでは保存されるがDB依存の動作
assert len(todo.title) == 201


def test_is_overdue_with_past_date(self):
"""期限切れ判定ロジックのテスト"""
todo = Todo.objects.create(
title="Overdue task",
due_date=date.today() - timedelta(days=1),
)
assert todo.is_overdue() is True

コード例: test_models.py

React + TypeScript + Vitestでの例です。考え方はバックエンドと変わりません。

it("always passes", () => {
expect(true).toBe(true);
// 何も検証していない
});

it("checks component instance", () => {
const { container } = render(
<TodoForm onSubmit={vi.fn()} />
);
// 実装の詳細（CSSクラス）に依存
expect(container.querySelector(
".todo-form"
)).toBeTruthy();
});

it("has correct form class name", () => {
const { container } = render(
<TodoForm onSubmit={vi.fn()} />
);
// CSSクラス名のテスト（優先度低）
expect(container.querySelector("form"))
.toHaveClass("todo-form");
});

it("submits form with valid data", async () => {
const onSubmit = vi.fn();
const user = userEvent.setup();

render(<TodoForm onSubmit={onSubmit} />);

await user.type(
screen.getByLabelText(/タイトル/i),
"New TODO"
);
await user.selectOptions(
screen.getByLabelText(/優先度/i),
"high"
);
await user.click(
screen.getByRole("button", {name: /作成/i})
);

expect(onSubmit).toHaveBeenCalledWith({
title: "New TODO",
priority: "high",
// ...
});
});

コード例: TodoForm.test.tsx | 参考: Vitest Official

参考: Boundary Value Analysis and Equivalence Partitioning

スナップショットテストの何が良いかって？リグレッション（意図しない変更）の検知力が圧倒的なんです。

def test_all_todos_snapshot(self, api_client):
"""TODO一覧APIのスナップショットテスト"""
response = api_client.get("/api/todos/")
data = response.json()

# ゴールデンデータと比較
snapshot_comparator.assert_matches_snapshot(
data,
"todos_all",
exclude_fields=["id", "created_at", "updated_at"],
)
# IDや日時は実行ごとに変わるので除外

# ゴールデンデータはParquet形式で保存
# - 大量データでも効率的
# - 人間が読めるフォーマット
# - バージョン管理可能

コード例: test_todos.py | 参考: Effective Snapshot Testing - Kent C. Dodds

参考: pytest | Vitest | Playwright | Django Testing

大企業とスタートアップでは、テストの書き方・考え方が大きく異なります。自分の環境に合ったアプローチを選びましょう。

「カバレッジ100%目指せ！」とか「カバレッジなんて意味ない」とか、極端な意見を聞くこと、ありませんか？実は、どちらも正しくありません。

参考: Google Testing Blog - Code Coverage Best Practices | Productive Coverage (ICSE 2024)

データ: JetBrains Developer Ecosystem 2024 | Software Testing Statistics 2024

もっと詳しく知りたい人へ（参考文献）

• pytest公式ドキュメント - Python テストフレームワーク
• Vitest公式ドキュメント - TypeScript テストフレームワーク
• Playwright公式ドキュメント - E2E テストフレームワーク
• Martin Fowler - Testing Guide - テストの考え方の基礎
• The Practical Test Pyramid - テストピラミッドの実践
• Google Testing Blog - Googleのテスト手法
• Effective Snapshot Testing - スナップショットテストのベストプラクティス
• JetBrains Developer Ecosystem 2024 - 開発者調査レポート
• サンプルコードリポジトリ - この記事で使用したコード例