第３章 プログラムを失敗させる

問題が発生したら、以下に挙げるように何度も同じテストの実施が必要です。
何度も実施するんだから、デバッグ用テスト自動化しておきましょうねって話。
(本書では、未知の問題の検出を目的としたものを妥当性確認テスト、
　既知の問題の発見を目的としたものをデバッグ用テストと呼んでいます。)

・問題を再現するために作成するテスト (４章)
・問題を単純化するために繰り返し行うテスト (５章)
・プログラムがうまく修正できたか確認するために再度行うテスト (１５章１５.４節)
・同様の問題 (または類似の問題)が今後発生しないよう、新しいバージョンのソフトウェアをリリースする前に再度行うテスト。
　このようなテストを回帰テスト(リグレッションテスト)とも言う (１６章)

デバッグ用テストを、まず以下の３つのレイヤーに分けてそれぞれの長所・短所を記しています。

・プレゼンテーション層
　➡ユーザーとのやり取りをシミュレートするテスト
・機能層
　➡機能の直接テストをシミュレートするテスト
・ユニット層
　➡単体テスト

一言で書くと、プレゼンテーション層でのテストは非推奨。
なぜならプレゼンテーション層は一番変わりやすい部分だから。
変更のたびにテスト資産の修正が必要になるのは賢くない。
ユニット層へのテストと機能層へのテストの自動化の組み合わせを推奨。
文中には明示してないけど、プレゼンテーション層のテストは手動でやれって話だと思う。
(少なくとも私の経験的には、プレゼンテーション層のテスト自動化はあんまし賢くない。)

さて、ここで大事なのが設計の善し悪しがデバッグのコストを大きく左右するってこと。
例えばプレゼンテーション層と機能層とが分離してないプログラムでは、
プレゼンテーション層でテストするしか無くなるため、
テストの自動化を諦めるか、変更覚悟で自動化テストを作るしか無くなってしまう。

だから設計の勉強もちゃんとしないと駄目だよって話。
一例として紹介しているのが、MVCと依存関係逆転の原則(DIP：Dependency Inversion Principle)。
この辺の詳細はネットでたくさん情報あるので、そちらで。

とりあえず３章はこんな感じ。
まだまだこの辺は序の口ってとこですね〜。
さてさて４章はどうなりますか。