Skip to content

Instantly share code, notes, and snippets.

@sunaot
Created October 11, 2011 10:33
Show Gist options
  • Save sunaot/1277789 to your computer and use it in GitHub Desktop.
Save sunaot/1277789 to your computer and use it in GitHub Desktop.
MVC な WAF でテストを書くときの設計方針

MVC な WAF でテストを書くための設計について

Controller から DB アクセスをしない

  • Controller が DB アクセスをするのを許すと、フローのテストが遅くなる
    • DB アクセスが必要な処理は Model へ追いやる
    • QUERY_STRING, ENV あたりを入力とする Controller のフローのテストと、DB や memcached を入力 とする Model のテストは分離するとテストしやすい
    • Controller と Model, View などの API の切れ目で抽象化してテスト可能にしておくとやりやすいので、 切れ目をフレームワークで強制したり、運用ルールで縛ると最低限のテスト可能性が確保された設計に 落ち着けやすい

Model も DB アクセスをなるべくしない形を目指す

  • Model も基本的には DB と分離してテスト可能なほうがいい。一方で、DB からデータを得ないテストだけになると テストの意味が薄れる。ということで、M をルールの API で切れ目を作ってルール (ビジネスロジック的なやつ) はそれ単体でテスト可能にする。ルールは原則状態を持たせない。
    • ここを意識的に切り分けしながら M のテストができるなら、とくにルールを単体の別ファイルへと切り出す必要性はない (Transactional Script を目指してしまうと Web のサービス系だと構成が冗長になりがち) 。
    • メソッドとして切り出してテスト可能にしておけるなら (そしてそれが全体の設計のバランスもよいのなら) 、それで OK
    • 要は、memcached や DB から得られるグローバルな状態を入力として動く関数としてのロジックと、 状態を操作する部分が分離されてさえいればいい。
  • ルールは別途テストされている前提で、DB アクセスを伴うテストは一連の処理をつなぐ流れのテスト (モデルの中のフロー制御のテスト) として必要最小限を書く
    • これをしないと、テストが整備されるにつれ、どんどんテストが重いのが課題になっていくので…
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment