第13章 変更する必要がありますが、どんなテストを書けばよいのかわかりません

自動化テストは、バグを見つけるためのテストではなく、意図した振る舞いを維持するためのテスト
バグを見つかるのは、変えるつもりのない振る舞いを変更したとき

仕様化テスト…
コードの振る舞いを明らかにするためのテスト
仕様化テストはシステムの現在の振る舞いをそのまま文章化する

仕様化テストを書くための手順

1. テストハーネスで対象のコードを呼び出す
2. 失敗するとわかっている表明を書く
3. 失敗した結果から実際の振る舞いを確認する
4. コードが実現する振る舞いを期待するように、テストを変更する
5. 繰り返す

あるクラスについて、何をテストすべきかを特定する方法
最初は、クラスの動作を大まかに理解する→想像できる最もかんたんな動作についてテストを書く

筆者の経験則

1. 特に入り組んだ処理を探す
   • コードのある部分を理解できないなら、検出用変数の導入を検討する
2. クラスやメソッドの責務を特定できたなら、そこで一旦止まって失敗する可能性のある事柄の一覧を作る
   • その後、その失敗を引き起こすテストを作成できるかどうかを考える
3. テストに与える入力値を検討する
4. オブジェクトの存続期間を通じて、常に成立する条件を確認する(不変条件)

感想

仕様化テストのやり方が、TDDの、レッド・グリーン・リファクタリングに似ている？ むしろTDDがこの仕様化テストのやり方を持ってきて改善したのか？