[Rspec-devel] Fwd: ActiveRecord fixtures support in RSpec

aslak hellesoy aslak.hellesoy at gmail.com
Mon Apr 24 17:59:10 EDT 2006

was sent to me

---------- Forwarded message ----------
From: Wilson Bilkovich <wilsonb at gmail.com>
Date: Apr 24, 2006 4:57 PM
Subject: Re: [Rspec-devel] ActiveRecord fixtures support in RSpec
To: aslak hellesoy <aslak.hellesoy at gmail.com>

On 4/24/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> I have taken a look at how we can integrate RSpec with ActiveRecord.
> Here is what I have found so far (with a little background for the
> non-rails internals savvy):
> When running Test::Unit tests for ActiveRecord objects, rails
> developers usually use fixtures, which puts the database in a known
> state as part of the setup() method. This known state is usually
> described in a rails app's test/fixtures/*.yml files.
> The code that reads these YAML files and puts the data in the database
> during setup() is implemented here:
> http://dev.rubyonrails.org/browser/trunk/activerecord/lib/active_record/fixtures.rb
> As you see, the code is very tightly coupled to Test::Unit (by opening
> the Test::Unit::TestCase class and adding class methods).
> In order to have RSpec work with ActiveRecord we have to be able to
> reuse this tightly coupled code. The way I see it now we have 2
> options:
> 1) Patch Rails
> Pull out the code that is coupled to Test::Unit and stick it in a
> module that can be included both by Test::Unit::TestCase and by
> whichever class we decide to do it from in RSpec (probably
> ExecutionContext).
> We'd have to produce a patch that is likely to be accepted by the
> rails team, which means that it should be 110% backwards compatible.
> 2) Write an adapter
> We can try to leave the Rails code untouched, and instead reimplement
> an identical API (fixtures, use_transactional_fixtures, etc) in RSpec
> and just have our implementation delegate to what's already in Rails.
> This would only delegate to the methods that set up and tear down the
> fixtures.
> While I think option 1 is cleaner I think it's potentially a tougher
> sell to the Rails team. I suggest we give our first stab at something
> akin to option 2.
> I know Steve and Eric have looked a little bit into this. What are
> your thoughts on 1 vs 2? Can anyone think of other options?
> Aslak

I've done some work in the guts of fixtures.rb, adding support for STI
naming conventions, etc, etc.
Given what I saw, I highly recommend #2, and I'd be glad to help.
My personal beef with the fixtures code is that it names fixtures
after the table name in the DB, rather than the model class.
class Yarr < ActiveRecord::Base
  set_table_name 'yoogle'
means that you can't just say:
fixtures :yarrs
..and expect it to work.

Supporting that at the same time might give RSpec another reason to
're-implement' fixtures.


More information about the Rspec-devel mailing list