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

Pat Maddox pergesu at gmail.com
Thu May 22 10:20:43 EDT 2008


Have you tried making it not call db:test:prepare?

On Thu, May 22, 2008 at 7:12 AM, Andrew Selder <aselder at mac.com> wrote:
> Downloaded the latest plugins from Github and got the same results.
>
> The spec rake task still ends up calling db:test:prepare which blows away
> the database and reloads only the schema.
>
> Thanks,
>
> Andrew
>
> On May 22, 2008, at 9:58 AM, David Chelimsky wrote:
>
>> On Thu, May 22, 2008 at 8:55 AM, Andrew Selder <aselder at mac.com> wrote:
>>>
>>> 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.
>>
>> AHA!
>>
>> CURRENT means the latest release, which is 1.1.3, which was released
>> months ago, before Rails 2.1 RC1.
>>
>> Try the latest from github:
>>
>> script/plugin install git://github.com/dchelimsky/rspec.git
>> script/plugin install git://github.com/dchelimsky/rspec-rails.git
>> script/generate rspec
>>
>> See if that makes any difference.
>>
>> Cheers,
>> David
>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


More information about the rspec-users mailing list