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

Andrew Selder aselder at mac.com
Thu May 22 11:13:41 EDT 2008 

I tried modifying rspec.rake to read

spec_prereq = File.exist?(File.join(RAILS_ROOT, 'config',  
'database.yml')) ? [:testing, "db:test:purge", "db:migrate"] : :noop
task :noop do
end

task :testing do
   RAILS_ENV = ENV['RAILS_ENV'] = 'test'
end

which should do what I want, I think. However the db:migrate task  
blows up with a message:

rake aborted!
Mysql::Error: No database selected: SHOW TABLES
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/ 
active_record/connection_adapters/abstract_adapter.rb:151:in `log'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/ 
active_record/connection_adapters/mysql_adapter.rb:299:in `execute'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/ 
active_record/connection_adapters/mysql_adapter.rb:403:in `tables'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/ 
active_record/connection_adapters/abstract/schema_statements.rb:313:in  
`initialize_schema_migrations_table'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/ 
active_record/migration.rb:388:in `initialize'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/ 
active_record/migration.rb:357:in `new'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/ 
active_record/migration.rb:357:in `up'
/opt/local/lib/ruby/gems/1.8/gems/activerecord-2.0.991/lib/ 
active_record/migration.rb:340:in `migrate'
/opt/local/lib/ruby/gems/1.8/gems/rails-2.0.991/lib/tasks/ 
databases.rake:99

I examined the connection item and it is pointing to the right DB.  
It's strange since the db:migrate task work in isolation.

Anyway, for now I'll manually setup my db for test.

Thanks all,

Andrew

On May 22, 2008, at 10:25 AM, David Chelimsky wrote:

> On Thu, May 22, 2008 at 9: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.
>
> Well, thanks for trying.
>
> You can't be the first person to run up against this problem. I've run
> into it before but not in any rails apps I've worked on.
>
> Sounds like the solution would be something like what Scott and Ashley
> are talking about - introducing rake db:migrate or a custom data setup
> task after or instead of db:test:prepare.
>
>>
>> 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

More information about the rspec-users mailing list