Rails Models
Rails Model の spec の書き方について。
Rails Model
outside-in で実装してれば一番最後に実装するのが Model で、望ましい interface はもう決まっているはず。
26.1 Writing Model Specs
- model の spec を書くのは controller や view と比べて簡単。
- controllerやviewと同じように、model用のExampleGroupがあるみたい
- ActiveRecord::TestCaseをラップしたModelExampleGroupeというのがある。これによりfixtureのようなものにアクセスできたり、それぞれのexampleをtransactionを利用してDBの内容を保ったり出来る。
Making it real
話としては普通の spec の作り方なんだけど、気になるところがいくつかあった。
validation のチェック方法
例となる spec ファイルで
message.should be_valid
のようにして validation のチェックをしてる。これまでの自分のspecファイルでは error オブジェクトの中身をチェックしてたけどこれくらい簡単でもいいのかも。
invalid な attribute のチェック方法
before ブロックの中で valid な model オブジェクトを作成して、それぞれの example で attribute を invalid にしてテスト。
関連したmodelの設定
belongs_to なオブジェクトの mock_model を作成していた。これにより関連したmodelの影響を受けずに spec が書ける。
Specifying Business Rules
cucumberで実装したシナリオに沿ってspecを作っていく
Express business rules in models
ビジネスロジックよりもアプリケーションロジックの方が頻繁に変更される。model にビジネスロジックを押し込めれば、アプリケーションロジックが含まれる controlelr や view の変更がやりやすくなる。→ fat model。
そもそもビジネスロジックとアプリケーションロジックの意味が良くわかっていないのだけれど、
- アプリケーションロジック
- ユーザ側
- ビジネスロジック
- 開発者側
ってかんじでいいんだろうか?
26.4 Useful Tidbits
Db or Not Db
dbと繋げなくてもspecが書けるとスピード的な意味で効果あり。rspec-railsはその機能を提供してないけれど、UnitRecord とか NullDb 等のプラグインががある。それらはDBを使わずに、schema.rbから情報を得てmodelに情報を追加する。もちろんスピードよりも、実際にDBと繋げて動くかを確かめたいときもある。UnitRecordやNullDBは繋げたいときと繋げない時と両方の場合に使える。
これ実際の使い方も読みたかったなあ。
Test Data Builders
fixtureの代わりに下記のようなプラグインを使ってobjectを作る話。
- Fixjour
- FixtureReplacement
- FactoryGirl
- ObjectDaddy
- Machinist
Custom Macros
controllerの章で使っていたようなcustom macroのテクニックがmodelでも使えるという話。
Matchers
rspec-railsが提供しているmodel spec用のmatcher
be_valid
model.should be_valid model.should_not be_valid
error_on, errors_on
model.should have(:no).errors_on(:title) model.should have(1).error_on(:body) model.should have(2).errors_on(:caption)
reocord, recoreds
ModelClass.should have(:no).records ModelClass.should have(1).record
writing you own
重複していて、冗長な部分があれば自分でmatcherを作るべきという話。