Rpsec-rails overwriting RAILS_ENV?

Hi folks,

We have a “features” environment for Rails, where we run the Cucumber
stuff. This lets us run specs and features in different databases,
which can be handy.

I think I’ve found that rspec-rails 1.1.12 is doing something nasty to
the RAILS_ENV constant to force it to == “test”

Line 1 of vendor/gems/rspec-rails-1.1.12/lib/spec/rails.rb:

 silence_warnings { RAILS_ENV = "test" }

It seem like when I require this gem (which we use in the features
env) it’s clobbering my environment setting.

I’ve noticed this problem running a rake task:

 rake db:create RAILS_ENV=features

Where RAILS_ENV was changing back to “test” before the rake task ran!
and it’s definitely happening in spec/rails.

What was the intention behind making it so forceful? Would it be OK to
make it do something more like the following:

 RAILS_ENV ||= "test"

Shouldn’t we be leaving it up to rails to set this constant anyway?

cheers,
Matt

Matt W.
http://blog.mattwynne.net

On Thu, Jan 15, 2009 at 2:58 AM, Matt W. [email protected] wrote:

silence_warnings { RAILS_ENV = “test” }

It seem like when I require this gem (which we use in the features env) it’s
clobbering my environment setting.

Change require ‘spec’ to require ‘spec/expectations’ and you’ll be ok.

I’ve noticed this problem running a rake task:

rake db:create RAILS_ENV=features

Where RAILS_ENV was changing back to “test” before the rake task ran! and
it’s definitely happening in spec/rails.

What was the intention behind making it so forceful?

That was 2 years ago - I don’t remember the motivation.

Would it be OK to make
it do something more like the following:

RAILS_ENV ||= “test”

Shouldn’t we be leaving it up to rails to set this constant anyway?

As long as it works, that’s fine :slight_smile: Please enter a lighthouse ticket for
this.

Thanks,
David