※週一ランチタイムの読書会 ikejirirb/POODR

やったこと

  • p237 ~ p263
  • 第9章費用対効果の高いテストを設計する ~ 9.2 受信メッセージをテストする

memo

  • p237

    • 変更可能性こそが設計時に唯一問題と鳴る指標です。
    • リファクタリングとは、ソフトウェアの外部の振る舞いを保ったままで、内部の構造を改善していく作業を指します
  • p238

    • リファクタリングでは新たな振る舞いを追加することはない
    • リファクタリングは小さくカニのような歩みでインクリメンタルに慎重にコードを変えていく厳密なプロセス crab
    • 変更可能なコードを書くためには、価値の高いテストを書く能力が求められる
    • テストの真の目的はコストの削減
  • p239

    • テストにコストが掛かることの解決方法は、テストをやめることではなく、テストを書くのをうまくなること
    • できることを初期段階で知ることは将来利用可能は設計の選択肢をかえるために、他の案を選択し直すきっかけになる
    • テストは唯一信頼できる設計の仕様書になる
    • 将来の自分は記憶喪失になっているとでも思ってテストを書こう
  • p240

    • 具体的なケースを単一の抽象として扱うコードによって、いつか報われるときが来ることは知っているものの、現時点ではその抽象がどんなものになるか予測するための十分な情報がない
    • 意図的にインターフェースに依存することに寄って、テストを使い、設計の決定を安全に代償もなく遅らせることができる
  • p240

    • 良い設計は自然と抽象に依存する独立した小さなObjectの集まりになる
  • p241

    • コードベースが拡大し幾つもの抽象が育っていくと、テストの重要性も一層ましていく
    • テストを書くのが大変なのであれば、他のObjectから見ても再利用が難しい
    • テストにコストがかかるカロ言って、必ずしもアプリの設計がまずいわけではない
  • p243

    • 一般規則として、Objectは、自信のパブリックインターフェースを構成するメッセージにたいしてのみ、状態についての表明を行うべき
  • p244

    • このような送信メッセージはクエリ(質問)として知られていて、送りてのObjectでテストされる必要はない
    • 受信メッセージは、その戻り値の状態がテストされるべき
  • p245

    • テストの価値を信じ続けることが大事
  • p246

    • 経験を積んだ設計者は、問題に対し「スパイクを打つ」ということを知っている
  • p251

    • 依存されていない、使われていないコードが見つかったら削除する

所感

将来の自分は記憶喪失になっているとでも思ってテストを書こう

ハイ!