いってきた
メモ
「動作するきれいなコード」はあらゆる理由で価値がある
これに近づけるのが良いソフトウェア開発
「動作するコード」＋「きれいなコード」に分解して考えると、
- 「きれいなコード」
動かすまで問題がわからない。ソフトウェア開発は予測可能性が低い。
- 「動作するコード」
これをきれいなコードに変更しようとすると
「動くから良いじゃないか」「変更して動かなくなったらどうする？」
という堕落、恐怖がある。
これに打ち勝つためにテストで保護する。
まずはテストで保護された動作するコードを書いて、それを編集してきれいなコードにしていく。
（テストファースト:テストを書いてgreenになるように実装していく。）
TDDのサイクル
- 次の目標を考える （紙などに書き出すと良い）
- その目標を示すテストを書く
- そのテストを実行して失敗させる
- 目的のコードを書く
- ２で書いたテストを成功させる
- テストが通るまでリファクタリングを行う
- １〜６を繰り返す
日々の作業に落とし込む
テストとメンテナンス
- テストのメンテナンスコスト
- テストの理想はMESE
- テストごとの重なり、漏れがあるとメンテナンスコスト高い
- テストもメンテナンスしていく必要がある
実践
仮実装（テストコードのテスト）
例:真偽を返す関数でreturn trueなどして必ずテストを通るようにする。
こうすることで、テストコードは間違っていないことを確認する。落ちるべきところで落ちることが理想（自分の予想と一致している）。
テストの対称性
テスト件数にばらつきがあると、後任者から見ると段差がバラバラのはしごが残っているようにみえる。 テストを減らすことには判断コストがかかる。 テストケースを減らせるのはテスト担当者のみ。最後にテストの数を揃える。
TDDに必要なスキル
- 問題を小さく分割する
- 歩幅を調整する
- テスト＞仮実装＞三角測量＞実装
- テスト＞仮実装＞実装
- テスト＞明白な実装
- テストの構造化とリファクタリング
TDDはスキル
- 一人から始められる
- 才能ではなく習得可能
- 量は質に添加する
- 写経
