In the original implementation, one could not truly use two different database connections: ActsAsFu would use ActiveRecord::Base’s connection, or setting ActsAsFu’s connection would change ActiveRecord::Base’s connection globally, breaking other tests.
To fix this, we created ActsAsFu::Connection, an abstract class that extends from ActiveRecord::Base. This segregates ActsAsFu’s database connection (to whatever database technology) from ActiveRecord::Base, and thus from the rest of the project.
Now you have no excuse for not test-driving your ActiveRecord
In your spec_helper.rb (pretty sure this works with Test::Unit
too, I’ll leave you to figure it out though)
Then in your specs:
describe "acts_as_gilmore_girls" do before(:each) do build_model :nerds do text :omg_omg_bio string :name string :favorite_scene validates_presence_of :favorite_scene def awesome?(show_name) show_name == "Gilmore Girls" end end end it "should require favorite scene" do nerd = Nerd.new :favorite_scene => nil nerd.should_not be_valid nerd.errors.on(:favorite_scene).should_not be_nil end it "should think gilmore girls is awesome" nerd = Nerd.new nerd.awesome?("Gilmore Girls").should be_true end it "has other stuff" do # ETC! end end
build_model method allows you to build an ActiveRecord model on
the fly. It takes a block where you can specify columns and methods.
If you want to create a model that’s a subclass of another, you can
Picture model will then be a subclass of the
If the in-memory sqlite3 database doesn’t suit your needs, you can
specify an alternative configuration with the
- Maybe a couple more options… maybe.
Despite the above example, watching Gilmore Girls doesn’t make you
a nerd. Probably.
© Copyright 2008 Pat Nakajima. All Rights Reserved.