rspec users - Mar 2009 - RSpec-rails 1.2.2: autospec passes but "rake spec" fails

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20090325/eabebe63/attachment-0001.html>

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?
-- 
Posted via http://www.ruby-forum.com/.

On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi Takahashi
<lists at 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 at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

Stephen Eley wrote:
> On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi Takahashi
> <lists at 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 at 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

-- 
Posted via http://www.ruby-forum.com/.

On Wed, Mar 25, 2009 at 5:49 PM, Tadatoshi Takahashi
<lists at 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 at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

On Wed, Mar 25, 2009 at 2:49 PM, Tadatoshi Takahashi
<lists at ruby-forum.com> wrote:
> Stephen Eley wrote:
>> On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi Takahashi
>> <lists at 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

On Wed, Mar 25, 2009 at 6:58 PM, Mark Wilden <mark at mwilden.com>
wrote:
> On Wed, Mar 25, 2009 at 2:49 PM, Tadatoshi Takahashi
> <lists at ruby-forum.com> wrote:
>> Stephen Eley wrote:
>>> On Wed, Mar 25, 2009 at 3:29 PM, Tadatoshi Takahashi
>>> <lists at 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.
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
>
> ///ark
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Fri, Mar 27, 2009 at 8:36 AM, David Chelimsky <dchelimsky at 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 at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

Stephen Eley wrote:
> On Fri, Mar 27, 2009 at 8:36 AM, David Chelimsky <dchelimsky at
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 at 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
-- 
Posted via http://www.ruby-forum.com/.

On Fri, Mar 27, 2009 at 4:50 PM, Tadatoshi Takahashi
<lists at 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 at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

Stephen Eley wrote:
> On Fri, Mar 27, 2009 at 4:50 PM, Tadatoshi Takahashi
> <lists at 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 at 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

-- 
Posted via http://www.ruby-forum.com/.

On 27 mrt 2009, at 21:03, Stephen Eley wrote:
> On Fri, Mar 27, 2009 at 8:36 AM, David Chelimsky  
> <dchelimsky at 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 :)
>
> 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.
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

On Sat, Mar 28, 2009 at 4:49 PM, Bart Zonneveld <zuperinfinite at
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 at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

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

On Mon, Mar 30, 2009 at 2:35 AM, Matt Wynne <matt at mattwynne.net>
wrote:
>
> 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.
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.
>
> Matt Wynne
> http://beta.songkick.com
> http://blog.mattwynne.net
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 30 Mar 2009, at 13:23, David Chelimsky wrote:
> On Mon, Mar 30, 2009 at 2:35 AM, Matt Wynne <matt at mattwynne.net>  
> wrote:
>>
>> 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.
>
> 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/d6af98c1ffd992d81723fba70f5da9fbbb9e0a58

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