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

32a7dd6ad1b55d5f11c76fe38bd6af69?d=identicon&s=25 Tadatoshi Takahashi (tadatoshi)
on 2009-03-25 20:18
(Received via mailing list)
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
32a7dd6ad1b55d5f11c76fe38bd6af69?d=identicon&s=25 Tadatoshi Takahashi (tadatoshi)
on 2009-03-25 20:29
Tadatoshi Takahashi 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?
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-03-25 21:31
(Received via mailing list)
On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi Takahashi
<lists@ruby-forum.com> 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 Eley (sfeley@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
32a7dd6ad1b55d5f11c76fe38bd6af69?d=identicon&s=25 Tadatoshi Takahashi (tadatoshi)
on 2009-03-25 22:49
Stephen Eley wrote:
> On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi Takahashi
> <lists@ruby-forum.com> 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 Eley (sfeley@gmail.com)
>    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
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-03-25 23:51
(Received via mailing list)
On Wed, Mar 25, 2009 at 5:49 PM, Tadatoshi Takahashi
<lists@ruby-forum.com> 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 Eley (sfeley@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2009-03-26 00:15
(Received via mailing list)
On Wed, Mar 25, 2009 at 2:49 PM, Tadatoshi Takahashi
<lists@ruby-forum.com> wrote:
> Stephen Eley wrote:
>> On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi Takahashi
>> <lists@ruby-forum.com> 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
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2009-03-27 15:13
(Received via mailing list)
On Wed, Mar 25, 2009 at 6:58 PM, Mark Wilden <mark@mwilden.com> 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 :)

Cheers,
David
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-03-27 21:27
(Received via mailing list)
On Fri, Mar 27, 2009 at 8:36 AM, David Chelimsky <dchelimsky@gmail.com>
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 :)

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 Eley (sfeley@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
32a7dd6ad1b55d5f11c76fe38bd6af69?d=identicon&s=25 Tadatoshi Takahashi (tadatoshi)
on 2009-03-27 21:50
Stephen Eley wrote:
> On Fri, Mar 27, 2009 at 8:36 AM, David Chelimsky <dchelimsky@gmail.com>
> 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 :)
>
> 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 Eley (sfeley@gmail.com)
>    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
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-03-28 00:04
(Received via mailing list)
On Fri, Mar 27, 2009 at 4:50 PM, Tadatoshi Takahashi
<lists@ruby-forum.com> 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 Eley (sfeley@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
32a7dd6ad1b55d5f11c76fe38bd6af69?d=identicon&s=25 Tadatoshi Takahashi (tadatoshi)
on 2009-03-28 05:19
Stephen Eley wrote:
> On Fri, Mar 27, 2009 at 4:50 PM, Tadatoshi Takahashi
> <lists@ruby-forum.com> 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 Eley (sfeley@gmail.com)
>    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
3880f04333bf8375b44cd6aa135406c7?d=identicon&s=25 Bart Zonneveld (Guest)
on 2009-03-28 22:20
(Received via mailing list)
On 27 mrt 2009, at 21:03, Stephen Eley 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
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-03-29 21:51
(Received via mailing list)
On Sat, Mar 28, 2009 at 4:49 PM, Bart Zonneveld
<zuperinfinite@gmail.com> 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 Eley (sfeley@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-03-30 09:40
(Received via mailing list)
On 29 Mar 2009, at 20:18, Stephen Eley 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 Wynne
http://beta.songkick.com
http://blog.mattwynne.net
5d38ab152e1e3e219512a9859fcd93af?d=identicon&s=25 David Chelimsky (Guest)
on 2009-03-30 15:26
(Received via mailing list)
On Mon, Mar 30, 2009 at 2:35 AM, Matt Wynne <matt@mattwynne.net> 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.
Cdf378de2284d8acf137122e541caa28?d=identicon&s=25 Matt Wynne (mattwynne)
on 2009-03-30 18:01
(Received via mailing list)
On 30 Mar 2009, at 13:23, David Chelimsky 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:
http://github.com/dchelimsky/rspec-rails/commit/d6...

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

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com
This topic is locked and can not be replied to.