Book読んだ後に残ってたメモ2012年09月04日リファクタリングリファクタリングとは、コードの振る舞いを変えずにその設計を変えること。コードの振る舞いが変わる場合、それはリファクタリングではない何か。テスト対象オブジェクトが、何であるかをテストするのは良くなく、何をするかをテストすることが重要。RDBMSを使って保存されることではなく、DBに保存されるということが重要。Refactorの順に行う。次に振る舞いを実装することで論理エラーを解消する。Refactorは常にGreenを維持するように努力を払いながら行う。その過程に冗長な実装が記述されることも厭わない。テストの粒度オブジェクトの振る舞いという観点でテストを記述できる。別の観点から、アプリケーションの振る舞いという観点でテストを記述できる。Cucumberが得意。粒度は揃えた方が良いので、この2つの観点を混同させてはいけない。やりやすいものから手を付けるのが正しい。テストをPending状態にするタイミングこれから変更を行うが、確実に失敗するテストが明確であり、それらの失敗を新たに発覚する失敗と混同したくない場合。BDDBDDは設計手法の1つであり、厳密には本物のアプリをテストしているわけではない。実行可能なサンプルをつくっているだけ。BDDの視点サービス提供者ではなくステークホルダーの視点の振る舞いを説明する。サービス提供者がステークホルダーに含まれることもある。TDDあると良いと思うコードをまず書く。サンプルが実際にテストするかどうかはそれほど重要ではない。振る舞いを説明することが重要。イベント出力テストの主語テストを表すメッセージにおいて、主語が誰かというのを明示することは大事。完了したことを知るのに十分な情報がある現実的に完了できる期限が付いているストーリーの構成要素タイトル(識別するため)ステークホルダーの望む機能とその理由いつ完了になるか分かる基準(前提とイベントと結果)。