リーダブルコード読書メモ～その７（最後）～
こちらの続きです。
14章を取り上げます。若干ボリューミーなので、14章のみです。なお、リーダブルコード読書メモはこれで最後です。本当は15章があるのですが、1～14章に対する問題演習みたいな位置づけのため、ノウハウまとめとしては15章は触れず、14章までとします。
14章はテストコードに関する話題です。通常のビジネスロジックとは異なり、テストコードにはテストコードなりの読みやすさ、保守のしやすさなどがあるので、そのあたりを中心に扱っていきます。
14章
テストコードの読みやすさ
- 通常のビジネスロジックと同じくらいの可読性、保守性が求められる。
- テストコードは仕様理解のための非公式ドキュメントという考え方もある。
- そのため、読みやすければ、仕様理解の促進につながる。
テストを読みやすくする
- 大事なことを目立たせる
- テストデータでは独自で変数や定数を定義する。これらがハードコードされていて、変に目立っていないか
- このテストは何をしているのかを最小限でコーディングする（12章のやり方）
- 細かくメソッド化する、ヘルパーメソッドを作成するなどで工夫する
- 大事なことを目立たせる
エラーメッセージを読みやすくする
- assertメソッドについて、ライブラリ標準のものは大体優れているのでそれをうまく活用する
- 入力、出力、具体的にどれがまずいか、がしっかり明示されているかがポイント
- メッセージ表示のメソッドを独自で作ってしまってもいい
テストの入力データ
- テストはきれいで単純な値を選ぶ
- 不必要に桁数の多い数値、テストの目的とはかけ離れている複雑な文字列、などはNG
- 負荷テストなど、大量のデータが必要な場合はテスト生成用のメソッドを作るといい
- 入力データが複雑になりがちの場合、一つの機能やメソッドで複数のテストをしている傾向がある。分割すること
- 分割したほうが保守の面でもいい
- テストはきれいで単純な値を選ぶ
テストの機能に名前を付ける
元のコードがテストしやすいように書かれているか
- 元のコードがテストしにくいコードであれば、テストコードも汚くなる
- 簡潔かつ明確なインタフェースがあるなど
- ただ、テストコードを意識しすぎて、元のコードの読みやすさを犠牲にするのも問題
- 元のコードがテストしにくいコードであれば、テストコードも汚くなる
終わりに
テストについて色々書きました。結局テストコードも、13章までのノウハウに気を付けてね、という話でした。
