14章『テストと読みやすさ』P.179
14章における「テスト」……他の（「本物」の）コードの振る舞いを確認するためのすべてのコードのこと
14.1 テストを読みやすくて保守しやすいものにする(P.180)
テストコードを読みやすくすることは大切。本物のコードの動作が理解しやすくなる。
テストコードは「本物のコードの動作と使い方を示した非公式的な文書」といえる。
鍵となる考え
他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
ダメなテストコードが引き起こすこと
- 本物のコードを修正することを恐れる
- 新しいコードを書いたときにテストを追加しなくなる
テストコードを変更したことで既存のテストが壊れたとしても、簡単に原因が突き止められるなら安心してテストを追加できるようになる。
14.2 このテストのどこがダメなの？(P.180)
実例
14.3 テストを読みやすくする(P.181)
14.2の解説。
大切ではない詳細はユーザから隠し、大切な詳細は目立つようにするべき。
- 最小のテストを作る
⇨コードが簡潔で読みやすくなる。テストケースの追加が簡単になる。
- 独自の「ミニ言語」を実装する
14.4 エラーメッセージを読みやすくする(P.185)
エラーメッセージはできるだけ役に立つようにするべき。
- もっといいassert()を使う
どの言語を使っていても、役立つライブラリやフレームワーク（xUnitなど）がきっとある。ライブラリのことを知っておこう！
- 手作りのエラーメッセージ
14.5 テストの適切な入力値を選択する(P.188)
テストの適切な入力値を選択するには優れた技能が必要。
適切な入力値＝コードを完全にテストするもの かつ 簡単に読めるような単純なもの
鍵となる考え
コードを完全にテストする最も単純な入力値の組み合わせを選択しなければいけない。
- 入力値を単純化する
テストには最もキレイで単純な値を選ぶ。
- 1つの機能に複数のテスト
○小さなテストを複数作る
簡単で効果的で読みやすい。
複数のテストで別々の方向からバグを見つけ出すようにする。
テストケースが分割されていれば、次の人がコードを扱いやすくなる。
意図せずにバグを発生させたとしても、失敗したテストによってその場所がわかる。
14.5 テストの適切な入力値を選択する（P188）
・コードを完全にテストする最も単純な入力値の組み合わせを選択しなければならない。
→テストコードを書く際、最もキレイで単純な値を選ぶ
・1つの機能に複数のテスト
→小さなテストを複数作る方が単純で読みやすい
例：ソート、重複は許可
14.6 テストの機能に名前をつける（P190）
・テストコード（関数）に名前をつける
例：Test_SortAndFilterDocs() など
その際、名前が長くなっても良い。コメントだと思えば良い。
14.7 このテストのどこがダメだったのか？（P192）
具体例だったので飛ばす
14.8 テストに優しい開発（P194）
テストコードを書くつもりでコードを書くと、
テストしやすいコードを設計しやすいようになり、いいコードが書けるようになる。
14.9 やりすぎ
テストに集中しすぎる可能性もあるので注意する。
・テストのために本物のコードの読みやすさを犠牲にしてしまう。
・テストのカバレッジを100%しないと気がすまない。
・テストがプロダクト開発の邪魔になる。
担当：やし
