## 4部
# 14.テストと読みやすさ
本番のコードの振る舞いを確認するために書かれるコードを指す
・テストは読みやすくて保守しやすいものにする
→他のプログラマが安心してテストの追加や変更ができるようにテストコードは読みやすくする
・テストを読みやすくする
→大切ではない詳細はユーザーから隠し、大切な詳細は目立つようにすること
そのために、最小のテストを作り、このテストが何をしようとしているのかを簡単な言葉で説明できるようになる。
・エラーメッセージを読みやすくする
→便利なアサーションメソッドを使う
（エラーメッセージはできるだけ役に立つようにする cf.自分好みのエラーメッセージを印字する「手作りのアサート」を用意するなど）
・テストの適切な入力値を選択する
→
コードを完全にテストする最も単純な入力値の組み合わせを選択しなければならない
テストには最もキレイで単純な値を選ぶ
1つの機能に複数のテスト
テストコードを(ソート、マイナスは削除……といったように)分割させていることで次の人がコードを扱いやすくする・バグを発生させた際に失敗したテストによってその場所がわかる）などの効果がある
・テストの機能に名前をつける
→
"Test1"のような名前ではなく、テストの内容を表した名前を付けるべきである。
以下の点がすぐに理解できるといい
・テストするクラス
・テストする関数
・テストする状況やバグ
ex.Test_<関数名>()やテストの関数を分割する場合はTest_<関数名>_<状況>のようにするとわかりやすい。
また、テスティングフレームワークを使っている場合、その規約にのっとる
・このテストのどこがダメだったのか?（用例のまとめ）
→
・テストステートメントが長すぎる
・テストが簡単に追加できない
・失敗メッセージが役に立たない(デバッグに使える情報が足りない)
・一度にすべてのことをテストしている（分割するべき）
・テストの入力値が単純ではない（-9998.7のような値は「大音量」で目立つが、意味はないためもっと単純なマイナス値で十分である）
・テストの入力値が不完全(スコアが0の場合などテストしていないため、どのような振る舞いをするのか不明確)
・極端な入力値を使ってテストしていない（空のベクタ、巨大なベクタ、スコアが重複したものなど）
・Test1()のような意味のない名前がついている。テストの関数名はテストする関数や状況を表したものにする
テストに優しい開発
→テスト駆動開発（TDD）
本物のコードを書く前にテストを書くプログラミング手法
・やりすぎ
→
・テストのために本物のコードの読みやすさを犠牲にしてしまう。
・テストのカバレッジを100%にしないと気が済まない
・テストがプロダクト開発の邪魔になる
・まとめ
→
・テストのトップレベルはできるだけ簡潔にする。
・テストが失敗した際のエラーメッセージはバグの発見や修正がしやすいものにする
・テストに有効な最も単純な入出力値を使う
・何をテストしているのか明らかにするTest_<関数名>_<状況>のような名前にする
新しいテストの追加や修正を簡単にすることが大事である
#15.「分/時間カウンター」を設計・実装する
実際のコードの改善をする
①名前の改善
→ ・ex)count()というメソッド名には名詞と動詞があり、
この場合動詞で使っているが名詞（これまでのカウントが欲しい）と解釈されやすい。
変更する用例として
●Increment（）増加
●Observe（）観察する
●Record() 記録する （名詞で）記録
●Add() 加える
②コメントの改善
外部の視点を得る（他の人に聞くなど。 6か月後の自分なども含まれる）
③書く→読みやすく書く
④パーフォーマンスの問題などの問題を挙げる、バグの（数字を丸めてしまうもの）の修正
⑤複数の下位問題を分割し、解決した
以上
とりあえず、一冊読んだ。この本、最初は１部をしっかり読んで定着（やってほしいことは本のなかにも書いてあるが１部にまとまっていて、後の部はその「やり方」が書いてあるだけなので）させるくらいの方がいいのかなぁと思った。
めちゃめちゃ覚えていたらになるのだけど来年も同じくらいの時期に読むと感想が変わるかもなぁという感じ。