I know the problem has been solved but you can supply global fixtures in
your spec_helper.rb file. This avoids having to repeat them for every
describe block.
Spec::Runner.configure do |config|
config.global_fixtures = :table_a, :table_b
end
Zach
On Wed, May 21, 2008 at 10:49 PM, Andrew Selder <[EMAIL PROTECTED]> wrote:
> Is it possible to specify that certain tables not be cleared on each
> example.
>
> I've inherited a project where a good amount of enumerated data is stored
> in the database (US States, statuses, about 15-20 tables worth. Over all,
> it's a reasonable decision that leads to solid production code
> (acts_as_enumerated is good). This data is read-only and relatively static;
> any changes to these tables are done via migrations.
>
> The problem comes when I'm writing my tests. Obviously all these tables get
> wiped with each example. Yes, I could specify these as fixtures, but I
> really don't want to have to specify 15-20 fixtures on every example. Yes, I
> could mock/stub all the values, except that I use many of these values at
> class definition time, which means that errors are thrown before I can even
> mock/stub.
>
> For instance, I have a statement like this.
>
> named_scope :open, :conditions => ["lead_status_id IN (?)", %w{New
> Incubating Client UAG}.collect{|x| LeadStatus[x].id}]
>
> Which loads the named_scope using the string version of the enumeration for
> clarity's sake. It works great, except for testing.
>
> Does anybody see anyway around this other than creating a fixture file for
> each of these tables and loading all the fixtures on each describe block.
> Not only does this make for ugly code, but I'm sure it takes a good chunk of
> time to setup and teardown each of the tables each example.
>
> It would be wonderful if there was some option to specify tables that
> behave like this, that should be loaded at the beginning of the test run,
> and (optionally) trashed at the end of the run. Or even better, specify that
> the test script shouldn't touch (build or teardown) these tables at all, and
> let their migrated state remain.
>
> Thanks,
>
> Andrew
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
--
Zach Dennis
http://www.continuousthinking.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
