2012年09月04日

The RSpec Book読んだ後に残ってたメモ

リファクタリングとは、コードの振る舞いを変えずにその設計を変えること。
コードの振る舞いが変わる場合、それはリファクタリングではない何か。

オブジェクトが、何であるかをテストするのは良くなく、何をするかをテストすることが重要。
例えば、RDBMSを使って保存されることではなく、DBに保存されるということが重要。

Red, Green, Refactorの順に行う。
Redから始まり、器を用意することで例外とエラーを解消し、
次に振る舞いを実装することで論理エラーを解消する。
Refactorは常にGreenを維持するように努力を払いながら行う。
その過程に冗長な実装が記述されることも厭わない。

オブジェクトの振る舞いという観点でテストを記述できる。RSpecが得意。
別の観点から、アプリケーションの振る舞いという観点でテストを記述できる。Cucumberが得意。
粒度は揃えた方が良いので、この2つの観点を混同させてはいけない。

ビジネスバリューの点から言えばどれからでも同じであるため、
最もやりやすいものから手を付けるのが正しい。

これから変更を行うが、確実に失敗するテストが明確であり、
それらの失敗を新たに発覚する失敗と混同したくない場合。

BDDは設計手法の1つであり、厳密には本物のアプリをテストしているわけではない。
ただ実行可能なサンプルをつくっているだけ。

サービス提供者ではなくステークホルダーの視点の振る舞いを説明する。
サービス提供者がステークホルダーに含まれることもある。

あると良いと思うコードをまず書く。
サンプルが実際にテストするかどうかはそれほど重要ではない。
振る舞いを説明することが重要。

テストを表すメッセージにおいて、主語が誰かというのを明示することは大事。