RSpec-rails 1.2.2: autospec passes but "rake spec" fails

Testing RSpec
1

Hi,

I started to use RSpec and RSpec-rails 1.2.0 last week when I upgraded
to
Ruby on Rails 2.3.2.
At that time, “ruby script/generate rspec” hang but autospec and “rake
spec”
were successful.

Yesterday, I updated to RSpec and RSpec-rails 1.2.2.
This time, “ruby script/generate rspec” was successful with helpful
messages.
autospec is still successful.
But “rake spec” failed and it even overwritten the development database.
It appears that only the database tables with the fixtures that are
being
used are overwritten.

I could stop using fixtures all together.
But I would rather like to know how to resolve this problem.

Please let me know what I should do to resolve the problem.

Thank you in advance.

Tadatoshi

2

Tadatoshi T. wrote:

Hi,

I started to use RSpec and RSpec-rails 1.2.0 last week when I upgraded
to
Ruby on Rails 2.3.2.
At that time, “ruby script/generate rspec” hang but autospec and “rake
spec”
were successful.

Yesterday, I updated to RSpec and RSpec-rails 1.2.2.
This time, “ruby script/generate rspec” was successful with helpful
messages.
autospec is still successful.
But “rake spec” failed and it even overwritten the development database.
It appears that only the database tables with the fixtures that are
being
used are overwritten.

I could stop using fixtures all together.
But I would rather like to know how to resolve this problem.

Please let me know what I should do to resolve the problem.

Thank you in advance.

Tadatoshi

P.S.
It seems that autospec is run against test database and that “rake spec”
is run against development database.
How can I resolve this problem?

3

Stephen E. wrote:

On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi T.
[email protected] wrote:

P.S.
It seems that autospec is run against test database and that “rake spec”
is run against development database.
How can I resolve this problem?

The first thing I’d check would be whether you have RAILS_ENV defined
in your .profile or .bashrc or wherever. RSpec used to always declare
the ‘test’ environment, but the latest version of spec_helper.rb
declares it conditionally:

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

It shouldn’t be necessary to declare your environment as ‘development’
in the shell, because it’s usually the default. So if you have that
environment variable set somewhere, take it out.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Hi, Steve,

Thank you for your reply.

I have never set RAILS_ENV anywhere.
To make sure, I have looked at .profile but RAILS_ENV is not set there.

Is there any other place where that RAILS_ENV is getting set?

Thank you.

Tadatoshi

4

On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi T.
[email protected] wrote:

P.S.
It seems that autospec is run against test database and that “rake spec”
is run against development database.
How can I resolve this problem?

The first thing I’d check would be whether you have RAILS_ENV defined
in your .profile or .bashrc or wherever. RSpec used to always declare
the ‘test’ environment, but the latest version of spec_helper.rb
declares it conditionally:

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

It shouldn’t be necessary to declare your environment as ‘development’
in the shell, because it’s usually the default. So if you have that
environment variable set somewhere, take it out.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

5

On Wed, Mar 25, 2009 at 5:49 PM, Tadatoshi T.
[email protected] wrote:

I have never set RAILS_ENV anywhere.
To make sure, I have looked at .profile but RAILS_ENV is not set there.

Is there any other place where that RAILS_ENV is getting set?

I don’t know. But the way to test it from the command line would be:

echo $RAILS_ENV

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

6

On Wed, Mar 25, 2009 at 6:58 PM, Mark W. [email protected] wrote:

Is there any other place where that RAILS_ENV is getting set?

Check the rakefiles? Could someone have “improved” one? It happened to me.

You can also change spec_helper.rb to force the test environment with:

ENV[“RAILS_ENV”] = ‘test’

That’s what it used to do but somebody complained that it shouldn’t
force an environment :slight_smile:

Cheers,
David

7

On Fri, Mar 27, 2009 at 8:36 AM, David C. [email protected]
wrote:

You can also change spec_helper.rb to force the test environment with:
ENV[“RAILS_ENV”] = ‘test’
That’s what it used to do but somebody complained that it shouldn’t
force an environment :slight_smile:

Yeah. Running tests in the ‘test’ environment? What were you
thinking? That’s almost as ridiculous as expecting the ‘rails’
command to create a Rails app! >%-\

It might be that your positive comment on my Lighthouse ticket
yesterday is going to my head, but it seems to me that the arrow of
work here is backwards. The reason for having a generated skeleton,
including spec_helper.rb, is to give people sensible starter code with
defaults for sensible cases. 99% of Rails users are going to want to
run their Rspec behaviors in ‘test’ every time. Setting the
environment to ‘test’ is therefore sensible.

People with edge cases are more likely to know what they’re doing, and
should know that they can change that one line to add the ‘||=’ or
comment it out completely. The people who are most likely to be
impacted by the less forceful spec_helper are probably newer users who
don’t understand shells and environments quite as well, and might be
running in ‘one-click’ Rails setups that set the environment for them
without them knowing about it.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

8

On Wed, Mar 25, 2009 at 2:49 PM, Tadatoshi T.
[email protected] wrote:

Stephen E. wrote:

On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi T.
[email protected] wrote:

P.S.
It seems that autospec is run against test database and that “rake spec”
is run against development database.

Is there any other place where that RAILS_ENV is getting set?

Check the rakefiles? Could someone have “improved” one? It happened to
me.

///ark

9

Stephen E. wrote:

On Fri, Mar 27, 2009 at 8:36 AM, David C. [email protected]
wrote:

You can also change spec_helper.rb to force the test environment with:
�ENV[“RAILS_ENV”] = ‘test’
That’s what it used to do but somebody complained that it shouldn’t
force an environment :slight_smile:

Yeah. Running tests in the ‘test’ environment? What were you
thinking? That’s almost as ridiculous as expecting the ‘rails’
command to create a Rails app! >%-\

It might be that your positive comment on my Lighthouse ticket
yesterday is going to my head, but it seems to me that the arrow of
work here is backwards. The reason for having a generated skeleton,
including spec_helper.rb, is to give people sensible starter code with
defaults for sensible cases. 99% of Rails users are going to want to
run their Rspec behaviors in ‘test’ every time. Setting the
environment to ‘test’ is therefore sensible.

People with edge cases are more likely to know what they’re doing, and
should know that they can change that one line to add the ‘||=’ or
comment it out completely. The people who are most likely to be
impacted by the less forceful spec_helper are probably newer users who
don’t understand shells and environments quite as well, and might be
running in ‘one-click’ Rails setups that set the environment for them
without them knowing about it.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Thank you, David, Steve.

About Steve’s comment,
I may not be familiar with everything in Ruby on Rails but I am willing
to learn.
And I would like to know in which case it would be better to run RSpec
in an environment other than test one.
To me, I like clear separation of development, test, and production
environment in Ruby on Rails.
And I like to run Specs in test environment because for every run of a
spec (example), database is cleaned up and doesn’t affect the result of
running the next spec (example). And I don’t want the development
database to be cleaned up by running RSpec against it.
But that’s only my understanding.
If anybody could give me more insight about it, I would greatly
appreciate it.

Thank you.

Tadatoshi

10

Stephen E. wrote:

On Fri, Mar 27, 2009 at 4:50 PM, Tadatoshi T.
[email protected] wrote:

About Steve’s comment,
I may not be familiar with everything in Ruby on Rails but I am willing
to learn.

FWIW, I absolutely did not mean my comment as an insult, to you or
anybody else. I was going a bit more general, and wasn’t referring
specifically to you. Anyway, in my own head “new user” is never an
insult. Everybody starts there. It’s like insulting someone for
having been born.

And I would like to know in which case it would be better to run RSpec
in an environment other than test one.

I can see cases where some specialized behaviors might run in specific
environments – for instance, maybe you have a routine task in your
staging environment that copies data from the production environment,
etc. If those behaviors are non-trivial, it makes sense to spec and
test them. But if they’re initialized in your environment config
files, you’re then stuck either with doing backflips to try to fake
out Rails, or running your specs in that environment.

That’s just one hypothetical case off the top of my head. Doubtless
there are others that might be logical. (And a whole lot more that
wouldn’t be, but someone would surely try them anyway.)

To me, I like clear separation of development, test, and production
environment in Ruby on Rails.
And I like to run Specs in test environment because for every run of a
spec (example), database is cleaned up and doesn’t affect the result of
running the next spec (example). And I don’t want the development
database to be cleaned up by running RSpec against it.

And you’re absolutely right. On all of that. Anything different
would be an exception, not the rule. It sounds to me like you’re
pretty grounded in the principles of Rails – don’t sell yourself
short.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

Hi, Steve.

Thank you for your reply.
I am glad that I have learned a lot from your replies.

Sincerely,
Tadatoshi

11

On 27 mrt 2009, at 21:03, Stephen E. wrote:

run their Rspec behaviors in ‘test’ every time. Setting the
environment to ‘test’ is therefore sensible.

I very strongly disagree on this one. As it so happens, we’ve found a
bug in Passenger regarding uploads, umasks and permissions, which was
caused by Passenger overwriting the TMP_DIR environment variable. Took
us quite a while to figure this one out.

Even more, rake RAILS_ENV=development spec wouldn’t work as expected
when the env gets explicitly set from within a spec helper.

my 2cts,
bartz

12

On Fri, Mar 27, 2009 at 4:50 PM, Tadatoshi T.
[email protected] wrote:

About Steve’s comment,
I may not be familiar with everything in Ruby on Rails but I am willing
to learn.

FWIW, I absolutely did not mean my comment as an insult, to you or
anybody else. I was going a bit more general, and wasn’t referring
specifically to you. Anyway, in my own head “new user” is never an
insult. Everybody starts there. It’s like insulting someone for
having been born.

And I would like to know in which case it would be better to run RSpec
in an environment other than test one.

I can see cases where some specialized behaviors might run in specific
environments – for instance, maybe you have a routine task in your
staging environment that copies data from the production environment,
etc. If those behaviors are non-trivial, it makes sense to spec and
test them. But if they’re initialized in your environment config
files, you’re then stuck either with doing backflips to try to fake
out Rails, or running your specs in that environment.

That’s just one hypothetical case off the top of my head. Doubtless
there are others that might be logical. (And a whole lot more that
wouldn’t be, but someone would surely try them anyway.)

To me, I like clear separation of development, test, and production
environment in Ruby on Rails.
And I like to run Specs in test environment because for every run of a
spec (example), database is cleaned up and doesn’t affect the result of
running the next spec (example). And I don’t want the development
database to be cleaned up by running RSpec against it.

And you’re absolutely right. On all of that. Anything different
would be an exception, not the rule. It sounds to me like you’re
pretty grounded in the principles of Rails – don’t sell yourself
short.

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

13

On Sat, Mar 28, 2009 at 4:49 PM, Bart Z.
[email protected] wrote:

I very strongly disagree on this one. As it so happens, we’ve found a bug in
Passenger regarding uploads, umasks and permissions, which was caused by
Passenger overwriting the TMP_DIR environment variable. Took us quite a
while to figure this one out.

Weird. And a bit unfathomable to me why Passenger would have a need
to set a generic environment variable like that. I seem to recall
those guys have run into trouble with namespacing before. It seems
like a different case to me than Rails code setting RAILS_ENV.

Even more, rake RAILS_ENV=development spec wouldn’t work as expected when
the env gets explicitly set from within a spec helper.

My first question would be, why do you want to do that? What are you
doing in development mode that needs to be tested against separately
from other modes?

Second, assuming a good answer, why not just alter that line in
spec_helper.rb? It’s not like you have to go and fork the gem to
alter this behavior; configuration settings like this are what
spec_helper.rb is for. If you’re setting your environment on the
command line all the time then you must be clueful enough not to need
the same level of handholding.

But I’ll moderate my smartassishness just slightly: while I’m still in
favor of leaving spec_helper.rb with an explicit assignment to ‘test’,
perhaps a comment may be in order on the lines of:

This line ensures that RSpec will run in the ‘test’ environment

regardless of defaults set by other tools. If you have reasons to run

specs in other environments, you can allow this value to be overridden

by changing the line to:

ENV[‘RAILS_ENV’] ||= ‘test’

Then everybody who bothers to read spec_helper at least knows about
the issue and can make up their own minds. And as a side bonus,
really new Rubyists can learn something about the ||= operator. >8->
(Hey, everyone has a first time for seeing it. I first noticed it in
the restful_authentication plugin, IIRC, and now I use it all the
time.)

–
Have Fun,
Steve E. ([email protected])
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org

14

On 29 Mar 2009, at 20:18, Stephen E. wrote:

This line ensures that RSpec will run in the ‘test’ environment

regardless of defaults set by other tools. If you have reasons to

run

specs in other environments, you can allow this value to be

overridden

by changing the line to:

ENV[‘RAILS_ENV’] ||= ‘test’

Just to explain: I think it was me who asked for this, though the
change wasn’t in generated code, it was in a file in rspec-rails that
gets run when you require ‘spec/rails’. We use a ‘features’
environment for running our features (so we can run them in parallel
with specs) and it was causing some weird behaviour as the constant
was changing under our feet as the features (which use some rspec-
rails matchers) were run.

Matt W.

http://blog.mattwynne.net

15

On 30 Mar 2009, at 13:23, David C. wrote:

by changing the line to:

features (so we can run them in parallel with specs) and it was
causing some
weird behaviour as the constant was changing under our feet as the
features
(which use some rspec-rails matchers) were run.

What was the code doing to make the rspec-rails matchers available?

require ‘spec/rails’

There’s no reason you’d need to load ‘spec/spec_helper.rb’ to do that.

Maybe I’m getting two things mixed up, but I thought the change we
were talking about here was this commit:

I didn’t realise that the generated spec/spec_helper.rb file was also
going something similar.

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

16

On Mon, Mar 30, 2009 at 2:35 AM, Matt W. [email protected] wrote:

Just to explain: I think it was me who asked for this, though the change
wasn’t in generated code, it was in a file in rspec-rails that gets run when
you require ‘spec/rails’. We use a ‘features’ environment for running our
features (so we can run them in parallel with specs) and it was causing some
weird behaviour as the constant was changing under our feet as the features
(which use some rspec-rails matchers) were run.

What was the code doing to make the rspec-rails matchers available?
There’s no reason you’d need to load ‘spec/spec_helper.rb’ to do that.