Rake spec default environment

hi,

When I run rake spec , it seems to be starting with my default
environment (development or production) and connects to that
database, before actually connecting to the test one and proceeding
with the tests. When I remove the development database, the specs
wont run. How do i initiate rspec to be test environment from the
start? I dont see this when i run using script/spec

linoj

On Oct 29, 2007, at 9:04 AM, Jonathan L. wrote:

hi,

When I run rake spec , it seems to be starting with my default
environment (development or production) and connects to that
database, before actually connecting to the test one and proceeding
with the tests. When I remove the development database, the specs
wont run. How do i initiate rspec to be test environment from the
start? I dont see this when i run using script/spec

Well, usually the schema of the development database is copied to the
test one (you wouldn’t want to run 100 migrations just because you
fired up your test now, would you?)

Scott

On Oct 29, 2007, at 10:55 AM, Scott T. wrote:

start? I dont see this when i run using script/spec


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

That make sense now. Thanks.
– linoj

On Mon, 29 Oct 2007 10:55:32 -0400, Scott T. wrote:

Well, usually the schema of the development database is copied to the
test one (you wouldn’t want to run 100 migrations just because you
fired up your test now, would you?)

Scott

This has been discussed recently. If you’re doing true BDD, then you’re
going to be using the test env before you even venture into your dev
one.
Like you point out though, it poses a bit of a conundrum. Your tests are
run frequently, and having all those migrations run will slow things
down.
Yet it’s a PITA though to run my dev migrations when making changes
before
I run tests since I haven’t had need to run against that env yet.

On 10/29/07, Steve [email protected] wrote:

Like you point out though, it poses a bit of a conundrum. Your tests are
run frequently, and having all those migrations run will slow things down.
Yet it’s a PITA though to run my dev migrations when making changes before
I run tests since I haven’t had need to run against that env yet.

I don’t understand the dilemma here. Here’s what I do:

write a spec
watch it fail
decide to add or modify a model to get the spec to pass
write a migration
run migrations
run the specs

I don’t think to myself “gee, I’m running migrations and that’s my dev
env - I shouldn’t have to engage my dev env right now.” I just do it.

Simple, no?

Cheers,
David

Hey scott,
I’m running into this again

What I’m trying to do is avoid 2 database.yml files – one for my dev
machine, one for the deploy server –
by adding a new “staging” environment that is like “test” but on the
server
Since the server doesnt have a “development” env or db, the rake spec
fails
Is there a way to force the rake task to copy the schema from
“production” rather than “development”?

linoj

On Oct 29, 2007, at 9:04 AM, Jonathan L. wrote:

Database config aside, it turns out the issue was my spec_helper.rb
file contained:

ENV[“RAILS_ENV”] ||= “test”

I changed it to

ENV[“RAILS_ENV”] = “test”

–linoj

On Nov 20, 2007, at 12:25 AM, Jonathan L. wrote:

“production” rather than “development”?
Well, you could run the migrations with:

rake db:migrate RAILS_ENV=“staging”.

Check out capistrano to automate this stuff for you (and especially
the excellent capistrano-ext gem for deploying to different
environments).

Not sure why you would want to run your specs in another environment
called staging - but, if you really want to, you should look into
modifying spec_helper.rb to be less restrictive (currently it sets
RAILS_ENV = “test”). FixtureReplacement (which I know you are
using), also isn’t being included, which is something I’ve been
meaning to make configurable. (Patches welcome, as always).

Scott