[rspec-users] Specifying certain tables NOT to be cleared each example?

Andrew Selder aselder at mac.com
Thu May 22 09:55:28 EDT 2008


David,

The static data generated in the migrations in being wiped away.

I did a
rake db:test:purge

followed by

rake db:migrate RAILS_ENV=test

and then looked in my database to verify that the data was there and  
it was.

And then when I run rake spec, the test blow up and I looks at the DB  
and all the static tables are empty.

Looking at the rspec.rake file in the rspec_on_rails plugin, the spec  
task calls the spec_prereq task. This task does a db:test:prepare,  
which looking at the source for that in the rails gem only copies the  
schema from the development db.

I'm using Rails 2.1 RC1, and the tagged CURRENT version of both plugins.

Thanks,

Andrew

On May 22, 2008, at 9:32 AM, David Chelimsky wrote:

> On May 21, 2008, at 9:49 PM, Andrew Selder 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.
>
> This should not be the case. Transactions get rolled back, but  
> tables do not just get wiped clean.
>
> If this static data is being generated in migrations, then you  
> should be OK. Is it?
>
>> 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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users



More information about the rspec-users mailing list