読者です 読者をやめる 読者になる 読者になる

maeshimaの日記

メモ書きです

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を作るべきという話。