カニ本読書メモ 1章:テストでコードを駆動する

Rubyベストプラクティス -プロフェッショナルによるコードとテクニック

でかいテストを書いてからとかやるより、小さいステップからイテレーティブにやってくとハッピーだよ

• sanity(正気) check
• SAN値チェック!?
• あからさまな不整合がないか手早く確認していくこと
• サニティー・チェックの直訳は「正気確認」？──IT業界のカタカナ用語はくせ者ばかり：ITpro

コードの正しさは書いたテストの正しさと同じ程度にしかならない

テスト中にプライベートメソッドをsendで頻繁に呼び出す必要があったらリファクタリングのサイン

• モジュールにするとか
• 内部でしか使わないメソッドは隠蔽すべきだし、それの細かい挙動もテストしたい場合、send()は必要だと思うのだけどなぁ…
• プライベートメソッド、テスト駆動開発と優れたデザイン
  • テスト容易性を重視すべき
  • パプリックAPIに対してテストすべきで、それで足りないならコードが複雑なので、リファクタリングすべき

と、言うことらしい

TDDの最終成果物→仕様通りにメソッドが動作することを検証可能な、自動化されたセーフティーネット

• 問題発見、リファクタリング、イテレーティブな設計といったプロセスがTDDの真価
• 書かれたテストは副作用に過ぎず、TDDの本当の力は最初にテストを書くことで得られる洞察

1個のテストケースに複数のテストを書くより分けた方がよいよー

• どんな問題が起きたかすぐ分かる
• 個々のテストをクリーンな環境で実行できる

例外のテストを書いたら、例外じゃない場合のテストも書こう

XMLとか複雑な出力をテストする時はパーサーライブラリ使った方が、テストがはっきりするよ

• ライブラリがないなら、簡単なフォーマットだったらパーサー書いた方がよいよ
• パーサー書くのに時間かかりすぎるなら、期待する出力をファイルにしといてdiffした結果を出すと良いよ

まとめ

• 解決策をテストするのが難しいと感じたら、設計に柔軟性が足りず、リファクタリングや外部からの利用が難しいというサインかも
• 小さな機能毎にテストを書いてコードをリファクタリングすることで、複雑すぎるコードにありがちな落とし穴を回避できる
• どうしてもいろんな事情からテスト書きづらい場合もあるけど、それでも無いよりは少しでもあったほうがハッピーだよ!

感想

テストってこれらを保証する為に書いているイメージが強いけど

• 仕様を満たしていること
• 安心してリファクタリングできること
• デグレが発生しないこと

それだけじゃなくもう一歩進んで、テストを軸する実装を行うことで、より洗練された設計のコードになるよという話と解釈