From noreply at rubyforge.org  Thu Mar  1 06:02:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  1 Mar 2007 06:02:49 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8969 ] Evaluate
	"context_setup" blocks as soon as they are encountered
	(better compatibility with "dynamic" specs)
Message-ID: <20070301110249.9D9025240A2E@rubyforge.org>

Feature Requests item #8969, was opened at 2007-03-01 12:02
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8969&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Lee Noori (leenoori)
Assigned to: Nobody (None)
Summary: Evaluate "context_setup" blocks as soon as they are encountered (better compatibility with "dynamic" specs)

Initial Comment:
I'm posting this feature request as a follow-up to this mailing test post:

http://rubyforge.org/pipermail/rspec-users/2007-February/000854.html

The basic problem is that "context_setup" blocks may be run too late when setting up "dynamic" specs. The following example illustrates the problem if you have a "context_setup" block inside a context containing a dynamic specify block. Intuition might lead one to believe that it would be executed *before* the specs because it's labelled as a "setup" block and also because it appears physically before the "specify" block; however this is not the case:

context "The month march" do
   context_setup do
     @start = 1
     @max = 10
   end
   (@start.. at max).each do |n|
     specify "The root of #{n} square should be #{n}" do
       Math.sqrt(n*n).should == n
     end
   end
end

Here the "context_setup" block hasn't actually been evaluated by the time Ruby sees (and starts executing) the (@start.. at max).each block, so it doesn't work as intended. The workaround is to forget using "context_setup" and do the setup in the same scope as the following "specify" block:

context "The month march" do
   @start = 1
   @max = 10
   (@start.. at max).each do |n|
     specify "The root of #{n} square should be #{n}" do
       Math.sqrt(n*n).should == n
     end
   end
end

I suspect a robust fix would involve evaluating context_setup blocks  
as soon as they are encountered rather than deferring them until  
later.

At a minimum, the definition of the context_setup method (in lib/spec/runner/context_eval.rb) would need to be changed. Looks like the rest of the work would probably have to take place in lib/spec/runner/context.rb. I am not yet very familiar with the RSpec codebase but if one of the devs can provide some guidance I can have a shot at whipping together a patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8969&group_id=797

From noreply at rubyforge.org  Thu Mar  1 08:26:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  1 Mar 2007 08:26:09 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-8969 ] Evaluate
	"context_setup" blocks as soon as they are encountered
	(better compatibility with "dynamic" specs)
Message-ID: <20070301132610.1B8F05242006@rubyforge.org>

Feature Requests item #8969, was opened at 2007-03-01 11:02
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8969&group_id=797

>Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Lee Noori (leenoori)
Assigned to: Nobody (None)
>Summary: Evaluate "context_setup" blocks as soon as they are encountered (better compatibility with "dynamic" specs)

Initial Comment:
I'm posting this feature request as a follow-up to this mailing test post:

http://rubyforge.org/pipermail/rspec-users/2007-February/000854.html

The basic problem is that "context_setup" blocks may be run too late when setting up "dynamic" specs. The following example illustrates the problem if you have a "context_setup" block inside a context containing a dynamic specify block. Intuition might lead one to believe that it would be executed *before* the specs because it's labelled as a "setup" block and also because it appears physically before the "specify" block; however this is not the case:

context "The month march" do
   context_setup do
     @start = 1
     @max = 10
   end
   (@start.. at max).each do |n|
     specify "The root of #{n} square should be #{n}" do
       Math.sqrt(n*n).should == n
     end
   end
end

Here the "context_setup" block hasn't actually been evaluated by the time Ruby sees (and starts executing) the (@start.. at max).each block, so it doesn't work as intended. The workaround is to forget using "context_setup" and do the setup in the same scope as the following "specify" block:

context "The month march" do
   @start = 1
   @max = 10
   (@start.. at max).each do |n|
     specify "The root of #{n} square should be #{n}" do
       Math.sqrt(n*n).should == n
     end
   end
end

I suspect a robust fix would involve evaluating context_setup blocks  
as soon as they are encountered rather than deferring them until  
later.

At a minimum, the definition of the context_setup method (in lib/spec/runner/context_eval.rb) would need to be changed. Looks like the rest of the work would probably have to take place in lib/spec/runner/context.rb. I am not yet very familiar with the RSpec codebase but if one of the devs can provide some guidance I can have a shot at whipping together a patch.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-01 13:26

Message:
Hi Lee,

Thanks for posting this here rather than just on the mailing list. I have some thoughts about why I'd prefer not to do this right now, but this is the right place for any debate and to ensure that if/when the time is right we have the history.

In my view, what you're calling a workaround is actually the right way to go here. I see @start and @max as "spec generation" code, something akin to a pre-processor macro, which I would actually prefer to avoid mixing into the scope in which the spec gets executed.

On the other hand, the context_setup is intended to set up state that is expensive to set up, and therefore better off set up only once. Things like loading large data sets or starting browsers, in the case of 'spec/ui'.

To me, these are two separate concerns, which are causing confusion because they appear to be intermingled, but are never-the-less orthogonal.

The other reason is a bit more pragmatic. There have been numerous requests over time for some means of nesting contexts and/or specifications. To that end, I am exploring some alternative approaches to the inner workings of the runner, so I am hesitant to impose any new requirements on the runner right now.

Seeing as you are able to use the workaround, I'm going to defer this for now. But please feel free to keep the discussion going here while your thoughts are fresh.

Cheers,
David

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8969&group_id=797

From noreply at rubyforge.org  Thu Mar  1 11:15:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  1 Mar 2007 11:15:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6510 ] Named routes in
	controller specs
Message-ID: <20070301161533.BE5065242292@rubyforge.org>

Feature Requests item #6510, was opened at 2006-11-06 01:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6510&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Named routes in controller specs

Initial Comment:
[from RFE 5719 - Jonathan del Strother]

Being able to use named routes would be extremely useful - eg  
"get accounts_url"
or
"delete account_url(@account)"
(though it's perhaps worth noting that this doesn't even work in Rails' functional tests - you have to use integration
tests if you want this to work)

(this is a dup of  6501, but I was unable to move it from tracker to tracker, so I deleted that one and added this one)

----------------------------------------------------------------------

Comment By: Rodrigo Kochenburger (divoxx)
Date: 2007-03-01 13:15

Message:
I think this must be fixed.
Mostly because having some redirect_to some_url in the controller will also break the spec.
So it's not really a spec needs, but controller execution need.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6510&group_id=797

From noreply at rubyforge.org  Thu Mar  1 15:20:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  1 Mar 2007 15:20:34 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-6510 ] Named routes in
	controller specs
Message-ID: <20070301202034.6C90052422B0@rubyforge.org>

Feature Requests item #6510, was opened at 2006-11-05 19:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6510&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Named routes in controller specs

Initial Comment:
[from RFE 5719 - Jonathan del Strother]

Being able to use named routes would be extremely useful - eg  
"get accounts_url"
or
"delete account_url(@account)"
(though it's perhaps worth noting that this doesn't even work in Rails' functional tests - you have to use integration
tests if you want this to work)

(this is a dup of  6501, but I was unable to move it from tracker to tracker, so I deleted that one and added this one)

----------------------------------------------------------------------

Comment By: David Goodlad (dgoodlad)
Date: 2007-03-01 12:20

Message:
I've just run into this issue, although it's because I'm trying to spec out my named routes. It seems that ActionController::Base's normal behavior of using the current url's options and merging them with whatever is generated in url_for doesn't work, since AC::Base needs to have @url set to do that.

I worked around the problem in this case by doing a simple 'get' on one of my actions in setup first, but this is an ugly solution. We should have a way of specifying that the controller's "current url" is already set to something...

----------------------------------------------------------------------

Comment By: Rodrigo Kochenburger (divoxx)
Date: 2007-03-01 08:15

Message:
I think this must be fixed.
Mostly because having some redirect_to some_url in the controller will also break the spec.
So it's not really a spec needs, but controller execution need.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6510&group_id=797

From noreply at rubyforge.org  Fri Mar  2 07:34:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 07:34:17 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070302123417.1F7035242142@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 23:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: Nobody (None)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Fri Mar  2 07:45:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 07:45:32 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070302124532.2AD5F5242188@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 23:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: Nobody (None)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Fri Mar  2 07:48:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 07:48:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070302124829.669CA52421A7@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 12:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: Nobody (None)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Fri Mar  2 07:49:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 07:49:25 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070302124926.1AF325242208@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 23:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
>Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: Nobody (None)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:49

Message:
No, actually now that the errors have been resolved, the
original problem persists.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 23:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Fri Mar  2 07:59:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 07:59:11 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070302125911.A63125242188@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 12:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: Nobody (None)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:59

Message:
version please

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:49

Message:
No, actually now that the errors have been resolved, the
original problem persists.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From dchelimsky at gmail.com  Fri Mar  2 11:26:26 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 2 Mar 2007 10:26:26 -0600
Subject: [rspec-devel] [ANN] RSpec-0.8.2
Message-ID: <57c63afe0703020826s3914e94euc2aed83134d164b1@mail.gmail.com>

Announcing the release of rspec-0.8.2.

This should only affect a small number of you, but I re-wrote the
assert_select fork as a wrapper. The only effect this has on the API
is that :hide and :effect are not supported by "should have_rjs", as
they are not supported by assert_select_rjs.

You can, however, still use them both with "should_have_rjs" (with an
underscore between "should" and "have").

The reason for this change is that only a day after releasing 0.8, I
discovered that the specs for should have_rjs were failing against
edge rails. I quickly realized that it makes no sense for us to
maintain forks of anything in rails. I guess I knew that already, but
simply ignored my better judgment when writing the fork because I
wanted better messages (the failure messages in assert_select are not
that helpful).

Thanks for your patience w/ this.

David
The RSpec Development Team

From noreply at rubyforge.org  Fri Mar  2 11:41:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 11:41:44 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302164144.4599652411C8@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 12:21:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 12:21:01 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302172101.897095242301@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 16:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 17:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 12:38:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 12:38:44 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302173844.D6FBF5242270@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 19:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 12:39:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 12:39:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302173916.1BC215242270@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 19:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 13:08:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 13:08:29 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302180829.B73035242248@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 16:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 17:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 17:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 13:12:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 13:12:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302181257.2613A524224B@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 20:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 19:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 13:33:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 13:33:52 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302183352.D4048524224A@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 16:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:33

Message:
This looks good.

Although, I'm not comfortable adding these methods to the core classes. It's one thing to do that in your own app - it's another to do it in a tool that interacts with a lot of other apps. RSpec does add some extensions already, but we've pared it down to the bare minimum to avoid conflicts w/ the rest of the world.

I understand that means it becomes more procedural and less OO, but it's a fair tradeoff in my view.

If you want to send one more patch where everything is bottled up in be.rb, I'll be glad to add it. Otherwise I'll adjust on my end.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 18:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 17:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 17:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 14:36:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 14:36:47 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302193647.A31FF524225B@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 21:36

Message:
Yup, my fault. Here you are a new patch.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:33

Message:
This looks good.

Although, I'm not comfortable adding these methods to the core classes. It's one thing to do that in your own app - it's another to do it in a tool that interacts with a lot of other apps. RSpec does add some extensions already, but we've pared it down to the bare minimum to avoid conflicts w/ the rest of the world.

I understand that means it becomes more procedural and less OO, but it's a fair tradeoff in my view.

If you want to send one more patch where everything is bottled up in be.rb, I'll be glad to add it. Otherwise I'll adjust on my end.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 20:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 19:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 15:01:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 15:01:26 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070302200126.3546F5242208@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 23:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: Nobody (None)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-03 07:01

Message:
My apologies (I shouldn't post when it's late). Version is
0.8.0. Thanks.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 23:59

Message:
version please

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:49

Message:
No, actually now that the errors have been resolved, the
original problem persists.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 23:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Fri Mar  2 15:06:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 15:06:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070302200607.1920F524225A@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 12:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: Nobody (None)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:06

Message:
Did you run script/generate rspec? spec_helper.rb changed in 0.8. You now identify global_fixtures there and/or local fixtures in each spec.

Give that a shot and pls let me know if that does the trick.

Cheers,
David

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 20:01

Message:
My apologies (I shouldn't post when it's late). Version is
0.8.0. Thanks.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:59

Message:
version please

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:49

Message:
No, actually now that the errors have been resolved, the
original problem persists.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Fri Mar  2 15:13:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 15:13:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302201356.BC8065242208@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 16:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:13

Message:
Applied to rev 1562.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:36

Message:
Yup, my fault. Here you are a new patch.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:33

Message:
This looks good.

Although, I'm not comfortable adding these methods to the core classes. It's one thing to do that in your own app - it's another to do it in a tool that interacts with a lot of other apps. RSpec does add some extensions already, but we've pared it down to the bare minimum to avoid conflicts w/ the rest of the world.

I understand that means it becomes more procedural and less OO, but it's a fair tradeoff in my view.

If you want to send one more patch where everything is bottled up in be.rb, I'll be glad to add it. Otherwise I'll adjust on my end.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 18:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 17:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 17:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Fri Mar  2 15:14:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  2 Mar 2007 15:14:06 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070302201406.EF0A35242208@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 16:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
>Assigned to: David Chelimsky (dchelimsky)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:13

Message:
Applied to rev 1562.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:36

Message:
Yup, my fault. Here you are a new patch.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:33

Message:
This looks good.

Although, I'm not comfortable adding these methods to the core classes. It's one thing to do that in your own app - it's another to do it in a tool that interacts with a lot of other apps. RSpec does add some extensions already, but we've pared it down to the bare minimum to avoid conflicts w/ the rest of the world.

I understand that means it becomes more procedural and less OO, but it's a fair tradeoff in my view.

If you want to send one more patch where everything is bottled up in be.rb, I'll be glad to add it. Otherwise I'll adjust on my end.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 18:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 17:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 17:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From bkeepers at gmail.com  Fri Mar  2 18:42:43 2007
From: bkeepers at gmail.com (Brandon Keepers)
Date: Fri, 2 Mar 2007 18:42:43 -0500
Subject: [rspec-devel] multiple versions with the plugin
Message-ID: <7758F357-4B44-45AE-8CE1-5AD39916C530@gmail.com>

I have several projects that use older versions of rspec that I  
haven't had time to update.  This gets really annoying when I install  
the latest rspec gem and get this lovely warning when trying to run  
old specs:

######################################################################## 
####
Your RSpec on Rails plugin is incompatible with your installed RSpec.

RSpec          : 0.8.2 (r1560)
RSpec on Rails : r1395

Make sure your RSpec on Rails plugin is compatible with your RSpec gem.
See http://rspec.rubyforge.org/documentation/rails/install.html for  
details.
######################################################################## 
####


Since the rails plugin depends on a specific version of rspec, does  
anyone have any opposition to using gem (or require_gem for rubygems  
< 0.9) to explicitly state the version in the plugin so multiple  
versions  can be used side-by-side?

   gem 'rspec', '0.7.5.1'

This would need to go in spec/rails and the rake task.  Thoughts?

Brandon

From noreply at rubyforge.org  Sat Mar  3 10:46:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  3 Mar 2007 10:46:14 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070303154615.02D6F5242103@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: David Chelimsky (dchelimsky)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-03 17:46

Message:
One more patch:

a) be_ predicates with few words (like kind_of) are translating to "kind of" now
b) Be#description preserves used prefix (a or an) if it was used

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 22:13

Message:
Applied to rev 1562.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 21:36

Message:
Yup, my fault. Here you are a new patch.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:33

Message:
This looks good.

Although, I'm not comfortable adding these methods to the core classes. It's one thing to do that in your own app - it's another to do it in a tool that interacts with a lot of other apps. RSpec does add some extensions already, but we've pared it down to the bare minimum to avoid conflicts w/ the rest of the world.

I understand that means it becomes more procedural and less OO, but it's a fair tradeoff in my view.

If you want to send one more patch where everything is bottled up in be.rb, I'll be glad to add it. Otherwise I'll adjust on my end.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 20:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 19:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Sat Mar  3 10:49:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  3 Mar 2007 10:49:08 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070303154908.782E55242102@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: David Chelimsky (dchelimsky)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-03 17:49

Message:
One more patch:

a) be_ predicates with few words (like kind_of) are translating to "kind of" now
b) Be#description preserves used prefix (a or an) if it was used

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-03 17:46

Message:
One more patch:

a) be_ predicates with few words (like kind_of) are translating to "kind of" now
b) Be#description preserves used prefix (a or an) if it was used

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 22:13

Message:
Applied to rev 1562.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 21:36

Message:
Yup, my fault. Here you are a new patch.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:33

Message:
This looks good.

Although, I'm not comfortable adding these methods to the core classes. It's one thing to do that in your own app - it's another to do it in a tool that interacts with a lot of other apps. RSpec does add some extensions already, but we've pared it down to the bare minimum to avoid conflicts w/ the rest of the world.

I understand that means it becomes more procedural and less OO, but it's a fair tradeoff in my view.

If you want to send one more patch where everything is bottled up in be.rb, I'll be glad to add it. Otherwise I'll adjust on my end.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 20:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 19:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From jake.howerton at gmail.com  Sat Mar  3 13:45:38 2007
From: jake.howerton at gmail.com (Jake Howerton)
Date: Sat, 3 Mar 2007 13:45:38 -0500
Subject: [rspec-devel] multiple versions with the plugin
In-Reply-To: <7758F357-4B44-45AE-8CE1-5AD39916C530@gmail.com>
References: <7758F357-4B44-45AE-8CE1-5AD39916C530@gmail.com>
Message-ID: <218a05e40703031045y3f972e0by31abc29eac7e36a1@mail.gmail.com>

Brandon,

This is also one of my huge pet peeves about RSpec, and is something
that is constantly preventing me(and others) from working with it
efficiently.

It is my opinion that the RSpec on Rails plugin should get distributed
as a gem, and be applied to a rails app in a similar fashion to
Capistrano..

rspec_rails --apply-to=~/myapp

would add the appropriate files/directories and require statements,
including version number... this would allow you to continue to run
specs for applications that were spec'd with RSpec 0.7.5 even when you
upgrade to 0.8.

And if you want to test on 0.8 do rspec_rails --upgrade=~/myapp

WDYT?

Jake

On 3/2/07, Brandon Keepers <bkeepers at gmail.com> wrote:
> I have several projects that use older versions of rspec that I
> haven't had time to update.  This gets really annoying when I install
> the latest rspec gem and get this lovely warning when trying to run
> old specs:
>
> ########################################################################
> ####
> Your RSpec on Rails plugin is incompatible with your installed RSpec.
>
> RSpec          : 0.8.2 (r1560)
> RSpec on Rails : r1395
>
> Make sure your RSpec on Rails plugin is compatible with your RSpec gem.
> See http://rspec.rubyforge.org/documentation/rails/install.html for
> details.
> ########################################################################
> ####
>
>
> Since the rails plugin depends on a specific version of rspec, does
> anyone have any opposition to using gem (or require_gem for rubygems
> < 0.9) to explicitly state the version in the plugin so multiple
> versions  can be used side-by-side?
>
>    gem 'rspec', '0.7.5.1'
>
> This would need to go in spec/rails and the rake task.  Thoughts?
>
> Brandon
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sat Mar  3 13:48:50 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 3 Mar 2007 12:48:50 -0600
Subject: [rspec-devel] multiple versions with the plugin
In-Reply-To: <218a05e40703031045y3f972e0by31abc29eac7e36a1@mail.gmail.com>
References: <7758F357-4B44-45AE-8CE1-5AD39916C530@gmail.com>
	<218a05e40703031045y3f972e0by31abc29eac7e36a1@mail.gmail.com>
Message-ID: <57c63afe0703031048g7a6ca810u1795bd87ab46e10c@mail.gmail.com>

On 3/3/07, Jake Howerton <jake.howerton at gmail.com> wrote:
> Brandon,
>
> This is also one of my huge pet peeves about RSpec, and is something
> that is constantly preventing me(and others) from working with it
> efficiently.
>
> It is my opinion that the RSpec on Rails plugin should get distributed
> as a gem, and be applied to a rails app in a similar fashion to
> Capistrano..
>
> rspec_rails --apply-to=~/myapp
>
> would add the appropriate files/directories and require statements,
> including version number... this would allow you to continue to run
> specs for applications that were spec'd with RSpec 0.7.5 even when you
> upgrade to 0.8.
>
> And if you want to test on 0.8 do rspec_rails --upgrade=~/myapp
>
> WDYT?

This sounds like a great feature request! Please feel free to add it
to the tracker.

Thanks,
David


>
> Jake
>
> On 3/2/07, Brandon Keepers <bkeepers at gmail.com> wrote:
> > I have several projects that use older versions of rspec that I
> > haven't had time to update.  This gets really annoying when I install
> > the latest rspec gem and get this lovely warning when trying to run
> > old specs:
> >
> > ########################################################################
> > ####
> > Your RSpec on Rails plugin is incompatible with your installed RSpec.
> >
> > RSpec          : 0.8.2 (r1560)
> > RSpec on Rails : r1395
> >
> > Make sure your RSpec on Rails plugin is compatible with your RSpec gem.
> > See http://rspec.rubyforge.org/documentation/rails/install.html for
> > details.
> > ########################################################################
> > ####
> >
> >
> > Since the rails plugin depends on a specific version of rspec, does
> > anyone have any opposition to using gem (or require_gem for rubygems
> > < 0.9) to explicitly state the version in the plugin so multiple
> > versions  can be used side-by-side?
> >
> >    gem 'rspec', '0.7.5.1'
> >
> > This would need to go in spec/rails and the rake task.  Thoughts?
> >
> > Brandon
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sat Mar  3 13:57:06 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 3 Mar 2007 12:57:06 -0600
Subject: [rspec-devel] multiple versions with the plugin
In-Reply-To: <7758F357-4B44-45AE-8CE1-5AD39916C530@gmail.com>
References: <7758F357-4B44-45AE-8CE1-5AD39916C530@gmail.com>
Message-ID: <57c63afe0703031057l43f36128jd21d1472f04cc3d7@mail.gmail.com>

On 3/2/07, Brandon Keepers <bkeepers at gmail.com> wrote:
> I have several projects that use older versions of rspec that I
> haven't had time to update.  This gets really annoying when I install
> the latest rspec gem and get this lovely warning when trying to run
> old specs:
>
> ########################################################################
> ####
> Your RSpec on Rails plugin is incompatible with your installed RSpec.
>
> RSpec          : 0.8.2 (r1560)
> RSpec on Rails : r1395
>
> Make sure your RSpec on Rails plugin is compatible with your RSpec gem.
> See http://rspec.rubyforge.org/documentation/rails/install.html for
> details.
> ########################################################################
> ####

I'd recommend that you install rspec as a plugin as well in each of
your apps, getting it from the same tag that rspec_on_rails came from.
For example,

script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5_1/rspec
script/plugin install
svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5_1/rspec_on_rails/vendor/plugins/rspec_on_rails

Then you can use RSpec's rake tasks

  rake spec

or the spec command in your installed rspec:

  vendor/plugins/rspec/bin/spec spec

It's not a perfect solution because you can't use this with external
runners unless the installed gem matches. Now that we've gotten the
expectation syntax issues addressed, we should be able to focus more
energy on getting this to work more smoothly.

Cheers,
David

>
>
> Since the rails plugin depends on a specific version of rspec, does
> anyone have any opposition to using gem (or require_gem for rubygems
> < 0.9) to explicitly state the version in the plugin so multiple
> versions  can be used side-by-side?
>
>    gem 'rspec', '0.7.5.1'
>
> This would need to go in spec/rails and the rake task.  Thoughts?
>
> Brandon
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Sun Mar  4 00:01:02 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  4 Mar 2007 00:01:02 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070304050102.772435242340@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 12:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-04 05:01

Message:
I've verified that this works correctly if you update the spec_helper and assign your global fixtures like this:

module Spec
  module Rails
    module Runner
      class EvalContext < Test::Unit::TestCase
        self.use_transactional_fixtures = true
        self.use_instantiated_fixtures  = false
        self.fixture_path = RAILS_ROOT + '/spec/fixtures'

        self.global_fixtures = :table_a, :table_b
      end
    end
  end
end

I need to add something about this to the upgrade page. I'll leave this open until that is done.

David

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:06

Message:
Did you run script/generate rspec? spec_helper.rb changed in 0.8. You now identify global_fixtures there and/or local fixtures in each spec.

Give that a shot and pls let me know if that does the trick.

Cheers,
David

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 20:01

Message:
My apologies (I shouldn't post when it's late). Version is
0.8.0. Thanks.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:59

Message:
version please

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:49

Message:
No, actually now that the errors have been resolved, the
original problem persists.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Sun Mar  4 06:49:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  4 Mar 2007 06:49:36 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070304114936.7166C5240AC3@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 23:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: David Chelimsky (dchelimsky)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-04 22:49

Message:
Worked like a charm. I didn't see the self.global_fixtures
change. My apologies. I did look on the upgrade page so an
update to that would no-doubt help others.

Keep up the great work. Love it!

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-04 16:01

Message:
I've verified that this works correctly if you update the spec_helper and assign your global fixtures like this:

module Spec
  module Rails
    module Runner
      class EvalContext < Test::Unit::TestCase
        self.use_transactional_fixtures = true
        self.use_instantiated_fixtures  = false
        self.fixture_path = RAILS_ROOT + '/spec/fixtures'

        self.global_fixtures = :table_a, :table_b
      end
    end
  end
end

I need to add something about this to the upgrade page. I'll leave this open until that is done.

David

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-03 07:06

Message:
Did you run script/generate rspec? spec_helper.rb changed in 0.8. You now identify global_fixtures there and/or local fixtures in each spec.

Give that a shot and pls let me know if that does the trick.

Cheers,
David

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-03 07:01

Message:
My apologies (I shouldn't post when it's late). Version is
0.8.0. Thanks.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 23:59

Message:
version please

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:49

Message:
No, actually now that the errors have been resolved, the
original problem persists.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 23:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Sun Mar  4 06:51:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  4 Mar 2007 06:51:56 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070304115156.F04305240AC3@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 23:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: David Chelimsky (dchelimsky)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-04 22:51

Message:
Oh. One more thing. I had a look at the generator and
although the commented out example has the correct syntax,
for a doofus like me the comment:

# can do it in individual contexts using "fixtures :table_a,
table_b".

Should probably be

# can do it in individual contexts using
"self.global_fixtures :table_a, table_b".

Cheers,

Simon

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-04 22:49

Message:
Worked like a charm. I didn't see the self.global_fixtures
change. My apologies. I did look on the upgrade page so an
update to that would no-doubt help others.

Keep up the great work. Love it!

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-04 16:01

Message:
I've verified that this works correctly if you update the spec_helper and assign your global fixtures like this:

module Spec
  module Rails
    module Runner
      class EvalContext < Test::Unit::TestCase
        self.use_transactional_fixtures = true
        self.use_instantiated_fixtures  = false
        self.fixture_path = RAILS_ROOT + '/spec/fixtures'

        self.global_fixtures = :table_a, :table_b
      end
    end
  end
end

I need to add something about this to the upgrade page. I'll leave this open until that is done.

David

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-03 07:06

Message:
Did you run script/generate rspec? spec_helper.rb changed in 0.8. You now identify global_fixtures there and/or local fixtures in each spec.

Give that a shot and pls let me know if that does the trick.

Cheers,
David

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-03 07:01

Message:
My apologies (I shouldn't post when it's late). Version is
0.8.0. Thanks.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 23:59

Message:
version please

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:49

Message:
No, actually now that the errors have been resolved, the
original problem persists.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 23:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 23:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Sun Mar  4 11:01:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  4 Mar 2007 11:01:39 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8897 ] Error when mixing controller spec
	with/without integrated views and using template system other
	than rhtml
Message-ID: <20070304160139.53D7C5240AF0@rubyforge.org>

Bugs item #8897, was opened at 2007-02-26 20:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8897&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jonathan Tron (jonathant)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Error when mixing controller spec with/without integrated views and using template system other than rhtml

Initial Comment:
Whooo what a title !!

The problem is RoR does caching of template/template extension in test mode. So when RSpec stub ActionView methods, to run controller specs in isolation mode, it faint Rails about the presence of a template with an rhtml extension. Now, if you mix, for the same controller, specs in isolation mode and spec with integrated views or even for different controllers which shares some templates AND you use a template system using an extension other than rhtml you're in some trouble.

One solution is to disable caching in environment/test.rb :

config.action_view.cache_template_extensions         = false

An other solution would probably be to do it in Spec::Rails::Runner::ControllerContext only when running with integrated views, but it probably means clearing the cache in some way (stubbing ?).

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-04 16:01

Message:
Fixed in trunk rev 1565

THANK YOU, THANK YOU, THANK YOU!!!!

As it turns out, this solves a bug that was happening in rspec's specs only when run against edge rails or 1.1.6.

I've gone ahead and called this:

  ActionView::Base.cache_template_extensions = false

in EvalContext, meaning it will be set for all specs regardless of mode.

Personally, I don't see a problem w/ that. Do you?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8897&group_id=797

From noreply at rubyforge.org  Sun Mar  4 14:39:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  4 Mar 2007 14:39:15 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8897 ] Error when mixing controller spec
	with/without integrated views and using template system other
	than rhtml
Message-ID: <20070304193916.67A8552420CD@rubyforge.org>

Bugs item #8897, was opened at 26/02/2007 21:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8897&group_id=797

Category: rails plugin
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Jonathan Tron (jonathant)
Assigned to: David Chelimsky (dchelimsky)
Summary: Error when mixing controller spec with/without integrated views and using template system other than rhtml

Initial Comment:
Whooo what a title !!

The problem is RoR does caching of template/template extension in test mode. So when RSpec stub ActionView methods, to run controller specs in isolation mode, it faint Rails about the presence of a template with an rhtml extension. Now, if you mix, for the same controller, specs in isolation mode and spec with integrated views or even for different controllers which shares some templates AND you use a template system using an extension other than rhtml you're in some trouble.

One solution is to disable caching in environment/test.rb :

config.action_view.cache_template_extensions         = false

An other solution would probably be to do it in Spec::Rails::Runner::ControllerContext only when running with integrated views, but it probably means clearing the cache in some way (stubbing ?).

----------------------------------------------------------------------

>Comment By: Jonathan Tron (jonathant)
Date: 04/03/2007 20:39

Message:
Thank YOU !!! for all the work you do on RSpec :)

I don't see any problem with your solution, the speed
bottleneck will hardly come from this if there is one, so
everything is fine.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 04/03/2007 17:01

Message:
Fixed in trunk rev 1565

THANK YOU, THANK YOU, THANK YOU!!!!

As it turns out, this solves a bug that was happening in rspec's specs only when run against edge rails or 1.1.6.

I've gone ahead and called this:

  ActionView::Base.cache_template_extensions = false

in EvalContext, meaning it will be set for all specs regardless of mode.

Personally, I don't see a problem w/ that. Do you?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8897&group_id=797

From noreply at rubyforge.org  Sun Mar  4 17:15:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  4 Mar 2007 17:15:46 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] trunk: generated names for be_
	specs
Message-ID: <20070304221547.1426E5242033@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 18:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
>Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: David Chelimsky (dchelimsky)
Summary: trunk: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-03 17:49

Message:
One more patch:

a) be_ predicates with few words (like kind_of) are translating to "kind of" now
b) Be#description preserves used prefix (a or an) if it was used

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-03 17:46

Message:
One more patch:

a) be_ predicates with few words (like kind_of) are translating to "kind of" now
b) Be#description preserves used prefix (a or an) if it was used

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 22:13

Message:
Applied to rev 1562.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 21:36

Message:
Yup, my fault. Here you are a new patch.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:33

Message:
This looks good.

Although, I'm not comfortable adding these methods to the core classes. It's one thing to do that in your own app - it's another to do it in a tool that interacts with a lot of other apps. RSpec does add some extensions already, but we've pared it down to the bare minimum to avoid conflicts w/ the rest of the world.

I understand that means it becomes more procedural and less OO, but it's a fair tradeoff in my view.

If you want to send one more patch where everything is bottled up in be.rb, I'll be glad to add it. Otherwise I'll adjust on my end.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 20:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 19:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Sun Mar  4 23:06:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  4 Mar 2007 23:06:16 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-8994 ] generated names for be_ specs
Message-ID: <20070305040616.1B4725242100@rubyforge.org>

Patches item #8994, was opened at 2007-03-02 16:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

Category: expectation module
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: David Chelimsky (dchelimsky)
>Summary: generated names for be_ specs

Initial Comment:
As described at http://blog.railsware.com/2007/3/2/rspec-generated-spec-name-for-be attached you can find an ugly patch for this kind of functionality

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-05 04:06

Message:
Latest patch applied to rev 1566

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-03 15:49

Message:
One more patch:

a) be_ predicates with few words (like kind_of) are translating to "kind of" now
b) Be#description preserves used prefix (a or an) if it was used

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-03 15:46

Message:
One more patch:

a) be_ predicates with few words (like kind_of) are translating to "kind of" now
b) Be#description preserves used prefix (a or an) if it was used

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:13

Message:
Applied to rev 1562.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 19:36

Message:
Yup, my fault. Here you are a new patch.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:33

Message:
This looks good.

Although, I'm not comfortable adding these methods to the core classes. It's one thing to do that in your own app - it's another to do it in a tool that interacts with a lot of other apps. RSpec does add some extensions already, but we've pared it down to the bare minimum to avoid conflicts w/ the rest of the world.

I understand that means it becomes more procedural and less OO, but it's a fair tradeoff in my view.

If you want to send one more patch where everything is bottled up in be.rb, I'll be glad to add it. Otherwise I'll adjust on my end.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 18:12

Message:
Sorry, here you are a full patch :) 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 18:08

Message:
Looks like the patch is missing core_ext, which I'm guessing adds to_sentence to Array, no?

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-03-02 17:38

Message:
Oops, attaching it again 

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 17:21

Message:
Please attach the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=8994&group_id=797

From noreply at rubyforge.org  Mon Mar  5 01:21:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Mar 2007 01:21:59 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8991 ] Fixtures not loading from
	spec_helper
Message-ID: <20070305062159.40E6C524231A@rubyforge.org>

Bugs item #8991, was opened at 2007-03-02 12:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Simon Harris (haruki_zaemon)
Assigned to: David Chelimsky (dchelimsky)
Summary: Fixtures not loading from spec_helper

Initial Comment:
When I load fixtures from spec_helper.rb I get

NoMethodError in 'The Source File model should be valid when name and content root are present and unique'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]

However all the tests pass when I load the fixtures from the specs.

I'd rather not use fixtures but I've converted an entire application from standard rails tests to specs.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-05 06:21

Message:
Actually, that message is about local fixtures (i.e. declared in each context). I changed the message to read as below as of rev 1569.

I've also added a note to http://rspec.rubyforge.org/upgrade.html about re-generating the spec helper.

Closing this now. Thanks for the feedback.

David

===================================
# You can declare fixtures within each context like this:
#   context "...." do
#     fixtures :table_a, :table_b
# 
# Alternatively, if you prefer to declare them only once, you can
# do so here, using self.global_fixtures:
# 
# self.global_fixtures = :table_a, :table_b
# 
# If you declare global fixtures, be aware that they will be declared
# for all of your contexts, even those that don't use them.


----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-04 11:51

Message:
Oh. One more thing. I had a look at the generator and
although the commented out example has the correct syntax,
for a doofus like me the comment:

# can do it in individual contexts using "fixtures :table_a,
table_b".

Should probably be

# can do it in individual contexts using
"self.global_fixtures :table_a, table_b".

Cheers,

Simon

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-04 11:49

Message:
Worked like a charm. I didn't see the self.global_fixtures
change. My apologies. I did look on the upgrade page so an
update to that would no-doubt help others.

Keep up the great work. Love it!

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-04 05:01

Message:
I've verified that this works correctly if you update the spec_helper and assign your global fixtures like this:

module Spec
  module Rails
    module Runner
      class EvalContext < Test::Unit::TestCase
        self.use_transactional_fixtures = true
        self.use_instantiated_fixtures  = false
        self.fixture_path = RAILS_ROOT + '/spec/fixtures'

        self.global_fixtures = :table_a, :table_b
      end
    end
  end
end

I need to add something about this to the upgrade page. I'll leave this open until that is done.

David

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 20:06

Message:
Did you run script/generate rspec? spec_helper.rb changed in 0.8. You now identify global_fixtures there and/or local fixtures in each spec.

Give that a shot and pls let me know if that does the trick.

Cheers,
David

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 20:01

Message:
My apologies (I shouldn't post when it's late). Version is
0.8.0. Thanks.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:59

Message:
version please

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:49

Message:
No, actually now that the errors have been resolved, the
original problem persists.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-02 12:48

Message:
version?

----------------------------------------------------------------------

Comment By: Simon Harris (haruki_zaemon)
Date: 2007-03-02 12:45

Message:
Update: Actually what was happening is that errors
encountered while loading the fixtures were being
surpressed. So I'd suggest that be fixed but in general the
fixtures loading is working as advertised.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8991&group_id=797

From noreply at rubyforge.org  Mon Mar  5 06:21:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  5 Mar 2007 06:21:37 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8887 ] Should have RJS matches DOM IDs
	as substrings
Message-ID: <20070305112137.C28365240957@rubyforge.org>

Bugs item #8887, was opened at 2007-02-26 15:13
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8887&group_id=797

Category: rails plugin
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: David Chelimsky (dchelimsky)
Summary: Should have RJS matches DOM IDs as substrings

Initial Comment:
In RSpec 0.7.5.1, given:
    <div id="my_div" />

and RJS to insert a partial at the bottom of the div, the following spec passes:
    response.should_have_rjs :insert_html, :bottom, "my_div"

but so does this:
    response.should_have_rjs :insert_html, :bottom, "y_di"

because the string "y_di" is a substring of the ID.


Is this intended?  To create robust specs, you need to do this:
  response.should_have_rjs :insert_html, :bottom, /^my_div$/

which seems unintuitive.

----------------------------------------------------------------------

>Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-05 11:21

Message:
Ok cool.  I knew should_have_rjs was deprecated but I assumed "should 
have_rjs" would work the same way.  Haven't started tomove to the 0.8 syntax 
yet because I'm up to my ears in work.  Might wait for the spec update tool.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-26 17:09

Message:
should_have_rjs wraps a port of ARTS. This is how ARTS works.

Additionally, should_have_rjs is deprecated in favor of "should have_rjs" (no underscore between should and have), which is in the current trunk, in 0.8.0-RC1, and will be part of the 0.8 release, so we won't be making this change to improve "should_have_rjs".

"should have_rjs" wraps assert_select and will behave as you suggest that it should.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8887&group_id=797

From noreply at rubyforge.org  Tue Mar  6 09:21:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Mar 2007 09:21:16 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070306142117.07E7F52409A0@rubyforge.org>

Feature Requests item #9083, was opened at 2007-03-06 14:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: Nobody (None)
Summary: Allow ordering of expectations across mocks

Initial Comment:
I'd like to be able to write something like this:

context "Two mocks"
  setup do
    @mock_1 = mock("1")
    @mock_1.stub!(:moo)
    @mock_2 = mock("2")
    @mock_2.stub!(:quack)
  end

  specify "should receive their messages in a certain order"
    @mock_2.should_receive(:quack).after(@mock_1.receives(:moo))
  end
end

or something like that...


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

From noreply at rubyforge.org  Tue Mar  6 09:58:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Mar 2007 09:58:26 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070306145826.A2C295240A52@rubyforge.org>

Feature Requests item #9083, was opened at 2007-03-06 14:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

>Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Allow ordering of expectations across mocks

Initial Comment:
I'd like to be able to write something like this:

context "Two mocks"
  setup do
    @mock_1 = mock("1")
    @mock_1.stub!(:moo)
    @mock_2 = mock("2")
    @mock_2.stub!(:quack)
  end

  specify "should receive their messages in a certain order"
    @mock_2.should_receive(:quack).after(@mock_1.receives(:moo))
  end
end

or something like that...


----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-06 14:58

Message:
This sounds like mock abuse to me and I'm inclined not to support it in rspec. Can you give me a sense of the value you're looking for from this? A specific example maybe?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

From noreply at rubyforge.org  Tue Mar  6 11:03:45 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  6 Mar 2007 11:03:45 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070306160345.2DF63524206D@rubyforge.org>

Feature Requests item #9083, was opened at 2007-03-06 09:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: David Chelimsky (dchelimsky)
Summary: Allow ordering of expectations across mocks

Initial Comment:
I'd like to be able to write something like this:

context "Two mocks"
  setup do
    @mock_1 = mock("1")
    @mock_1.stub!(:moo)
    @mock_2 = mock("2")
    @mock_2.stub!(:quack)
  end

  specify "should receive their messages in a certain order"
    @mock_2.should_receive(:quack).after(@mock_1.receives(:moo))
  end
end

or something like that...


----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-06 11:03

Message:
I agree with David. This is bad use of mocking. It will lead to too brittle specs.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-06 09:58

Message:
This sounds like mock abuse to me and I'm inclined not to support it in rspec. Can you give me a sense of the value you're looking for from this? A specific example maybe?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

From noreply at rubyforge.org  Wed Mar  7 03:24:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  7 Mar 2007 03:24:37 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070307082437.DBB54524237B@rubyforge.org>

Feature Requests item #9083, was opened at 2007-03-06 14:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: David Chelimsky (dchelimsky)
Summary: Allow ordering of expectations across mocks

Initial Comment:
I'd like to be able to write something like this:

context "Two mocks"
  setup do
    @mock_1 = mock("1")
    @mock_1.stub!(:moo)
    @mock_2 = mock("2")
    @mock_2.stub!(:quack)
  end

  specify "should receive their messages in a certain order"
    @mock_2.should_receive(:quack).after(@mock_1.receives(:moo))
  end
end

or something like that...


----------------------------------------------------------------------

>Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-07 08:24

Message:
Hmm seems like I've been shot down on this!!!

I'm just searching for a way to spec that my database statements run in a 
transaction.  There was a suggestion posted on rspec-users that would involve 
monitoring the order of statments.

> This is bad use of mocking

Oh no, it can't be! ;) http://www.jmock.org/oopsla2004.pdf (section 3.4)

Maybe the ThoughtWorks team have revised their opinion on mock method 
ordering since 2004... but in that paper they present it as a valid technique.  
To my sleep-deprived eyes, I can't tell whether it looks suspect or not.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-06 16:03

Message:
I agree with David. This is bad use of mocking. It will lead to too brittle specs.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-06 14:58

Message:
This sounds like mock abuse to me and I'm inclined not to support it in rspec. Can you give me a sense of the value you're looking for from this? A specific example maybe?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

From noreply at rubyforge.org  Thu Mar  8 14:08:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  8 Mar 2007 14:08:42 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-9132 ] Rakefile spec:doc can fail
	without preparing database
Message-ID: <20070308190843.0030B5242129@rubyforge.org>

Patches item #9132, was opened at 2007-03-08 11:08
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9132&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: steve ross (cwd)
Assigned to: Nobody (None)
Summary: Rakefile spec:doc can fail without preparing database

Initial Comment:
Two issues addressed in this patch to rspec.rake:

1. specs fail because database is not prepared when running spec:doc
2. added task spec:appdoc so only specs for the app are run - not for plugins

N.b.: It might be better to name these spec:doc (just the application) and spec:doc_all (for everything) but I left that alone because I didn't want to break existing functionality.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9132&group_id=797

From noreply at rubyforge.org  Sat Mar 10 08:41:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Mar 2007 08:41:14 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9167 ] string.should have_tag
Message-ID: <20070310134114.905175240993@rubyforge.org>

Feature Requests item #9167, was opened at 2007-03-10 13:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9167&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: string.should have_tag

Initial Comment:
>From Tilmann Singer on the rspec-users mailing list:

Hi,

Is there a way to use the have_tag matcher on a string instead of the
response body from a view? I have a helper in a method rails project
that returns an html fragment which I would like to test.

Like this:

module SomeHelper
 def some_helper_method
   "<p>foo</p>"
 end
end

context "The SomeHelper"
 helper_name :some
 specify do
   some_helper_method.should have_tag("p", "foo")
 end
end



Til

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9167&group_id=797

From noreply at rubyforge.org  Sat Mar 10 08:50:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Mar 2007 08:50:09 -0500 (EST)
Subject: [rspec-devel] [ rspec-Feature Requests-9167 ] string.should have_tag
Message-ID: <20070310135009.3020352409AF@rubyforge.org>

Feature Requests item #9167, was opened at 2007-03-10 13:41
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9167&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: string.should have_tag

Initial Comment:
>From Tilmann Singer on the rspec-users mailing list:

Hi,

Is there a way to use the have_tag matcher on a string instead of the
response body from a view? I have a helper in a method rails project
that returns an html fragment which I would like to test.

Like this:

module SomeHelper
 def some_helper_method
   "<p>foo</p>"
 end
end

context "The SomeHelper"
 helper_name :some
 specify do
   some_helper_method.should have_tag("p", "foo")
 end
end



Til

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-10 13:50

Message:
Great idea Tilmann!

Added to trunk rev 1582

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9167&group_id=797

From noreply at rubyforge.org  Sat Mar 10 09:12:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Mar 2007 09:12:19 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-7637 ] [PATCH] add skip-migration
	option to rspec_resource generator
Message-ID: <20070310141220.0ED3652409BF@rubyforge.org>

Patches item #7637, was opened at 2007-01-07 00:35
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797

>Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Chris Anderson (jchris)
>Assigned to: David Chelimsky (dchelimsky)
Summary: [PATCH] add skip-migration option to rspec_resource generator 

Initial Comment:
it should have this option, just like the regular Test::Unit version of it.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-10 14:12

Message:
Applied (rev 1583)

----------------------------------------------------------------------

Comment By: Chris Anderson (jchris)
Date: 2007-01-29 01:41

Message:
Sorry, I haven't been keeping up with this ticket. The patch should be attached 
by now.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-18 17:14

Message:
Make sure you check the checkbox if you attach it again

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-07 01:03

Message:
Where's the file?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=7637&group_id=797

From noreply at rubyforge.org  Sat Mar 10 09:13:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Mar 2007 09:13:10 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-9132 ] Rakefile spec:doc can fail
	without preparing database
Message-ID: <20070310141310.D2AD352409BF@rubyforge.org>

Patches item #9132, was opened at 2007-03-08 19:08
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9132&group_id=797

>Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: steve ross (cwd)
Assigned to: Nobody (None)
Summary: Rakefile spec:doc can fail without preparing database

Initial Comment:
Two issues addressed in this patch to rspec.rake:

1. specs fail because database is not prepared when running spec:doc
2. added task spec:appdoc so only specs for the app are run - not for plugins

N.b.: It might be better to name these spec:doc (just the application) and spec:doc_all (for everything) but I left that alone because I didn't want to break existing functionality.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-10 14:13

Message:
Please submit the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9132&group_id=797

From noreply at rubyforge.org  Sat Mar 10 10:01:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Mar 2007 10:01:31 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-6541 ] catch-22 using named routes
Message-ID: <20070310150132.0216B5240A57@rubyforge.org>

Bugs item #6541, was opened at 2006-11-07 14:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Nobody (None)
>Assigned to: David Chelimsky (dchelimsky)
Summary: catch-22 using named routes

Initial Comment:
The recommended way specify controller redirects is to use

  controller.should_redirect_to 'path or hash'

*before* calling the action.

However, you cannot use named routes (XXX_url) until the action has been called (it gives 'rewrite' undefined for nil when it tries to call an instance variable in the controller).  

Can the mock be improved sufficiently to allow named routes to work in advance of the action? 

One workaround is to instantiate an ActionController::Integration::Session and delegate the named routes to that.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-10 15:01

Message:
controller.should_redirect_to is deprecated and will be removed in rspec 0.9.

The recommended way to spec redirects is now:

  response.should redirect_to(url)

This should be invoked after the action and does support using XXX_url or XXX_url(id).

I've updated the specs generated when you invoke script/generate rspec_resource to reflect this (trunk rev 1584).

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-19 12:48

Message:
Agreed that we should move the routing specs outside controller specs. I'll add a separate Feature Request for this. If you're satisfied w/ that, I'll leave it to you to close this bug.

We will eventually add a Story Runner for acceptance-level (high level integration) testing. In the mean time, what I do personally is use rails integtration testing with rspec's expectations. For 0.7.5 and prior, you just require 'spec'. For future versions you'll also have to include a module, but this will be explained when we release.

----------------------------------------------------------------------

Comment By: Eric Peden (ericpeden)
Date: 2007-01-19 10:11

Message:
You know, the more I think about it, the more I wonder if named routes should only appear in integration tests and not at all in specs. I'd also wanted to be able to do things like:

  get docs_url
  controller.should_render :template => 'docs/index'

but it does feel like I'm crossing boundaries by bringing routing into the controller spec, since routing is what connects the public interface of my app (namly, the URLs) with the semi-backend (the controllers). But I really like RSpec's should_ syntax and don't want to have to go back to asserts in my integration tests. ;)

----------------------------------------------------------------------

Comment By: Eric Peden (ericpeden)
Date: 2007-01-19 09:56

Message:
I'm of the opinion that simply setting expectations post-action is insufficient. For example, I have a case where I simply want to verify that a named route points to the correct url. I'd like to simply do:

  docs_url.should == 'http://test.host/applicant/first-last/docs'

without having to make a dummy call to the controller.

I have a patch that I think fixes this problem. I extend ActionController::Base so that its @url variable is accessible and then initialize that in context_extra. This is what initialize_current_url does; I'm just doing it earlier. This allows named routes to be called at any point in the spec. I've added a spec to verify the new behavior, but I'm not sure if it runs properly. I get scores of errors when trying to run the specs for the rspec_for_rails plugin.

I don't appear to be able to attach files to this request. Should I submit the patch in the patch tracker and then link to it here?


----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2006-12-07 16:05

Message:
I'd say you should set your expectations post-action:

response.should_be_redirect
response.redirect_url.should == my_named_url

----------------------------------------------------------------------

Comment By: Brandon Keepers (brandon)
Date: 2006-12-07 15:28

Message:
Does anyone have any suggestions for a workaround for this? I tried sending :initialize_current_url to my controller in the setup and that doesn't seem to do anything.

----------------------------------------------------------------------

Comment By: Jerry West (jjw)
Date: 2006-11-07 21:37

Message:
PS: 

def redirect
  controller.url_for(response.redirected_to)
end 

# that's because named routes return the path. While should_redirect_to takes paths, response.redirected_to is a Hash.  Yes, I know, I know, I've just found out about should_have_redirected_to or whatever it is.  I'm still coming to grips with the new equality rules and latest functionality!


----------------------------------------------------------------------

Comment By: Jerry West (jjw)
Date: 2006-11-07 21:25

Message:
Sorry, failing spec as requested...

----------------------------------------------------------
require File.dirname(__FILE__) + '/../spec_helper'

# just so we have something to test
class TestController < ApplicationController
  def index
    render :text => 'testing'   # don't look for view
  end
end # probably redundant with 0.7?

context "All controllers (via ApplicationController)" do  
  controller_name :test
  
  specify 'should redirect to login if protected page sought and not logged in' do
    controller.should_redirect_to login_url
    get :index
    controller.should_not_be_logged_in
    redirect.should == login_url
  end
end

----------------------------------------------------------

spec -fs spec/controllers/application_controller_spec.rb
/home/jjw/work/northants/config/environment.rb:31: warning: already initialized constant RAILS_CONNECTION_ADAPTERS
Creating sqlite in memory database...

All controllers (via ApplicationController)
- should redirect to login if protected page sought and not logged in (FAILED - 1)

1)
NoMethodError in 'All controllers (via ApplicationController) should redirect to login if protected page sought and not logged in'
You have a nil object when you didn't expect it!
The error occured while evaluating nil.rewrite
generated/routing/named_routes/login.rb:2:in `login_url'
./spec/controllers/application_controller_spec.rb:17:in `should redirect to login if protected page sought and not logged in'

Finished in 0.004108 seconds

1 specification, 1 failure

---------------------------------------------------------

commenting out the offending 'should_redirect_to' shows that the code itself is fine and login_url valid after the call to get:-

All controllers (via ApplicationController)
- should redirect to login if protected page sought and not logged in

Finished in 0.006735 seconds

1 specification, 0 failures

----------------------------------------------------------

Examining the code for ActionController::Base shows that the nil value is an unset instance variable (@url).  There is a method 'initialize_current_url' (line 927) which passes @request and @params to UrlRewriter.new, if that's any help.  

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-11-07 17:46

Message:
Could you please attach a failing spec as explained here?
http://rspec.rubyforge.org/contribute.html

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6541&group_id=797

From noreply at rubyforge.org  Sat Mar 10 10:13:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Mar 2007 10:13:01 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8145 ] fixture use in context_setup bails
Message-ID: <20070310151302.11BE252409C1@rubyforge.org>

Bugs item #8145, was opened at 2007-01-25 15:35
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8145&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jodi Showers (jodishowers)
>Assigned to: David Chelimsky (dchelimsky)
Summary: fixture use in context_setup bails

Initial Comment:
It appears that fixtures are not permissible within a context_setup.

context "Given a Project fixture, " do
  fixtures :projects

  context_setup do
    @project = projects(:project_one)
  end

....

end

Results:

1)
NoMethodError in 'Given a Project fixture,  context_setup'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]
./spec/models/project_spec.rb:56:



----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-10 15:13

Message:
context_setup is a bit confusing because it looks like it lives inside the context, but in reality it is processed BEFORE the context is processed. Just as setup is processed before each specify block. So what's really happening is:

context_setup {}
context "..." do
  setup {}
  specify do
    ...
  end
end

So I think that the problem here is one of documentation/perception.

WDYT?

David

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8145&group_id=797

From noreply at rubyforge.org  Sat Mar 10 11:16:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Mar 2007 11:16:12 -0500 (EST)
Subject: [rspec-devel] [ rspec-Patches-9132 ] Rakefile spec:doc can fail
	without preparing database
Message-ID: <20070310161612.3C9C752409FB@rubyforge.org>

Patches item #9132, was opened at 2007-03-08 11:08
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9132&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: steve ross (cwd)
Assigned to: Nobody (None)
Summary: Rakefile spec:doc can fail without preparing database

Initial Comment:
Two issues addressed in this patch to rspec.rake:

1. specs fail because database is not prepared when running spec:doc
2. added task spec:appdoc so only specs for the app are run - not for plugins

N.b.: It might be better to name these spec:doc (just the application) and spec:doc_all (for everything) but I left that alone because I didn't want to break existing functionality.

----------------------------------------------------------------------

>Comment By: steve ross (cwd)
Date: 2007-03-10 08:16

Message:
Ok, now the patch :)

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-10 06:13

Message:
Please submit the patch ;)

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9132&group_id=797

From noreply at rubyforge.org  Sat Mar 10 11:45:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 10 Mar 2007 11:45:57 -0500 (EST)
Subject: [rspec-devel] [ rspec-Bugs-8145 ] fixture use in context_setup bails
Message-ID: <20070310164557.1BF935240A03@rubyforge.org>

Bugs item #8145, was opened at 2007-01-25 10:35
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8145&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jodi Showers (jodishowers)
Assigned to: David Chelimsky (dchelimsky)
Summary: fixture use in context_setup bails

Initial Comment:
It appears that fixtures are not permissible within a context_setup.

context "Given a Project fixture, " do
  fixtures :projects

  context_setup do
    @project = projects(:project_one)
  end

....

end

Results:

1)
NoMethodError in 'Given a Project fixture,  context_setup'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]
./spec/models/project_spec.rb:56:



----------------------------------------------------------------------

>Comment By: Jodi Showers (jodishowers)
Date: 2007-03-10 11:45

Message:
yes. Given your explanation I agree that documentation would
help.

But first, I'd like to propose that if context_setup could
reference fixtures, and a transaction wrapped the entire
context, then a all specifies could share global 'context'.

My experience (not a lot mind you) so far with rspec, tells
me that a number of my specs would be less repetitive and
easier to group under contexts if I could have some fixtures
rollback (setup), and some persist across the entire context.

init_context #internal requirements for a context
Context.transaction do

  context_setup {}
  context "..." do
  setup {}
  specify do
    ...
  end
  end

end

+ since contexts currently don't give access to fixtures,
then this change wouldn't impact any current specs(?). But
perhaps it would break the design goals?

WDYT?

thanx for your inclusiveness David.
Jodi

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-10 10:13

Message:
context_setup is a bit confusing because it looks like it lives inside the context, but in reality it is processed BEFORE the context is processed. Just as setup is processed before each specify block. So what's really happening is:

context_setup {}
context "..." do
  setup {}
  specify do
    ...
  end
end

So I think that the problem here is one of documentation/perception.

WDYT?

David

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8145&group_id=797

From noreply at rubyforge.org  Mon Mar 12 12:55:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Mar 2007 12:55:46 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070312165546.99DAA5240B67@rubyforge.org>

Feature Requests item #9083, was opened at 2007-03-06 09:21
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: David Chelimsky (dchelimsky)
Summary: Allow ordering of expectations across mocks

Initial Comment:
I'd like to be able to write something like this:

context "Two mocks"
  setup do
    @mock_1 = mock("1")
    @mock_1.stub!(:moo)
    @mock_2 = mock("2")
    @mock_2.stub!(:quack)
  end

  specify "should receive their messages in a certain order"
    @mock_2.should_receive(:quack).after(@mock_1.receives(:moo))
  end
end

or something like that...


----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 12:55

Message:
Ironically I just found myself needing what you're asking for, so I guess it can't be abuse then ;-) (just like 3 of the JMock authors I am an ex-ThoughtWorker, and there was never an official TW opinion on mocking)


Anyway, It's easily achievable with a block (mocks take blocks in should_receive). Example:

foo.should_receive(:bar) do
  ping.should_receive(:pong)
end

This will only pass with foo.bar;ping.pong, and will fail with the opposite order.

Can you use this technique?


----------------------------------------------------------------------

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-07 03:24

Message:
Hmm seems like I've been shot down on this!!!

I'm just searching for a way to spec that my database statements run in a 
transaction.  There was a suggestion posted on rspec-users that would involve 
monitoring the order of statments.

> This is bad use of mocking

Oh no, it can't be! ;) http://www.jmock.org/oopsla2004.pdf (section 3.4)

Maybe the ThoughtWorks team have revised their opinion on mock method 
ordering since 2004... but in that paper they present it as a valid technique.  
To my sleep-deprived eyes, I can't tell whether it looks suspect or not.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-06 11:03

Message:
I agree with David. This is bad use of mocking. It will lead to too brittle specs.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-06 09:58

Message:
This sounds like mock abuse to me and I'm inclined not to support it in rspec. Can you give me a sense of the value you're looking for from this? A specific example maybe?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=9083&group_id=797

From noreply at rubyforge.org  Mon Mar 12 14:42:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Mar 2007 14:42:53 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-8696 ] --order option
Message-ID: <20070312184253.C7D275240B54@rubyforge.org>

Feature Requests item #8696, was opened at 2007-02-16 07:23
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8696&group_id=797

Category: runner / command line
Group: None
>Status: Closed
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: --order option

Initial Comment:
Right now, when spec is executed with a directory, the spec files are run in alphabetical order. I would like to be able to specify a custom order for several reasons:

First, because being able to run specs in say, reverse alphabetical order would allow me to identify potential dependencies between specs.

Second, because I sometimes want to run the most recently modified spec files first, so I can get early feedback. This is especially important for slow-running specs (such as Watir ones). At work we have monkey-patched Spec::Runner::Reporter to turn on a lamp at the first failure.

Unless someone wants more ordering options than alphabetical/timestamp and ascending/descending, I think it can be done like this:

--order alphabetical:ascending (default)
--order alphabetical:descending
--order timestamp:ascending
--order timestamp:descending


----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 14:42

Message:
Implemented in trunk r1592 as --reverse and --loadby

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=8696&group_id=797

From noreply at rubyforge.org  Mon Mar 12 19:24:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Mar 2007 19:24:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9232 ] ActionController::Base#render
	is sometimes protected
Message-ID: <20070312232405.28D885240B75@rubyforge.org>

Patches item #9232, was opened at 2007-03-12 19:24
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9232&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Dan Manges (dcmanges)
Assigned to: Nobody (None)
Summary: ActionController::Base#render is sometimes protected

Initial Comment:
ActionController::Base#render is protected.
That is, until ActionController::Layout is included in it; then it's public.

The problem is some plugins keep it protected by aliasing render with a protected method after ActionController::Layout makes it public.

It's probably an edge case, but the RSpec plugin should use 
@controller.send :render, options

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9232&group_id=797

From noreply at rubyforge.org  Mon Mar 12 22:15:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Mar 2007 22:15:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9235 ] No longer able to execute single
	spec
Message-ID: <20070313021541.100725240B77@rubyforge.org>

Bugs item #9235, was opened at 2007-03-12 19:15
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9235&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Josh Knowles (joshknowles)
Assigned to: Nobody (None)
Summary: No longer able to execute single spec

Initial Comment:
Running edge-rspec with edge-rspec-on-rails.  Something in the last 24hrs caused me to be unable to run a single spec on its own via command-line or apple-r.  Exception as follows:

/Users/joshknowles/Development/Projects/integrum/bootstrap/config/../vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:15:in `run': wrong number of arguments (1 for 2) (ArgumentError)
	from /Users/joshknowles/Development/Projects/integrum/bootstrap/config/../vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:15:in `context_runner'
	from /Users/joshknowles/Development/Projects/integrum/bootstrap/spec/models/user_authentication_spec.rb:29


Heading off to debug now, but figured I'd throw this up here in case anyone else has already seen this error.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9235&group_id=797

From noreply at rubyforge.org  Mon Mar 12 22:54:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 12 Mar 2007 22:54:49 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9232 ] ActionController::Base#render
	is sometimes protected
Message-ID: <20070313025449.584055240B7C@rubyforge.org>

Patches item #9232, was opened at 2007-03-12 19:24
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9232&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Dan Manges (dcmanges)
Assigned to: Nobody (None)
Summary: ActionController::Base#render is sometimes protected

Initial Comment:
ActionController::Base#render is protected.
That is, until ActionController::Layout is included in it; then it's public.

The problem is some plugins keep it protected by aliasing render with a protected method after ActionController::Layout makes it public.

It's probably an edge case, but the RSpec plugin should use 
@controller.send :render, options

----------------------------------------------------------------------

>Comment By: Dan Manges (dcmanges)
Date: 2007-03-12 22:54

Message:
Rails trunk was just updated for consistency to keep #render
protected.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9232&group_id=797

From noreply at rubyforge.org  Tue Mar 13 07:13:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 07:13:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9235 ] No longer able to execute single
	spec
Message-ID: <20070313111341.C5AC05240B92@rubyforge.org>

Bugs item #9235, was opened at 2007-03-12 22:15
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9235&group_id=797

Category: rails plugin
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Josh Knowles (joshknowles)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: No longer able to execute single spec

Initial Comment:
Running edge-rspec with edge-rspec-on-rails.  Something in the last 24hrs caused me to be unable to run a single spec on its own via command-line or apple-r.  Exception as follows:

/Users/joshknowles/Development/Projects/integrum/bootstrap/config/../vendor/plugins/rspec/lib/spec/runner/extensions/kernel.rb:15:in `run': wrong number of argum