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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
