7-2. TDD入門・コードレビューの観点

このセクションで学ぶこと

• TDD（テスト駆動開発）の流れとなぜ有効か
• コードレビューで何を確認するか
• レビューを受ける側・する側それぞれの心構え
• テストとレビューを組み合わせた品質の考え方

テストを書くタイミングと、コードをどう見るかを学ぶことで、品質を継続して保つ習慣 が身につく。

---

1. TDD とは何か

TDD（Test-Driven Development：テスト駆動開発）は、実装よりもテストを先に書くという開発手法 である。

「先にテストを書く」と聞くと不思議に感じるかもしれないが、TDD には明確な流れがある。

レッド   → まずテストを書く（まだ実装がないので失敗する）
グリーン → テストが通る最低限の実装をする
リファクタ → コードをきれいに整える（テストが通ることを確認しながら）

この繰り返しを Red → Green → Refactor サイクル と呼ぶ。

---

2. Red → Green → Refactor の流れ

Red：テストを書く

まだ実装がないのに、先にテストを書く。

テスト: 「本のタイトルが空のときは例外を投げるはず」
  ↓
実行
  ↓
❌ 失敗（実装がないのだから当然）

なぜ先にテストを書くのかというと、「何を作るか」を先に決めるため である。 テストを書く行為は、「この関数はこういう入力を受け取り、こういう動作をするべきだ」という仕様を言語化することに等しい。

Green：テストが通る実装をする

失敗したテストを通すために、最小限の実装を書く。

関数: addBook(title)
  title が空なら例外を投げる
  それ以外はリストへ追加して返す
  ↓
実行
  ↓
✅ 成功

ここでの「最小限」は重要である。 テストを通すためだけに必要なコードを書き、この段階では完璧な設計を目指さない。

Refactor：コードを整える

テストが通った状態を保ちながら、コードをきれいにする。

重複があれば共通化
変数名をより分かりやすくする
処理の分割を見直す
  ↓
テストが引き続き通ることを確認

リファクタリングとは「動作を変えずに内部構造を改善すること」であり、テストがあることで安心して変更できる。

---

3. TDD のメリットとデメリット

メリット

メリット	説明
設計の質が上がりやすい	テストしやすいコードは、自然と疎結合（部品どうしの依存が少ない状態）になりやすい
仕様の明確化	何を作るかを先に考えるため、あいまいな仕様に気づきやすい
リファクタリングの安心感	テストがあるので変更を怖がらずに行える
過剰実装を防ぎやすい	テストを通すことだけを考えるため、不要な実装が入りにくい

デメリット・注意点

デメリット	説明
慣れるまで時間がかかる	先にテストを書く発想に慣れが必要
すべてに向くわけではない	UI の細かい動作や探索的な実装では適用しにくいこともある
テストの設計力が必要	テスト自体が設計を誘導するため、テストを書くスキルが求められる

TDD は「テストを必ず先に書かなければいけない」という厳格なルールではなく、品質と設計を改善するための考え方として捉えると使いやすい。

---

4. テストを先に書くと設計が変わる理由

TDD で有名な副作用として、「テストを書こうとすると、設計の問題に気づける」というものがある。

テストを書こうとしたら
「このクラスはデータベースに直接依存していてテストできない」
  ↓
依存を外から注入できるように設計を変える
  ↓
結果として疎結合（部品どうしの結びつきが弱く、差し替えやすい状態）な設計になる

実際に、「テストが難しいコード」は往々にして「修正も難しいコード」でもある。

つまり TDD は、テストそのものが目的ではなく、テストを書く行為を通じて良い設計へ誘導するプロセス でもある。

---

5. コードレビューとは何か

コードレビューは、書いたコードを他の開発者が読んで確認する作業 である。

本人が気づかないバグや設計の問題を発見したり、知識を共有したりすることができる。

開発者がコードを書く
  ↓
プルリクエスト（PR）を作る
  ↓
チームメンバーがレビューする
  ↓
フィードバックをもとに修正する
  ↓
承認されたらマージする

---

6. レビューで確認する観点

コードレビューでは、具体的に何を見るのかを押さえておく。

正しさ

• 意図通りに動くか
• エッジケース（空・ゼロ・最大値など）で正しく動くか
• エラー処理が適切か

安全性

• 入力値を検証しているか
• SQLインジェクション・XSSなど脆弱性につながる書き方をしていないか
• 認証・認可のチェックが適切か

読みやすさ

• 変数名・関数名が意図を表しているか
• 長すぎる関数を分割できるか
• コメントが過不足なく書かれているか

変更の影響範囲

• 他の機能を壊していないか
• 後方互換性は保たれているか

テスト

• テストが書かれているか
• テストが網羅的か（正常系・異常系・境界値）
• テスト名が何を確認しているかを表しているか

---

7. レビューを受ける側の心構え

コードレビューは批判ではなく協力である。

心構え	説明
指摘はコードへの意見であり、人格の否定ではない	フィードバックを個人攻撃として受け取らない
意図を説明できるようにしておく	なぜその実装を選んだかを説明できると、議論が建設的になる
分からないことは聞く	指摘の意図が分からなければ確認する
小さなPRにする	差分が大きいとレビューが難しくなる

レビューコメントを受けて修正する場合は、単に直すだけでなく なぜそう直すのかを理解する ことが重要である。

---

8. レビューをする側の心構え

心構え	説明
目的はコードの品質向上	指摘数を競うのではなく、チームの成果を高めることが目的
具体的に伝える	「ここが気になる」ではなく、なぜ・どう直すとよいかを伝える
良い部分も伝える	優れた実装は認めることで、チームの学習を促す
優先度を示す	必須の修正か、提案・質問に過ぎないかを明確にする
自分も間違える	レビュアーの意見が常に正しいとは限らない

---

9. よくあるレビューコメントの分類

レビューコメントを受けたとき、その意図を理解するために分類を知っておくと便利である。

分類	説明	例
バグ修正必須	動作が壊れる・危険な実装	「ここで null になるケースがある」
セキュリティ	脆弱性につながる可能性	「SQL に入力を直接結合しないほうがよい」
設計改善（要議論）	より良い設計の提案	「この処理は別のクラスに移したほうが責務が明確かも」
読みやすさ（任意）	命名や構造の整理	「変数名を data より userList にするといいかも」
質問・確認	意図の確認	「ここで型変換をしている意図は？」

---

10. テストとレビューを組み合わせる

TDD で書いたコードをレビューすると、次のようなメリットが生まれる。

テストがある
  ↓
レビュアーが動作の意図をテストから読める
  ↓
「こういう仕様で書いたのだな」が分かる
  ↓
コードへの指摘がより的確になる

また、レビューで「このテストケースが抜けている」という指摘もできるようになる。

テストとレビューは、どちらか片方より 両方を組み合わせたほうが品質向上に効果が出やすい 。

---

まとめ

キーワード	説明
TDD	テストを先に書き、Red → Green → Refactor のサイクルで開発する手法
Red	テストが失敗している状態（まだ実装がない）
Green	テストが通った状態
Refactor	テストが通った状態を保ちながらコードを整える
コードレビュー	他の開発者がコードを確認する作業
レビュー観点	正しさ・安全性・読みやすさ・影響範囲・テスト
疎結合	テストしやすいコードは変更しやすいコードでもある

---

次のステップ

演習問題 に取り組んで、TDD の流れとレビュー観点を整理しよう。

第7章が終わったら 第8章：JavaScript基礎 へ進み、フロントエンド実装に必要な文法と考え方を身につけよう。