On Oct 31, 2008, at 7:49 am, Matt W. wrote:
separate suite of tests for the database-object mappings that we run
when necessary.
I’m using DataMapper in a (non-web) project I have on now, and for
part of the spec suite where I am concerned with persistence as a
black-box, I create an in-memory SQLite database:
# story_spec.rb
describe "Class", Story do
# ...
describe ".unposted" do
include InMemoryDatabase
before(:each) do
setup_in_memory_database
@twitter_client = mock(TwitterAgent::Client, :post_story =>
true)
@story_1 = Story.create(:title => "Story title 1",
:published_at => DateTime.new(2008,
9, 28))
@story_2 = Story.create(:title => “Story title 2”,
:published_at => DateTime.new(2008,
9, 29))
@story_3 = Story.create(:title => “Story title 3”,
:published_at => DateTime.new(2008,
9, 27))
end
it "should find all stories (in ascending published date)
when none have been posted" do
Story.unposted.should == [ @story_3, @story_1, @story_2 ]
end
it "should find only unpublished stories (in ascending
published date)" do
@story_1.post_to_twitter!(@twitter_client)
Story.unposted.should == [ @story_3, @story_2 ]
end
end
end
# spec_helper.rb
module InMemoryDatabase
def setup_in_memory_database
DataMapper.setup(:default, "sqlite3::memory:")
Database::Migrator.new.reset_database!
end
end
Aside from being unable to use DB-lever constraints, that gives me
enough confidence in the persistence. Other specs that don’t need
persistence simply omit the “setup_in_memory_database” call.
It’s important not to lose sight of the fact that, even though
ActiveRecord mixes business logic and persistence, they are still
separate concerns.
Ashley
–
http://www.patchspace.co.uk/