- Controller が DB アクセスをするのを許すと、フローのテストが遅くなる
- DB アクセスが必要な処理は Model へ追いやる
- QUERY_STRING, ENV あたりを入力とする Controller のフローのテストと、DB や memcached を入力 とする Model のテストは分離するとテストしやすい
- Controller と Model, View などの API の切れ目で抽象化してテスト可能にしておくとやりやすいので、 切れ目をフレームワークで強制したり、運用ルールで縛ると最低限のテスト可能性が確保された設計に 落ち着けやすい
- Model も基本的には DB と分離してテスト可能なほうがいい。一方で、DB からデータを得ないテストだけになると
テストの意味が薄れる。ということで、M をルールの API で切れ目を作ってルール (ビジネスロジック的なやつ)
はそれ単体でテスト可能にする。ルールは原則状態を持たせない。
- ここを意識的に切り分けしながら M のテストができるなら、とくにルールを単体の別ファイルへと切り出す必要性はない (Transactional Script を目指してしまうと Web のサービス系だと構成が冗長になりがち) 。
- メソッドとして切り出してテスト可能にしておけるなら (そしてそれが全体の設計のバランスもよいのなら) 、それで OK
- 要は、memcached や DB から得られるグローバルな状態を入力として動く関数としてのロジックと、 状態を操作する部分が分離されてさえいればいい。
- ルールは別途テストされている前提で、DB アクセスを伴うテストは一連の処理をつなぐ流れのテスト
(モデルの中のフロー制御のテスト) として必要最小限を書く
- これをしないと、テストが整備されるにつれ、どんどんテストが重いのが課題になっていくので…