第10章 テストに聞いてみる
本章でやったこと
サブクラスのメソッド（times）の実装の差異をなくすために、以下のリファクタリングを行った
メソッド呼び出しのインライン化
デバッグ時のみに使う toString メソッドを テストを書かず に追加した
Frac の代わりに Money を返す変更し、テストが落ちるかチェックした（テストに聞いた）
実験的に変更を revert し、テストを追加した
その上で再度テストが通るように実装した
テストに聞く
実装の正しさは、既存のテストとそれをパスする綺麗なコードがあれば頭で考える必要はない
サンプルコードだと Franc と Money の区別が必要か？という点
コードを変更し、テストを実行すればテストが教えてくれる
実装に迷ったら、テストを書いて仕様を模索せよ、ということ？ radish-miyazaki.icon
TDD が「テスト駆動」開発と呼ばれる所以か
サンプルコードだと equals に起因する問題であった
調べるのは通貨が等しいかであって、クラスが同じかではない
→ これらの区別は不要
なぜ toString メソッドのテストを書かなかったのか
画面への出力がすぐ見たかった
デバッグ出力のためであり、バグが混入しても問題ない
既存テストが失敗している時に、テストを追加するのは避けたい
テストが意図せず失敗した時はどうするか
テスト無しで本番コードを変更するのは NG
また、テストを新規で追加するのも避けたい
代わりに、以下のようなフローで進めると良い
1. テストが失敗している原因箇所を確認する
2. 1. の変更を巻き戻し、テストがパス（GREEN）する状態に する
3. 新しいテストを追加する
4. 3. のテストがパスするように実装を進める