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 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  Tue Mar 13 07:23:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 07:23:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9235 ] No longer able to execute single
	spec
Message-ID: <20070313112320.547FB5240990@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: Closed
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 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.


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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 07:23

Message:
Fixed in r1593

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

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

From noreply at rubyforge.org  Tue Mar 13 07:30:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 07:30:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9232 ] ActionController::Base#render
	is sometimes protected
Message-ID: <20070313113019.9BB255240990@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: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 07:30

Message:
Fixed on trunk (r1594)

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

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:30:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 07:30:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9232 ] ActionController::Base#render
	is sometimes protected
Message-ID: <20070313113036.615F55240990@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: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Dan Manges (dcmanges)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
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: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 07:30

Message:
Fixed on trunk (r1594)

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

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 08:22:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 08:22:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-8113 ] Better Watir exception for bad
	URLs
Message-ID: <20070313122227.057525240B9A@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Better Watir exception for bad URLs

Initial Comment:
class Watir::Browser
  def kill!
    close
  end
  
  alias contain_text? contains_text

  alias old_goto goto
  def goto(url)
    begin
      old_goto(url)
    rescue => e
      e.message << "\nURL: #{url}"
      raise e
    end
  end
end


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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 08:22

Message:
Applied (r1596)

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-24 13:08

Message:
A good tip - monkey patch the watir stuff in your spec_helper.rb

module Spec
  module Ui
    class WebappHelper
      def context_setup
        quick_db_web
        @browser = Watir::Browser.new
        ::Win32::Screenshot.setForegroundWindow(ie.getIE.hwnd)
      end
    end
  end
end
require 'spec/ui/watir_helper'

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-24 10:39

Message:
Add this too, to webapp_helper.rb (and remove it from the rake)

      raise "$RSPEC_IMG_DIR must be defined" if ENV['RSPEC_IMG_DIR'].nil?
      FileUtils.mkdir_p(ENV['RSPEC_IMG_DIR']) unless File.exist?(ENV['RSPEC_IMG_DIR'])


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

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

From noreply at rubyforge.org  Tue Mar 13 10:49:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 10:49:42 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070313144942.5D8775240BAC@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-13 14:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 16: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 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  Tue Mar 13 11:19:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 11:19:30 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070313151931.389C1524096F@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-13 11:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 10:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

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  Tue Mar 13 13:08:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 13:08:03 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9260 ] IvarProxy does not act like a hash
Message-ID: <20070313170803.ED2155240BB7@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: IvarProxy does not act like a hash

Initial Comment:
undefined method `delete' for #<Spec::Rails::Expectations::IvarProxy:0xb6ede840>

This happened in a Helper Spec. Here is the code to reproduce this.

mab = Markaby::Builder.new(assigns_hash, self)

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

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

From noreply at rubyforge.org  Tue Mar 13 13:13:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 13:13:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9260 ] IvarProxy does not act like a hash
Message-ID: <20070313171309.33EB15240BAD@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: IvarProxy does not act like a hash

Initial Comment:
undefined method `delete' for #<Spec::Rails::Expectations::IvarProxy:0xb6ede840>

This happened in a Helper Spec. Here is the code to reproduce this.

mab = Markaby::Builder.new(assigns_hash, self)

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

>Comment By: Brian Takita (btakita)
Date: 2007-03-13 10:13

Message:
Here is a fix I used without specs (my specs pass now):

class Spec::Rails::Expectations::IvarProxy
  def delete(name)
    @object.send(:remove_instance_variable, "@#{name}") if
@object.instance_variables.include?("@#{name}")
  end

  def each
    @object.instance_variables do |var|
      yield @object.instance_variable_get(var)
    end
  end
end

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

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

From noreply at rubyforge.org  Tue Mar 13 15:37:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 13 Mar 2007 15:37:03 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9265 ] [Documentation] These are NOT
	deprecated. See Spec::Matchers should not be red
Message-ID: <20070313193703.D22E65240BBB@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: [Documentation] These are NOT deprecated. See Spec::Matchers should not be red

Initial Comment:
It is confusing to see "These are NOT deprecated. See Spec::Matchers" in red text because it looks like it is being deprecated.

Perhaps it should be green?

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

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

From noreply at rubyforge.org  Wed Mar 14 06:05:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 06:05:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9278 ] Ajax auto-refresh in
	HTML report
Message-ID: <20070314100510.D68FC5240C06@rubyforge.org>

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

Category: reports
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Ajax auto-refresh in HTML report

Initial Comment:
We're using RSpec to run a long-running suite (over 300 watir specs).

We're keeping the HTML report open, and we'd like to have it auto-refresh so that we can see the progress without refreshing the browser.

This should be fairly easy to do with Ajax and an IFrame I think....

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

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

From noreply at rubyforge.org  Wed Mar 14 06:39:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 06:39:03 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070314103903.D76015240C08@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-14 10:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 15:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 14:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 16: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 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  Wed Mar 14 06:46:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 06:46:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070314104632.E5C7E5240C08@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-14 06:46

Message:
If you are writing controller specs, you should just stub the save! method and be done with it (stub/mock at the interface level).

Then, in a model spec you can verify the unstubbed save! method by running against the database.

Makes sense?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 06:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 11:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 10:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

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  Wed Mar 14 10:51:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 10:51:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9282 ] Change to allow running specs
	from textmate with rspec installed as a rails plugin (and no
	rspec gem installed)
Message-ID: <20070314145127.3CC545240C1E@rubyforge.org>

Patches item #9282, was opened at 14/03/2007 15:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9282&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jonathan Tron (jonathant)
Assigned to: Nobody (None)
Summary: Change to allow running specs from textmate with rspec installed as a rails plugin  (and no rspec gem installed)

Initial Comment:
I changed all require call to use a full path based on File.dirname(__FILE__).
I modified the spec_mate.rb of RSpec.tmbundle to look for rspec as a rails plugins (check if ENV['TM_PROJECT_DIRECTORY'] and ENV['TM_PROJECT_DIRECTORY']/vendor/plugins/rspec/lib/rspec.rb are present) and fallback to a simple require 'spec'. 

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

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

From noreply at rubyforge.org  Wed Mar 14 11:17:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 11:17:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9282 ] Change to allow running specs
	from textmate with rspec installed as a rails plugin (and no
	rspec gem installed)
Message-ID: <20070314151735.C3DD25240C21@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jonathan Tron (jonathant)
Assigned to: Nobody (None)
Summary: Change to allow running specs from textmate with rspec installed as a rails plugin  (and no rspec gem installed)

Initial Comment:
I changed all require call to use a full path based on File.dirname(__FILE__).
I modified the spec_mate.rb of RSpec.tmbundle to look for rspec as a rails plugins (check if ENV['TM_PROJECT_DIRECTORY'] and ENV['TM_PROJECT_DIRECTORY']/vendor/plugins/rspec/lib/rspec.rb are present) and fallback to a simple require 'spec'. 

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

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

Message:
I like the idea, but your patch modifies a bunch of require statements in RSpec core. Is that really necessary? Wouldn't it be better to use LOAD_PATH and avoid all of these ugly absolute paths everywhere?

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

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

From noreply at rubyforge.org  Wed Mar 14 11:40:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 11:40:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070314154004.BB2375240C1C@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-14 15:40

Message:
Hmmm, if I'm not quite sure I understand.  Often I need to call methods on 
models, so I need to stub (and should_receive) these too.  There's no way I 
could spec the behaviour of a controller just by stubbing save!.

Or are you suggesting using real ActiveRecord objects and stub just the save! 
method?  That would go against the principle of unit tests though, surely.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 10:46

Message:
If you are writing controller specs, you should just stub the save! method and be done with it (stub/mock at the interface level).

Then, in a model spec you can verify the unstubbed save! method by running against the database.

Makes sense?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 10:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 15:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 14:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 16: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 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  Wed Mar 14 11:58:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 11:58:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9282 ] Change to allow running specs
	from textmate with rspec installed as a rails plugin (and no
	rspec gem installed)
Message-ID: <20070314155827.471355240C1C@rubyforge.org>

Patches item #9282, was opened at 14/03/2007 15:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=9282&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jonathan Tron (jonathant)
Assigned to: Nobody (None)
Summary: Change to allow running specs from textmate with rspec installed as a rails plugin  (and no rspec gem installed)

Initial Comment:
I changed all require call to use a full path based on File.dirname(__FILE__).
I modified the spec_mate.rb of RSpec.tmbundle to look for rspec as a rails plugins (check if ENV['TM_PROJECT_DIRECTORY'] and ENV['TM_PROJECT_DIRECTORY']/vendor/plugins/rspec/lib/rspec.rb are present) and fallback to a simple require 'spec'. 

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

>Comment By: Jonathan Tron (jonathant)
Date: 14/03/2007 16:58

Message:
I tried to use "$:.unshift" method first, but I had some
trouble with files not loading correctly (I confess not
having searched to far to identified the problem). So I
choosed to go the way it is done in rspec_on_rails plugin.

If you prefer I think I could have a second look for the
"clean" solution by tomorrow. 

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 14/03/2007 16:17

Message:
I like the idea, but your patch modifies a bunch of require statements in RSpec core. Is that really necessary? Wouldn't it be better to use LOAD_PATH and avoid all of these ugly absolute paths everywhere?

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

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

From noreply at rubyforge.org  Wed Mar 14 14:08:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 14:08:50 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9286 ] spec --line switch fails when
	spec has loops
Message-ID: <20070314180850.7D5465240C31@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: spec --line switch fails when spec has loops

Initial Comment:
Hello,
  When running specific specs via the --line switch, it appears that there is a preprocessing step before this line number is attached to a segment of code.  For example:

[1,6].each do |size|
  context "Foo.bar of size #{size}" do
    specify "should return Bar"
  end
end

If I run 'spec --line 2 foo_spec.rb', only the context with size 1 will execute.  By itself, this is no big deal, but let's consider an augmentation of this example:

[1,6].each do |size|
  context "Foo.bar of size #{size}" do
    specify "should return Bar" do
      foo.bar.should == Bar
    end
  end
end

context "Bar.baz" do
  specify "should return Baz" do
    bar.baz.should == Baz
  end
end

Now, if I want to execute the "should return Baz" specification, I must anticipate the new line number after the loop has been "unfolded," so to speak.

Thanks for the help.  Rspec is great!


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

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

From noreply at rubyforge.org  Wed Mar 14 14:14:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 14:14:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070314181457.936CA5240C2F@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-14 18:14

Message:
Ashley - you should consider creating a method on one of your models that handles the transaction, for example:

Address#save_with(applicant, vehicle)

You could mock that in the controller, and then test it directly in your model tests.

I think that's what Aslak was driving at. Ideally, the only specs that should ever touch the database are your model specs and any end-to-end tests. The controller/helper/view specs should always mock models, and have absolutely zero direct references to ActiveRecord (even for mocking).



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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 15:40

Message:
Hmmm, if I'm not quite sure I understand.  Often I need to call methods on 
models, so I need to stub (and should_receive) these too.  There's no way I 
could spec the behaviour of a controller just by stubbing save!.

Or are you suggesting using real ActiveRecord objects and stub just the save! 
method?  That would go against the principle of unit tests though, surely.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 10:46

Message:
If you are writing controller specs, you should just stub the save! method and be done with it (stub/mock at the interface level).

Then, in a model spec you can verify the unstubbed save! method by running against the database.

Makes sense?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 10:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 15:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 14:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 16: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 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  Wed Mar 14 14:16:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 14:16:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070314181639.0E7E85240C30@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-14 18:16

Message:
"mock that in the controller" should be "call it from the controller and mock it in the controller spec"

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

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

Message:
Ashley - you should consider creating a method on one of your models that handles the transaction, for example:

Address#save_with(applicant, vehicle)

You could mock that in the controller, and then test it directly in your model tests.

I think that's what Aslak was driving at. Ideally, the only specs that should ever touch the database are your model specs and any end-to-end tests. The controller/helper/view specs should always mock models, and have absolutely zero direct references to ActiveRecord (even for mocking).



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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 15:40

Message:
Hmmm, if I'm not quite sure I understand.  Often I need to call methods on 
models, so I need to stub (and should_receive) these too.  There's no way I 
could spec the behaviour of a controller just by stubbing save!.

Or are you suggesting using real ActiveRecord objects and stub just the save! 
method?  That would go against the principle of unit tests though, surely.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 10:46

Message:
If you are writing controller specs, you should just stub the save! method and be done with it (stub/mock at the interface level).

Then, in a model spec you can verify the unstubbed save! method by running against the database.

Makes sense?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 10:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 15:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 14:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 16: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 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  Wed Mar 14 15:01:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 15:01:17 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9286 ] spec --line switch fails when
	spec has loops
Message-ID: <20070314190118.0D8745240C27@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: spec --line switch fails when spec has loops

Initial Comment:
Hello,
  When running specific specs via the --line switch, it appears that there is a preprocessing step before this line number is attached to a segment of code.  For example:

[1,6].each do |size|
  context "Foo.bar of size #{size}" do
    specify "should return Bar"
  end
end

If I run 'spec --line 2 foo_spec.rb', only the context with size 1 will execute.  By itself, this is no big deal, but let's consider an augmentation of this example:

[1,6].each do |size|
  context "Foo.bar of size #{size}" do
    specify "should return Bar" do
      foo.bar.should == Bar
    end
  end
end

context "Bar.baz" do
  specify "should return Baz" do
    bar.baz.should == Baz
  end
end

Now, if I want to execute the "should return Baz" specification, I must anticipate the new line number after the loop has been "unfolded," so to speak.

Thanks for the help.  Rspec is great!


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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 15:01

Message:
Due to the way --line is implemented I regret to have to reject this RFE. Here is why:

--line is merely a preprocessor for --spec, which takes a spec name as argument. This argument is either the context/describe name, the specify/it name or both (combined with a space).

--line just looks (upwards) for the nearest spec and context, constructs a "#{context_name} #{spec_name}" and delegates to the --spec functionality. Because these names cannot be determined at the time --line is evaluated, it won't work.

The solution is to use --spec instead, and use your own brain power to determine what its argument should be!


It's impossible (or at least very hard) to evaluate

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

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

From noreply at rubyforge.org  Wed Mar 14 15:12:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 15:12:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9286 ] spec --line switch fails when
	spec has loops
Message-ID: <20070314191241.1A8B95240C2C@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: spec --line switch fails when spec has loops

Initial Comment:
Hello,
  When running specific specs via the --line switch, it appears that there is a preprocessing step before this line number is attached to a segment of code.  For example:

[1,6].each do |size|
  context "Foo.bar of size #{size}" do
    specify "should return Bar"
  end
end

If I run 'spec --line 2 foo_spec.rb', only the context with size 1 will execute.  By itself, this is no big deal, but let's consider an augmentation of this example:

[1,6].each do |size|
  context "Foo.bar of size #{size}" do
    specify "should return Bar" do
      foo.bar.should == Bar
    end
  end
end

context "Bar.baz" do
  specify "should return Baz" do
    bar.baz.should == Baz
  end
end

Now, if I want to execute the "should return Baz" specification, I must anticipate the new line number after the loop has been "unfolded," so to speak.

Thanks for the help.  Rspec is great!


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

>Comment By: Chris Hoffman (hoffman_c)
Date: 2007-03-14 15:12

Message:
Hello,
  Could you please annotate the help screen so that another
user does not fall into the same trap, then?  It took me
quite some time to figure out that this was what was happening.

Thank you.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 15:01

Message:
Due to the way --line is implemented I regret to have to reject this RFE. Here is why:

--line is merely a preprocessor for --spec, which takes a spec name as argument. This argument is either the context/describe name, the specify/it name or both (combined with a space).

--line just looks (upwards) for the nearest spec and context, constructs a "#{context_name} #{spec_name}" and delegates to the --spec functionality. Because these names cannot be determined at the time --line is evaluated, it won't work.

The solution is to use --spec instead, and use your own brain power to determine what its argument should be!


It's impossible (or at least very hard) to evaluate

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

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

From noreply at rubyforge.org  Wed Mar 14 15:17:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 15:17:59 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9287 ] Add regular
	expression support to --spec switch
Message-ID: <20070314191759.B09215240C33@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: Add regular expression support to --spec switch

Initial Comment:
Hello,
  As a means of getting around the situation described here:

http://rubyforge.org/tracker/?func=detail&atid=3149&aid=9286&group_id=797

I propose adding regular expression support to the --spec switch.  I am not big on typing, and being able to do

spec --spec ".*unique phrase.*" some_spec.rb

instead of

spec --spec "Long specification statement with a unique phrase" some_spec.rb

would be fantastic.

Additionally, you could run all specs related to a loop, by regex'ing out the unique bits of the spec description, a la

spec --spec "should have \d+ items" some_spec.rb

Thanks.  Keep up the good work!

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

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

From noreply at rubyforge.org  Wed Mar 14 15:35:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 15:35:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9286 ] spec --line switch fails when
	spec has loops
Message-ID: <20070314193535.480015240C33@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: spec --line switch fails when spec has loops

Initial Comment:
Hello,
  When running specific specs via the --line switch, it appears that there is a preprocessing step before this line number is attached to a segment of code.  For example:

[1,6].each do |size|
  context "Foo.bar of size #{size}" do
    specify "should return Bar"
  end
end

If I run 'spec --line 2 foo_spec.rb', only the context with size 1 will execute.  By itself, this is no big deal, but let's consider an augmentation of this example:

[1,6].each do |size|
  context "Foo.bar of size #{size}" do
    specify "should return Bar" do
      foo.bar.should == Bar
    end
  end
end

context "Bar.baz" do
  specify "should return Baz" do
    bar.baz.should == Baz
  end
end

Now, if I want to execute the "should return Baz" specification, I must anticipate the new line number after the loop has been "unfolded," so to speak.

Thanks for the help.  Rspec is great!


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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 15:35

Message:
I've updated the help message locally - will commit it when I've finished the other stuff I'm working on.

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

Comment By: Chris Hoffman (hoffman_c)
Date: 2007-03-14 15:12

Message:
Hello,
  Could you please annotate the help screen so that another
user does not fall into the same trap, then?  It took me
quite some time to figure out that this was what was happening.

Thank you.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 15:01

Message:
Due to the way --line is implemented I regret to have to reject this RFE. Here is why:

--line is merely a preprocessor for --spec, which takes a spec name as argument. This argument is either the context/describe name, the specify/it name or both (combined with a space).

--line just looks (upwards) for the nearest spec and context, constructs a "#{context_name} #{spec_name}" and delegates to the --spec functionality. Because these names cannot be determined at the time --line is evaluated, it won't work.

The solution is to use --spec instead, and use your own brain power to determine what its argument should be!


It's impossible (or at least very hard) to evaluate

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

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

From noreply at rubyforge.org  Wed Mar 14 22:20:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 22:20:46 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9295 ] rake spec should run
	anything in the spec directory (not just rspec's standard dirs)
Message-ID: <20070315022046.DDA0A5240C30@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: rake spec should run anything in the spec directory (not just rspec's standard dirs)

Initial Comment:
>From email from Bob Martin:

Recommend you add this to rspec.rake

desc "Run all specs in spec directory"
Spec::Rake::SpecTask.new(:all_specs => "db:test:prepare") do |t|
  t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"]
  t.spec_files = FileList['spec/**/*_spec.rb']
end

Perhaps this should BE the 'spec' task. 

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

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

From noreply at rubyforge.org  Wed Mar 14 22:32:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 14 Mar 2007 22:32:25 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9295 ] rake spec should run
	anything in the spec directory (not just rspec's standard dirs)
Message-ID: <20070315023225.AA0055240C2F@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: rake spec should run anything in the spec directory (not just rspec's standard dirs)

Initial Comment:
>From email from Bob Martin:

Recommend you add this to rspec.rake

desc "Run all specs in spec directory"
Spec::Rake::SpecTask.new(:all_specs => "db:test:prepare") do |t|
  t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"]
  t.spec_files = FileList['spec/**/*_spec.rb']
end

Perhaps this should BE the 'spec' task. 

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-15 02:32

Message:
I added the task (rev 1602), but I'm not sure about making it the default. As we add more types of specs for stories and browser tests, I think this will become problematic.

I do see some benefit in a task that runs the model/view/controller/helper specs in a single batch (rather than 4 separate batches, each w/ their own reload time). Should we make the default do that?

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

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

From noreply at rubyforge.org  Thu Mar 15 05:59:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 05:59:50 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070315095950.4EE515240C95@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-15 09:59

Message:
Get you now - I just misunderstood Aslak's comment.  That's effectively what I 
had done, and I'm am right now in the middle of moving some classes out of 
the controller into the model layer that abstract the behaviour.  I was about to 
post to rspec-users about that anyway.

Thanks for the help as always

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-14 18:16

Message:
"mock that in the controller" should be "call it from the controller and mock it in the controller spec"

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

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

Message:
Ashley - you should consider creating a method on one of your models that handles the transaction, for example:

Address#save_with(applicant, vehicle)

You could mock that in the controller, and then test it directly in your model tests.

I think that's what Aslak was driving at. Ideally, the only specs that should ever touch the database are your model specs and any end-to-end tests. The controller/helper/view specs should always mock models, and have absolutely zero direct references to ActiveRecord (even for mocking).



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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 15:40

Message:
Hmmm, if I'm not quite sure I understand.  Often I need to call methods on 
models, so I need to stub (and should_receive) these too.  There's no way I 
could spec the behaviour of a controller just by stubbing save!.

Or are you suggesting using real ActiveRecord objects and stub just the save! 
method?  That would go against the principle of unit tests though, surely.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 10:46

Message:
If you are writing controller specs, you should just stub the save! method and be done with it (stub/mock at the interface level).

Then, in a model spec you can verify the unstubbed save! method by running against the database.

Makes sense?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 10:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 15:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 14:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 16: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 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 15 07:26:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 07:26:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070315112639.9526B5240C99@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-15 07:26

Message:
Can we close this issue then?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-15 05:59

Message:
Get you now - I just misunderstood Aslak's comment.  That's effectively what I 
had done, and I'm am right now in the middle of moving some classes out of 
the controller into the model layer that abstract the behaviour.  I was about to 
post to rspec-users about that anyway.

Thanks for the help as always

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

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

Message:
"mock that in the controller" should be "call it from the controller and mock it in the controller spec"

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

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

Message:
Ashley - you should consider creating a method on one of your models that handles the transaction, for example:

Address#save_with(applicant, vehicle)

You could mock that in the controller, and then test it directly in your model tests.

I think that's what Aslak was driving at. Ideally, the only specs that should ever touch the database are your model specs and any end-to-end tests. The controller/helper/view specs should always mock models, and have absolutely zero direct references to ActiveRecord (even for mocking).



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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 11:40

Message:
Hmmm, if I'm not quite sure I understand.  Often I need to call methods on 
models, so I need to stub (and should_receive) these too.  There's no way I 
could spec the behaviour of a controller just by stubbing save!.

Or are you suggesting using real ActiveRecord objects and stub just the save! 
method?  That would go against the principle of unit tests though, surely.

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

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

Message:
If you are writing controller specs, you should just stub the save! method and be done with it (stub/mock at the interface level).

Then, in a model spec you can verify the unstubbed save! method by running against the database.

Makes sense?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 06:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 11:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 10:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

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  Thu Mar 15 07:33:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 07:33:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070315113327.2C8FF5240C99@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-15 11:33

Message:
Well I've come to the conclusion that mock message ordering won't help what I 
was trying to do, so by all means close it on my account.  Unless you think 
cross-mock message ordering would be useful in general?

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-15 11:26

Message:
Can we close this issue then?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-15 09:59

Message:
Get you now - I just misunderstood Aslak's comment.  That's effectively what I 
had done, and I'm am right now in the middle of moving some classes out of 
the controller into the model layer that abstract the behaviour.  I was about to 
post to rspec-users about that anyway.

Thanks for the help as always

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-14 18:16

Message:
"mock that in the controller" should be "call it from the controller and mock it in the controller spec"

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

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

Message:
Ashley - you should consider creating a method on one of your models that handles the transaction, for example:

Address#save_with(applicant, vehicle)

You could mock that in the controller, and then test it directly in your model tests.

I think that's what Aslak was driving at. Ideally, the only specs that should ever touch the database are your model specs and any end-to-end tests. The controller/helper/view specs should always mock models, and have absolutely zero direct references to ActiveRecord (even for mocking).



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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 15:40

Message:
Hmmm, if I'm not quite sure I understand.  Often I need to call methods on 
models, so I need to stub (and should_receive) these too.  There's no way I 
could spec the behaviour of a controller just by stubbing save!.

Or are you suggesting using real ActiveRecord objects and stub just the save! 
method?  That would go against the principle of unit tests though, surely.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-14 10:46

Message:
If you are writing controller specs, you should just stub the save! method and be done with it (stub/mock at the interface level).

Then, in a model spec you can verify the unstubbed save! method by running against the database.

Makes sense?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 10:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 15:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 14:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-12 16: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 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 15 07:35:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 07:35:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9083 ] Allow ordering of
	expectations across mocks
Message-ID: <20070315113512.4339E5240C96@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: Closed
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-15 07:35

Message:
cross-mock message ordering is sometimes useful, and RSpec supports it by using blocks as described below.

Closing this now.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-15 07:33

Message:
Well I've come to the conclusion that mock message ordering won't help what I 
was trying to do, so by all means close it on my account.  Unless you think 
cross-mock message ordering would be useful in general?

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-15 07:26

Message:
Can we close this issue then?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-15 05:59

Message:
Get you now - I just misunderstood Aslak's comment.  That's effectively what I 
had done, and I'm am right now in the middle of moving some classes out of 
the controller into the model layer that abstract the behaviour.  I was about to 
post to rspec-users about that anyway.

Thanks for the help as always

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

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

Message:
"mock that in the controller" should be "call it from the controller and mock it in the controller spec"

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

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

Message:
Ashley - you should consider creating a method on one of your models that handles the transaction, for example:

Address#save_with(applicant, vehicle)

You could mock that in the controller, and then test it directly in your model tests.

I think that's what Aslak was driving at. Ideally, the only specs that should ever touch the database are your model specs and any end-to-end tests. The controller/helper/view specs should always mock models, and have absolutely zero direct references to ActiveRecord (even for mocking).



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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 11:40

Message:
Hmmm, if I'm not quite sure I understand.  Often I need to call methods on 
models, so I need to stub (and should_receive) these too.  There's no way I 
could spec the behaviour of a controller just by stubbing save!.

Or are you suggesting using real ActiveRecord objects and stub just the save! 
method?  That would go against the principle of unit tests though, surely.

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

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

Message:
If you are writing controller specs, you should just stub the save! method and be done with it (stub/mock at the interface level).

Then, in a model spec you can verify the unstubbed save! method by running against the database.

Makes sense?

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-14 06:39

Message:
Actually I'm writing controller specs here, so I guess I'm safe to stub out 
things like ActiveRecord::Base.transaction.  Otherwise I'd have no end of 
problems

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-13 11:19

Message:
As mentioned in an earlier mail thread: Don't use mocking in specs for AR classes. Have them go against the database.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-03-13 10:49

Message:
>Ironically I just found myself needing what you're asking for,
> so I guess it can't be abuse then

I feel less stupid for suggesting it now :)

The block thing looked like the perfect solution.  And I suppose it *is* for the 
issue I posted.  

Unfortunately it doesn't help me with the problem I've actually got, which is 
specifying this:

    def save!
      ActiveRecord::Base.transaction do
        applicant.address = address
        vehicle.applicant = applicant
        address.save!
      end
    end

Unfortunately the closest spec I can write is this:

  specify "should run the save tasks in a transaction" do
    ActiveRecord::Base.should_receive(:transaction).and_yield do
      @applicant.should_receive(:address=).with(@address)
      @vehicle.should_receive(:applicant=).with(@applicant)
      @address.should_receive(:save!)
    end
    @details.save!
  end

and this can be made to pass with the following mess:

    def save!
      applicant.address = address
      ActiveRecord::Base.transaction do
      end
      vehicle.applicant = applicant
      address.save!
    end

I guess that's a separate problem from simple message ordering, but it's what 
got me posting to rspec-users in the first place.

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

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  Thu Mar 15 10:42:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 10:42:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9295 ] rake spec should run
	anything in the spec directory (not just rspec's standard dirs)
Message-ID: <20070315144218.6E5215240C9A@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: rake spec should run anything in the spec directory (not just rspec's standard dirs)

Initial Comment:
>From email from Bob Martin:

Recommend you add this to rspec.rake

desc "Run all specs in spec directory"
Spec::Rake::SpecTask.new(:all_specs => "db:test:prepare") do |t|
  t.spec_opts = ['--options', "\#{RAILS_ROOT}/spec/spec.opts\"]
  t.spec_files = FileList['spec/**/*_spec.rb']
end

Perhaps this should BE the 'spec' task. 

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

Comment By: Robert Martin (unclebob)
Date: 2007-03-15 09:42

Message:
I've only build one real rails app at this point.  But before it got very large, I was creating subdirectories in the 'app/models' and 'app/specs' directory.  I can't imaging that this isn't common practice.  So my vote is for the default rake task to hunt out every subdirectory under spec, and execute any spec it finds.  I also wish that every subdirectory under 'app' was automatically added to the rails autoloader path.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-14 21:32

Message:
I added the task (rev 1602), but I'm not sure about making it the default. As we add more types of specs for stories and browser tests, I think this will become problematic.

I do see some benefit in a task that runs the model/view/controller/helper specs in a single batch (rather than 4 separate batches, each w/ their own reload time). Should we make the default do that?

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

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

From noreply at rubyforge.org  Thu Mar 15 10:58:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 10:58:17 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9304 ] should_all <predicate>
Message-ID: <20070315145817.440005240CA9@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: should_all <predicate>

Initial Comment:
Hello,
  In order to check the properties of each element in a collection, one must presently do the following (as far as I can tell):

mycollection = [2,3,5,7]
mycollection.each { |num| num.should_be_prime }

I suggest an improvement that would significantly increase the readability of these statement types:

mycollection.should_all be_prime

Keep up the good work!  This software has made me into a better programmer.


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

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

From noreply at rubyforge.org  Thu Mar 15 11:11:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 11:11:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9304 ] should_all <predicate>
Message-ID: <20070315151106.929035240CAA@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: should_all <predicate>

Initial Comment:
Hello,
  In order to check the properties of each element in a collection, one must presently do the following (as far as I can tell):

mycollection = [2,3,5,7]
mycollection.each { |num| num.should_be_prime }

I suggest an improvement that would significantly increase the readability of these statement types:

mycollection.should_all be_prime

Keep up the good work!  This software has made me into a better programmer.


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-15 15:11

Message:
How about:

mycollection.should all_be_prime

Then we don't further pollute Object.

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

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

From noreply at rubyforge.org  Thu Mar 15 11:14:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 11:14:52 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9304 ] should_all &lt;
	predicate&gt; 
Message-ID: <20070315151452.BFFE95240CAA@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
>Summary: should_all &lt;predicate&gt;

Initial Comment:
Hello,
  In order to check the properties of each element in a collection, one must presently do the following (as far as I can tell):

mycollection = [2,3,5,7]
mycollection.each { |num| num.should_be_prime }

I suggest an improvement that would significantly increase the readability of these statement types:

mycollection.should_all be_prime

Keep up the good work!  This software has made me into a better programmer.


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

>Comment By: Chris Hoffman (hoffman_c)
Date: 2007-03-15 11:14

Message:
Sure, that will work; I'm not intimate with your code base,
so whatever you think is best as far as implementation would
be great.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-15 11:11

Message:
How about:

mycollection.should all_be_prime

Then we don't further pollute Object.

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

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

From noreply at rubyforge.org  Thu Mar 15 15:05:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 15:05:52 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-6550 ] Mix in several
	modules and do it in one place only
Message-ID: <20070315190552.3E3E35240C84@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Mix in several modules and do it in one place only

Initial Comment:
We need a way to mixin several modules and do it in one place only. Like in the spec_helper.rb file used by spec/rails



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-15 19:05

Message:
We have a need to add this soon. Here's what I'm thinking:

#in spec_helper.rb

module Spec
  module Config
    mock_with :my_favorite_mock_framework
    include MyHelperMethods
    include MyCustomMatchers
  end
end

Everything defined or declared here would impact all specs. We'd make it work the same for Spec::Rails.

Sound reasonable?

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

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

From noreply at rubyforge.org  Thu Mar 15 17:48:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 15 Mar 2007 17:48:43 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9311 ] Controller Specs do not play
	nicely with Markaby and Rxml
Message-ID: <20070315214844.0F6385240CCA@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Controller Specs do not play nicely with Markaby and Rxml

Initial Comment:
Look in rails/runner/context/controller.rb line 18.

If render is called without a block and views are not integrated, ActionView::Base#find_template_extension_for is stubbed to return 'rhtml'.

Unfortunately, rails caches this result. When I run a view spec, e.g.
render 'foo/bar'

and bar is a markaby file (bar.mab), rails uses the cached extension (rhtml) when @@cache_template_extensions is set to true, which it is by default.

See ActionView::Base#pick_template_extension


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

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

From joshknowles at gmail.com  Sat Mar 17 17:40:52 2007
From: joshknowles at gmail.com (Josh Knowles)
Date: Sat, 17 Mar 2007 14:40:52 -0700
Subject: [rspec-devel] Error running webgen during pre_commit
Message-ID: <c18843c60703171440l2f4c5793g79f593ebe5c6f8eb@mail.gmail.com>

I'm attempting to get the rspec development environment setup, but am
running into the following error during the pre_commit step:

ERROR while running webgen:
/opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- webgen/plugins/tags/tags
(LoadError)

I know nothing about webgen, and infact this file doesn't even exist.  Has
anyone else ran into this problem?  Am I missing a gem?

Josh

-- 
Josh Knowles
joshknowles at gmail.com
http://joshknowles.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070317/c5a24a63/attachment.html 

From dchelimsky at gmail.com  Sat Mar 17 18:01:15 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 17 Mar 2007 17:01:15 -0500
Subject: [rspec-devel] Error running webgen during pre_commit
In-Reply-To: <c18843c60703171440l2f4c5793g79f593ebe5c6f8eb@mail.gmail.com>
References: <c18843c60703171440l2f4c5793g79f593ebe5c6f8eb@mail.gmail.com>
Message-ID: <57c63afe0703171501v1f302eedk9acfc755656edc1d@mail.gmail.com>

We're using an old version of webgen, which uses a different structure
- you want webgen 0.3.8.

On 3/17/07, Josh Knowles <joshknowles at gmail.com> wrote:
> I'm attempting to get the rspec development environment setup, but am
> running into the following error during the pre_commit step:
>
> ERROR while running webgen:
> /opt/local/lib/ruby/vendor_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require': no such file to load -- webgen/plugins/tags/tags
> (LoadError)
>
> I know nothing about webgen, and infact this file doesn't even exist.  Has
> anyone else ran into this problem?  Am I missing a gem?
>
> Josh
>
> --
> Josh Knowles
>  joshknowles at gmail.com
> http://joshknowles.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From larrytheliquid at gmail.com  Sat Mar 17 21:56:45 2007
From: larrytheliquid at gmail.com (Larrytheliquid)
Date: Sat, 17 Mar 2007 21:56:45 -0400
Subject: [rspec-devel] GSoC RSpec project
Message-ID: <fd2537a0703171856p153ad4a0ree99b96f1f733fcc@mail.gmail.com>

I'd like to do a project for this years Google Summer of Code. RSpec, being
something I prefer vastly over TestUnit and use personally and
professionally, would be something I'd love to work on.

The deadline for applications is March 24th, and the amount of time allotted
for the actual project is 3 months. Do any of you have any suggestions for a
good RSpec-related project that is suitable for this time frame? Maybe work
on the integration testing part of RSpec? Thanks in advance for any thought
or suggestions, and a very appreciated thanks for all the great work on
RSpec as it is!

-- 
Respectfully,
Larry Diehl
www.larrytheliquid.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070317/ed85526f/attachment.html 

From aslak.hellesoy at gmail.com  Sun Mar 18 04:50:57 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 18 Mar 2007 09:50:57 +0100
Subject: [rspec-devel] GSoC RSpec project
In-Reply-To: <fd2537a0703171856p153ad4a0ree99b96f1f733fcc@mail.gmail.com>
References: <fd2537a0703171856p153ad4a0ree99b96f1f733fcc@mail.gmail.com>
Message-ID: <8d961d900703180150x3765f833j56c3edeecdca374a@mail.gmail.com>

It's great that you want to contribute to RSpec in GSoC. I think maybe
the implementation of Rails integration testing would be a relatively
small job for 3 months. I cannot imagine it would be that much work,
but I might be wrong.

One thing that I would love to see is more editor/IDE support.
Currently we have great TextMate support, but there is no support in
RDT/Eclipse and IntelliJ IDEA, both of which I think will be used by
many developers by the end of this year. (I think the adoption of
these IDEs will follow naturally as more and more Java folks pick up
Ruby, and as JRuby gets more widespread.

Is that someone you (or someone else) would like to work on?

Aslak

On 3/18/07, Larrytheliquid <larrytheliquid at gmail.com> wrote:
> I'd like to do a project for this years Google Summer of Code. RSpec, being
> something I prefer vastly over TestUnit and use personally and
> professionally, would be something I'd love to work on.
>
> The deadline for applications is March 24th, and the amount of time allotted
> for the actual project is 3 months. Do any of you have any suggestions for a
> good RSpec-related project that is suitable for this time frame? Maybe work
> on the integration testing part of RSpec? Thanks in advance for any thought
> or suggestions, and a very appreciated thanks for all the great work on
> RSpec as it is!
>
> --
> Respectfully,
> Larry Diehl
> www.larrytheliquid.com
>

From noreply at rubyforge.org  Mon Mar 19 08:37:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Mar 2007 08:37:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9375 ] play nice w/ mocha
	and/or flexmock and/or any other mocking framework
Message-ID: <20070319123718.C67A55240BF0@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: play nice w/ mocha and/or flexmock and/or any other mocking framework

Initial Comment:
Right now you can use rspec w/ other frameworks but you have to go through some hoops.

You should be able to do something as simple as require 'mocha' or require 'flexmock' to invoke either.

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

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

From noreply at rubyforge.org  Mon Mar 19 08:54:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Mar 2007 08:54:37 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-8126 ] Nested specify blocks
Message-ID: <20070319125437.D738E5240AF0@rubyforge.org>

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

Category: expectation module
Group: None
>Status: Closed
Priority: 3
Submitted By: Wincent Colaiuta (wincent)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Nested specify blocks

Initial Comment:
I know that the idea of nested contexts has come up on the devel list before (Google for "pipermail rspec nested contexts") and most were not in favor of the idea.

For me, more useful than nested contexts would be nested specifications ("specify" blocks). Currently I have specs which look like this:

context 'outer' do
  specify 'inner' do
    this.should == that
  end
end

If a spec is not satisfied then rspec prints a message of the form "outer inner". I sometimes find myself wishing that I could nest the specify blocks to fine tune the failure message:

context 'outer' do
  specify 'inner' do
    specify 'innermost' do
      this.should == that
    end
  end
end

In this case rspec would print "outer inner innermost" on failure. Let me flesh it out a bit with more of a concrete example; basically I often find myself wanting to write this:

context 'applying a regexp to a string' do
  specify 'should be able to match "zero or more" times' do
    specify 'with input that matches zero times' do
      # test zero-match case
    end
    specify 'with input that matches one time' do
      # test one-match case
    end
    specify 'with input that matches two times' do
      # test two-match case
    end      
  end
end

Because I can't be bothered writing this:

context 'applying a regexp to a string' do
  specify 'should be able to match "zero or more" times (with input that matches zero times)' do
    # test zero-match case
  end
  specify 'should be able to match "zero or more" times (with input that matches one time)' do
    # test one-match case
  end
  specify 'should be able to match "zero or more" times  (with input that matches two times)' do
    # test two-match case
  end      
end

But I end up writing this:

context 'applying a regexp to a string' do
  specify 'should be able to match "zero or more" times' do
    # test zero-match case
    # test one-match case
    # test two-match case
  end      
end

This isn't ideal because if the first assertion fails then the others aren't even tested. I'd rather keep the number of assertions in each specify block a bit lower, and the ability to nest specify blocks would help me to do that. What do people think?

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-19 12:54

Message:
I've experimented with this a bit and it poses some serious problems. If we're nesting these, then there is an implied expectation that you can do this:

context 'context' do
  specify 'outer' do
    foo
    specify 'inner' do
      bar
      assume_that(:foo => :has_been_executed)
    end
    specify 'other_inner' do
      assume_that(:bar => :has_NOT_been_executed)
    end
  end
end

As you may imagine - that gets quite ugly quite quickly, yet it is a perfectly understandable expectation given the structure.

There is another request for an "aspect" (http://rubyforge.org/tracker/?group_id=797&atid=3152&func=detail&aid=8654), which would solve the problem you're trying to solve here.

I'm growing more fond of that idea, but I'm not happy w/ the word "aspect" because it evokes Aspect Oriented Programming, to which this idea has no relation.

I'm going to close this request, and get the 'naming' conversation rolling on the other request.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-16 15:54

Message:
Daniel - I think nesting the output should be an option, but so should not nesting it. I'm not sure of the best way to allow that option (suggestions?) or which should be the default, but I can imagine scenarios in which I'd prefer it each way.

WDYT?

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

Comment By: Daniel Schierbeck (dasch)
Date: 2007-02-16 15:34

Message:
Why not also nest the output?

<pre><code>
  Applying a regexp to a string
  - should be able to match "zero or more" times
     * with input that matches zero times
     * with input that matches one time
     * with input that matches two times
</code></pre>

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-05 11:46

Message:
Lachie: yes, you could view it that way, and given/when/then should be supported keywords (when and then would have to be munged in some way as they are already Ruby keywords).

Wincent: we've gone a long way to keep things simple and from what I've seen, some people will go out of their way to complicate things no matter how simple you make them. Including us!!!! (e.g. controller.should_render)

If/when we do this, it will likely be introduced gradually. It's not the first priority at the moment ;)

Also - looking back at your initial submission - you could do this in the mean time:

context 'applying a regexp to a string should be able to match "zero or more" times' do
  specify 'with input that matches zero times' do
  end
  specify 'with input that matches one time' do
  end
  specify 'with input that matches two times' do
  end      
end

I realize that the context name is more than context - it's a declaration of an aspect of behaviour. That's probably not such a bad thing. And it would result in the same readable output on failures. FFT.

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-02-05 10:12

Message:
> Command line options could load a file which defines
> custom aliases that you want to use that don't ship
> with RSpec, so you could things like 
> "project/iteration/story/scenario" if that made you
> happy.

Above all, I think *some kind* of nesting support would be a 
wonderful improvement in terms of readability/expressiveness 
and also in terms of saved typing; these are the reasons why 
I filed the feature request.

I am also sure that the ability to basically twist RSpec 
into any shape you want and use any terminology you want 
would be popular.

BUT I also think that it might be a bit dangerous to give 
people too much free reign. One of the things about BDD in 
general and specifically RSpec is that the language that it 
imposes ("context"/"specify") helps developers to do the 
right thing and follow best testing practice. If people 
could use any terminology at all then some of that benefit 
might be lost. Also, in the same way that overuse of C 
preprocessor macros can make it harder to read other 
people's source code, if the terminology for specifying 
behaviour is made too flexible then it might become more 
difficult to read other people's specs.

So I'm not saying that you shouldn't do it, but that if you 
do decide to go down this path I think your idea of doing so 
in an incremental fashion is a good one; it will give time 
to really think about it and be sure of why/how/if it should 
be done.

I like the idea of using "story" for acceptance level 
testing. I am not sure whether "behaviour" is the best term 
for cases where "the context is not
so much a system state, but rather an aspect of behaviour"; 
I think the word that you used right there, "aspect", is 
probably a better choice. That's just my initial gut 
feeling; I'd need to think about it more to be sure.

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

Comment By: Lachie Cox (lachie)
Date: 2007-02-04 22:29

Message:
I this given-when-then by different names?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-04 22:21

Message:
Thinking about this some more - I think that there are many structures that could prove useful. We've named "context/specify/example", but there is also "story/scenario" for acceptance level spec'ing, "behaviour/specify/example" when the context is not so much a system state, but rather an aspect of behaviour like "error messages".

This is leading me to this thought: what if the structure was simply a tree?

We could have a method #rspec_node(*args, &block) that returns an RSpecNode. This would be implemented in Kernel, aliased with names like #context, #behaviour and #story. It would also be implemented in RSpecNode, aliased with names like #specify, #example and #scenario.

Nested nodes would have access to state in any of its ancestor nodes, supporting the long sought-after "nested context", but siblings would not have access to each other's state.

Command line options could load a file which defines custom aliases that you want to use that don't ship with RSpec, so you could things like "project/iteration/story/scenario" if that made you happy.

I've taken a look at this and it would require a lot of work, but there's no reason it shouldn't be 100% backwards compatible (except for monkey patching), and it's something we can probably introduce gradually, starting w/ nested specify blocks, and working up to unifying Context and Specification into a single RSpecNode.

WDYT of that?

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-01-27 16:42

Message:
Yes, I think that "context/specify/example" would be a great 
way to split things up, and the language you've proposed 
maps well onto the behaviour-driven way of thinking about 
software development ("in this context ... this should 
happen ... example ...").

About the only thing I would change in your example is that 
I would start each example with the word "for" so that when 
the three strings are chained together they would read like, 
"applying a regexp to a string should be able to match 'zero 
or more' times for the zero-match case" etc:

context 'applying a regexp to a string' do
  specify 'should be able to match "zero or more" times' do
    example 'for the zero-match case' do ... end
    example 'for the one-match case' do ... end
    example 'for the two-match case' do ... end
  end      
end

This has the added benefit that the line introducing each 
example in the specification reads as "example for zero-
match case" etc, which is highly readable and descriptive.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-27 15:53

Message:
I love this idea, but I think nesting specify would be confusing to look at. How about this:

context
  specify
    example

context 'applying a regexp to a string' do
  specify 'should be able to match "zero or more" times' do
    example "zero-match case" do
    example "one-match case" do
    example "two-match case" do
  end      
end

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

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

From noreply at rubyforge.org  Mon Mar 19 08:56:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Mar 2007 08:56:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects
Message-ID: <20070319125612.B3D5E5240AE4@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Aspects

Initial Comment:
Specifications become a bit messy in large applications. What if implementing aspects for rspec?

context "New Document instance" do

  setup do
    @document = Document.new
  end 

   aspect "versioning" do

    specify "should have no versions" do
     @document.should_have(0).versions
    end

   end

   aspect "printing" do
     aspect "pdf" do
       ...
     end
   end

 end

New Document instance
- (versioning) should have no versions
- (printing/pdf) ...

Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-19 12:56

Message:
Agreed that sub_context is the wrong name, and "aspect" WOULD be a great name if it didn't evoke Aspect Oriented Programming.

Any other suggestions? I want to come up w/ the right name before we add this.

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

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-02-16 12:57

Message:
Also, I think that sub_context isn't good name for aspect. In my understanding 
aspects to be _quite_ orthogonal to context. It's kind of protocol in Smalltalk, or 
something like that.

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

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-02-16 12:49

Message:
David,

basically your idea about nested blocks with arbitrary names is nice, but I 
foresee one problem. My current implementation supports nested aspects 
and joins their names like "(versioning/backup)" for nested versioning -> 
backup aspects. WDYT?

I will surely be able to rework any of my proof-of-concept implementation of 
rspec extensions as a patch with tests once it will be agreed with rspec 
maintainers.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-14 14:02

Message:
Thanks Yurii. This is pretty sweet.

Please take a look at http://rubyforge.org/tracker/index.php?func=detail&aid=8126&group_id=797&atid=3152.

The direction that one is going is that we'd have nested specify blocks that you could invoke using arbitrary names (like "sub_context" or "aspect"). You'd end up being able to do exactly what you propose in your specs, but you'd have to wrap "versioning" in parens to get the output you're looking for:

context "New Document instance" do
  aspect "(versioning)" do
    specify "should have no versions" do
      ...
      
WDYT?

Also, if you're going to submit implementations, please do so in the form of patches here in the this Tracker. Not to suggest that you shouldn't put it on your blog also, but it would be better to have the history of this conversation in one place.

Lastly, regardless of whether we use your suggestion or what I've just described, I'd recommend coming up with another word besides "aspect" to avoid confusion w/ Aspect Oriented Programming.

Cheers,
David


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

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

From noreply at rubyforge.org  Mon Mar 19 09:40:55 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Mar 2007 09:40:55 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects
Message-ID: <20070319134055.A83BA52409C1@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Aspects

Initial Comment:
Specifications become a bit messy in large applications. What if implementing aspects for rspec?

context "New Document instance" do

  setup do
    @document = Document.new
  end 

   aspect "versioning" do

    specify "should have no versions" do
     @document.should_have(0).versions
    end

   end

   aspect "printing" do
     aspect "pdf" do
       ...
     end
   end

 end

New Document instance
- (versioning) should have no versions
- (printing/pdf) ...

Initial implementation (requires ActiveSupport, but could be easily ported to pure Ruby) and more details are available at http://rashkovskii.com/articles/2007/2/13/rspec-aspects

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-03-19 13:40

Message:
> Any other suggestions? I want to come up w/ the right name
> before we add this.

"Facet"?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-19 12:56

Message:
Agreed that sub_context is the wrong name, and "aspect" WOULD be a great name if it didn't evoke Aspect Oriented Programming.

Any other suggestions? I want to come up w/ the right name before we add this.

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

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-02-16 12:57

Message:
Also, I think that sub_context isn't good name for aspect. In my understanding 
aspects to be _quite_ orthogonal to context. It's kind of protocol in Smalltalk, or 
something like that.

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

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-02-16 12:49

Message:
David,

basically your idea about nested blocks with arbitrary names is nice, but I 
foresee one problem. My current implementation supports nested aspects 
and joins their names like "(versioning/backup)" for nested versioning -> 
backup aspects. WDYT?

I will surely be able to rework any of my proof-of-concept implementation of 
rspec extensions as a patch with tests once it will be agreed with rspec 
maintainers.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-14 14:02

Message:
Thanks Yurii. This is pretty sweet.

Please take a look at http://rubyforge.org/tracker/index.php?func=detail&aid=8126&group_id=797&atid=3152.

The direction that one is going is that we'd have nested specify blocks that you could invoke using arbitrary names (like "sub_context" or "aspect"). You'd end up being able to do exactly what you propose in your specs, but you'd have to wrap "versioning" in parens to get the output you're looking for:

context "New Document instance" do
  aspect "(versioning)" do
    specify "should have no versions" do
      ...
      
WDYT?

Also, if you're going to submit implementations, please do so in the form of patches here in the this Tracker. Not to suggest that you shouldn't put it on your blog also, but it would be better to have the history of this conversation in one place.

Lastly, regardless of whether we use your suggestion or what I've just described, I'd recommend coming up with another word besides "aspect" to avoid confusion w/ Aspect Oriented Programming.

Cheers,
David


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

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

From noreply at rubyforge.org  Mon Mar 19 14:09:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Mar 2007 14:09:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9381 ] rails integration
	spec'ing
Message-ID: <20070319180927.F41165240BFF@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: rails integration spec'ing

Initial Comment:
spec
 |
 + controllers
 |
 + helpers
 |
 + integration (need to add this)
 |
 + models
 |
 + views

spec/integration should use a context that derives from ActionController::IntegrationTest


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

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

From noreply at rubyforge.org  Mon Mar 19 14:19:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Mar 2007 14:19:44 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9382 ] Including a module within a
	context includes methods but not classes from the module
Message-ID: <20070319181944.4E1135240C05@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nathan Sobo (nathansobo)
Assigned to: Nobody (None)
Summary: Including a module within a context includes methods but not classes from the module

Initial Comment:
See attached failing spec.

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

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

From noreply at rubyforge.org  Mon Mar 19 15:51:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Mar 2007 15:51:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-7613 ] context#include
	should add constants into the context
Message-ID: <20070319195129.EE72D5240AF0@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: context#include should add constants into the context

Initial Comment:
dir = File.dirname(__FILE__)
require "#{dir}/spec_helper"

module Foo
  class Bar
  end
end

context "A Context include statement" do
  include Foo
  specify "should add constants accessable in the context" do
    b = Bar.new
  end
end


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-19 19:51

Message:
FYI - you CAN access the constants from instance_eval if you fully qualify them:

irb(main):001:0> class Foo
irb(main):002:1>   def const_missing
irb(main):003:2>     puts "const missing"
irb(main):004:2>   end
irb(main):005:1>   BAR = "bar"
irb(main):006:1>   def get_bar
irb(main):007:2>     BAR
irb(main):008:2>   end
irb(main):009:1> end
=> nil
irb(main):010:0> 
irb(main):011:0* foo = Foo.new
=> #<Foo:0x72ed4>
irb(main):012:0> foo.instance_eval { "bar" }
=> "bar"
irb(main):013:0> foo.instance_eval { get_bar }
=> "bar"
irb(main):014:0> foo.instance_eval { Foo::BAR }
=> "bar"
irb(main):015:0> foo.instance_eval { BAR }
NameError: uninitialized constant BAR
        from (irb):15
        from (irb):15:in `instance_eval'
        from (irb):15
        from :0


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 12:55

Message:
Following up, there doesn't appear to be a way to give a block passed to instance_eval access to the instance's class's constants. It seems that this is simply the state of things and not likely to change in Ruby.

I think the real problem we overloaded a Ruby keyword (include) to give the feeling of doing something that Ruby does, but in fact doesn't work the way it would therefore be expected.

We've had a couple of bugs that have come up as a result of this perception. I'm going to propose that we change the name to something that better describes the intent (in a separate RFE).

In the mean time I'm closing this. To get this to work it would seem to require a complete re-implementation of the runner.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 11:35

Message:
I've narrowed this down to our own use of instance_eval when running specs. Apparently Ruby doesn't allow access to instance constants from instance eval:

irb(main):001:0>   class Foo
irb(main):002:1>     BAR = "bar"
irb(main):003:1>     def get_bar
irb(main):004:2>       BAR
irb(main):005:2>     end
irb(main):006:1>   end
=> nil
irb(main):007:0> foo = Foo.new
=> #<Foo:0x10d90c0>
irb(main):008:0> foo.instance_eval { "bar" }
=> "bar"
irb(main):009:0> foo.instance_eval { get_bar }
=> "bar"
irb(main):010:0> foo.instance_eval { BAR }
NameError: uninitialized constant BAR
        from (irb):10
        from (irb):10:in `instance_eval'
        from (irb):10



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 10:56

Message:
Seems like it!

FUN!

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-02-08 10:33

Message:
Are we facing the challenge of reimplementing Ruby's class system here?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 05:21

Message:
This gets even better:

  module Helpers
    CONSTANT = "constant"
    class Helper
    end
  end
  
  context "context#include" do
    include Helpers
    
    specify "should include qualified constants" do
      Helpers::CONSTANT.should == "constant"
      Helpers::Helper.new
    end
    
    specify "should include unqualified constants" do
      self.class.constants.should include("CONSTANT")
      CONSTANT.should == "constant"
      Helper.new
    end
    
  end

The second spec bails on CONSTANT.should == "constant", but passes self.class.constants.should include("CONSTANT").

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-02-08 04:11

Message:
>From the ruby-talk list:

module TestHelper
 CONSTANT = "constant"
end

context "A context" do
 include TestHelper

 specify "should allow unqualified access to included constants" do
   CONSTANT.should_eql "constant"
   #fails
 end

 specify "should allow qualified access to all constants" do
   TestHelper::CONSTANT.should_eql "constant"
   # passes w/ fully qualified reference
 end
end

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

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

From noreply at rubyforge.org  Mon Mar 19 15:52:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 19 Mar 2007 15:52:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9382 ] Including a module within a
	context includes methods but not classes from the module
Message-ID: <20070319195220.456455240AF0@rubyforge.org>

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

>Category: runner module
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Nathan Sobo (nathansobo)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Including a module within a context includes methods but not classes from the module

Initial Comment:
See attached failing spec.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-19 19:52

Message:
This is a duplicate of an existing bug that we've closed because Ruby won't let us fix it. Closing this one for the same reasons. Read more here:

http://rubyforge.org/tracker/?func=detail&group_id=797&aid=7613&atid=3152

There is another request to rename #include to something else that won't make it so misleading here:

http://rubyforge.org/tracker/?group_id=797&atid=3152&func=detail&aid=8507

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

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

From noreply at rubyforge.org  Tue Mar 20 02:36:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Mar 2007 02:36:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-8103 ] RSpec not installing spec script
	correctly
Message-ID: <20070320063606.5700D5240D7D@rubyforge.org>

Bugs item #8103, was opened at 2007-01-24 07:22
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=8103&group_id=797

Category: runner module
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: RSpec not installing spec script correctly

Initial Comment:
>From Charles Oliver Nutter:

Hey, I just noticed this today...installed RSpec with JRuby, and at the
top of the spec script:

#!/usr/bin/env ruby

That dog won't hunt, Monsignor.

Rails and rake install scripts that correctly run with JRuby, so that's
probably good examples to follow. Unfortunately I have no clue how they
do it.

- Charlie

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-20 06:36

Message:
What is the best way to get around this?  I have a little script which searches the $PATH environment variable for a given name, hence:

euclid% find_file_in_path ruby
/opt/local/bin
/usr/local/bin
/usr/bin

euclid% find_file_in_path spec
/opt/local/bin

Would something like this be useful to use?  How about for the windows folks?

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

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

From noreply at rubyforge.org  Tue Mar 20 03:19:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Mar 2007 03:19:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-8103 ] RSpec not installing spec script
	correctly
Message-ID: <20070320071958.839135240D79@rubyforge.org>

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

Category: runner module
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: RSpec not installing spec script correctly

Initial Comment:
>From Charles Oliver Nutter:

Hey, I just noticed this today...installed RSpec with JRuby, and at the
top of the spec script:

#!/usr/bin/env ruby

That dog won't hunt, Monsignor.

Rails and rake install scripts that correctly run with JRuby, so that's
probably good examples to follow. Unfortunately I have no clue how they
do it.

- Charlie

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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-20 03:19

Message:
Are you talking about the rubygems-generated wrapper script? What's the path of the script you're talking abouth (after installation and in our sources).


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-20 02:36

Message:
What is the best way to get around this?  I have a little script which searches the $PATH environment variable for a given name, hence:

euclid% find_file_in_path ruby
/opt/local/bin
/usr/local/bin
/usr/bin

euclid% find_file_in_path spec
/opt/local/bin

Would something like this be useful to use?  How about for the windows folks?

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

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

From noreply at rubyforge.org  Tue Mar 20 04:57:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Mar 2007 04:57:37 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-8103 ] RSpec not installing spec script
	correctly
Message-ID: <20070320085737.BB78B5240964@rubyforge.org>

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

Category: runner module
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: RSpec not installing spec script correctly

Initial Comment:
>From Charles Oliver Nutter:

Hey, I just noticed this today...installed RSpec with JRuby, and at the
top of the spec script:

#!/usr/bin/env ruby

That dog won't hunt, Monsignor.

Rails and rake install scripts that correctly run with JRuby, so that's
probably good examples to follow. Unfortunately I have no clue how they
do it.

- Charlie

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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-20 04:57

Message:
The reason why I'm asking is that rubygems generates files with

#!/usr/bin/env ruby

in the header - it's not RSpec. I need to know what Rubygems version you are using, and what the path of the said file is (so I can determine whether this is a file made by the RSpec team or the Rubygems program.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-20 03:19

Message:
Are you talking about the rubygems-generated wrapper script? What's the path of the script you're talking abouth (after installation and in our sources).


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-20 02:36

Message:
What is the best way to get around this?  I have a little script which searches the $PATH environment variable for a given name, hence:

euclid% find_file_in_path ruby
/opt/local/bin
/usr/local/bin
/usr/bin

euclid% find_file_in_path spec
/opt/local/bin

Would something like this be useful to use?  How about for the windows folks?

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

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

From noreply at rubyforge.org  Tue Mar 20 07:23:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Mar 2007 07:23:44 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-6707 ] cannot run controller / helper
	tests via rails_spec or spec only works with rake
Message-ID: <20070320112344.84B175240D7D@rubyforge.org>

Bugs item #6707, was opened at 2006-11-16 15:55
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6707&group_id=797

Category: rails plugin
Group: None
Status: Closed
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: David Chelimsky (dchelimsky)
Summary: cannot run controller / helper tests via rails_spec or spec only works with rake

Initial Comment:
I've tried four methods for running rails specs and here are the results for 0.7.2 (plugin and gem) on windows

ruby spec/controllers/admin/some_controller_spec.rb - WORKS but not sure if supposed to do things this way?

spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for <Spec::Runner::ContextEvalModule:0x3630680> (NoMethodError)

Start rails_spec_server then
ruby script\rails_spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for <Spec::Runner::ContextEvalModule:0x3630680> (NoMethodError) (SAME AS BEFORE)

rake spec - WORKS FINE

---
the sample test
---
require File.dirname(__FILE__) + '/../../spec_helper'

context "The Admin::TalentPoolsController" do
  # fixtures :talent_pools
  controller_name "admin/talent_pools"

  specify "should be a Admin::TalentPoolsController" do
    controller.should_be_an_instance_of Admin::TalentPoolsController
  end


  specify "should have more specifications" do
    violated "not enough specs"
  end
end
---
It seems that the module that contains the class method for controller_name does not get loaded except with rake / ruby?

we really need the test suite not to reload each time (current rake takes 25 minutes or longer!)
---
the same error happens with helpers and the call to helper_name


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

Comment By: Stephan Kaag (synchrosteve)
Date: 2007-03-20 12:23

Message:
I still run into the same error..

Im using
Rails 1.1.6
with:
RSpec 0.8.2 (r1560)
on:
a mac

to regenerate:
$ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_2/rspec_on_rails/vendor/plugins/rspec_on_rails
$ ./script/generate rspec
$ ./script/generate rspec_controller 'item'
$ cd spec/controllers/
$spec item_controller_spec.rb

result:
/usr/local/lib/ruby/gems/1.8/gems/rspec-0.8.2/lib/spec/expectations/sugar.rb:14:in `call': undefined method `controller_name' for #<Spec::Runner::ContextEvalModule:0x270e83c> (NoMethodError)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-17 05:15

Message:
Fixed in trunk (rev 1120).

The problem was a path Regexp that failed to account for windows slashes.

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

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

From noreply at rubyforge.org  Tue Mar 20 09:17:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Mar 2007 09:17:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-6707 ] cannot run controller / helper
	tests via rails_spec or spec only works with rake
Message-ID: <20070320131754.9081A5240DA1@rubyforge.org>

Bugs item #6707, was opened at 2006-11-16 14:55
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6707&group_id=797

Category: rails plugin
Group: None
>Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: David Chelimsky (dchelimsky)
Summary: cannot run controller / helper tests via rails_spec or spec only works with rake

Initial Comment:
I've tried four methods for running rails specs and here are the results for 0.7.2 (plugin and gem) on windows

ruby spec/controllers/admin/some_controller_spec.rb - WORKS but not sure if supposed to do things this way?

spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for <Spec::Runner::ContextEvalModule:0x3630680> (NoMethodError)

Start rails_spec_server then
ruby script\rails_spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for <Spec::Runner::ContextEvalModule:0x3630680> (NoMethodError) (SAME AS BEFORE)

rake spec - WORKS FINE

---
the sample test
---
require File.dirname(__FILE__) + '/../../spec_helper'

context "The Admin::TalentPoolsController" do
  # fixtures :talent_pools
  controller_name "admin/talent_pools"

  specify "should be a Admin::TalentPoolsController" do
    controller.should_be_an_instance_of Admin::TalentPoolsController
  end


  specify "should have more specifications" do
    violated "not enough specs"
  end
end
---
It seems that the module that contains the class method for controller_name does not get loaded except with rake / ruby?

we really need the test suite not to reload each time (current rake takes 25 minutes or longer!)
---
the same error happens with helpers and the call to helper_name


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

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

Message:
Stephan - do the rake tasks work for you?

Also, you CD'd into spec/controllers. How about standing in the project root and saying:

spec spec/controllers/item_controller_spec.rb

Does that produce a similar error?

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

Comment By: Stephan Kaag (synchrosteve)
Date: 2007-03-20 11:23

Message:
I still run into the same error..

Im using
Rails 1.1.6
with:
RSpec 0.8.2 (r1560)
on:
a mac

to regenerate:
$ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_2/rspec_on_rails/vendor/plugins/rspec_on_rails
$ ./script/generate rspec
$ ./script/generate rspec_controller 'item'
$ cd spec/controllers/
$spec item_controller_spec.rb

result:
/usr/local/lib/ruby/gems/1.8/gems/rspec-0.8.2/lib/spec/expectations/sugar.rb:14:in `call': undefined method `controller_name' for #<Spec::Runner::ContextEvalModule:0x270e83c> (NoMethodError)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-17 04:15

Message:
Fixed in trunk (rev 1120).

The problem was a path Regexp that failed to account for windows slashes.

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

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

From noreply at rubyforge.org  Tue Mar 20 09:38:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 20 Mar 2007 09:38:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-6707 ] cannot run controller / helper
	tests via rails_spec or spec only works with rake
Message-ID: <20070320133832.3EB275240D7F@rubyforge.org>

Bugs item #6707, was opened at 2006-11-16 15:55
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6707&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: David Chelimsky (dchelimsky)
Summary: cannot run controller / helper tests via rails_spec or spec only works with rake

Initial Comment:
I've tried four methods for running rails specs and here are the results for 0.7.2 (plugin and gem) on windows

ruby spec/controllers/admin/some_controller_spec.rb - WORKS but not sure if supposed to do things this way?

spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for <Spec::Runner::ContextEvalModule:0x3630680> (NoMethodError)

Start rails_spec_server then
ruby script\rails_spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for <Spec::Runner::ContextEvalModule:0x3630680> (NoMethodError) (SAME AS BEFORE)

rake spec - WORKS FINE

---
the sample test
---
require File.dirname(__FILE__) + '/../../spec_helper'

context "The Admin::TalentPoolsController" do
  # fixtures :talent_pools
  controller_name "admin/talent_pools"

  specify "should be a Admin::TalentPoolsController" do
    controller.should_be_an_instance_of Admin::TalentPoolsController
  end


  specify "should have more specifications" do
    violated "not enough specs"
  end
end
---
It seems that the module that contains the class method for controller_name does not get loaded except with rake / ruby?

we really need the test suite not to reload each time (current rake takes 25 minutes or longer!)
---
the same error happens with helpers and the call to helper_name


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

Comment By: Stephan Kaag (synchrosteve)
Date: 2007-03-20 14:38

Message:
David: rake tasks didn't produce an error
the command from the root map did the trick..

tnq..


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-20 14:17

Message:
Stephan - do the rake tasks work for you?

Also, you CD'd into spec/controllers. How about standing in the project root and saying:

spec spec/controllers/item_controller_spec.rb

Does that produce a similar error?

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

Comment By: Stephan Kaag (synchrosteve)
Date: 2007-03-20 12:23

Message:
I still run into the same error..

Im using
Rails 1.1.6
with:
RSpec 0.8.2 (r1560)
on:
a mac

to regenerate:
$ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_2/rspec_on_rails/vendor/plugins/rspec_on_rails
$ ./script/generate rspec
$ ./script/generate rspec_controller 'item'
$ cd spec/controllers/
$spec item_controller_spec.rb

result:
/usr/local/lib/ruby/gems/1.8/gems/rspec-0.8.2/lib/spec/expectations/sugar.rb:14:in `call': undefined method `controller_name' for #<Spec::Runner::ContextEvalModule:0x270e83c> (NoMethodError)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-17 05:15

Message:
Fixed in trunk (rev 1120).

The problem was a path Regexp that failed to account for windows slashes.

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

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

From deanwampler at gmail.com  Tue Mar 20 14:09:12 2007
From: deanwampler at gmail.com (Dean Wampler)
Date: Tue, 20 Mar 2007 13:09:12 -0500
Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects
In-Reply-To: <20070319134055.A83BA52409C1@rubyforge.org>
References: <20070319134055.A83BA52409C1@rubyforge.org>
Message-ID: <6cf2a94f0703201109r6538a2bfna4454db21013cebe@mail.gmail.com>

Maybe "scenario" or "(use)case"?

context "New Document instance" do
 scenario "(versioning)" do
   specify "should have no versions" do
     ...

context "New Document instance" do
 usecase "(versioning)" do
   specify "should have no versions" do
     ...

Hmm. Scenario seems better.

I agree that "aspect" is the wrong choice because of the association with AOP.

Dean

On 3/19/07, noreply at rubyforge.org <noreply at rubyforge.org> wrote:
> ..
> ----------------------------------------------------------------------
>
> Comment By: Wincent Colaiuta (wincent)
> Date: 2007-03-19 13:40
>
> Message:
> > Any other suggestions? I want to come up w/ the right name
> > before we add this.
>
> "Facet"?
>

-- 
Dean Wampler
http://www.objectmentor.com
http://www.aspectprogramming.com
http://www.contract4j.org

From mailing_lists at railsnewbie.com  Tue Mar 20 14:42:59 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Tue, 20 Mar 2007 14:42:59 -0400
Subject: [rspec-devel] [ rspec-Bugs-8103 ] RSpec not installing spec
	script correctly
In-Reply-To: <20070320085737.BB78B5240964@rubyforge.org>
References: <20070320085737.BB78B5240964@rubyforge.org>
Message-ID: <60897B5F-50A5-4C2E-B309-FAC7C95E7792@railsnewbie.com>


The only files that I can find are:

rspec/lib/spec/rake/spectask.rb
rspec/bin/spec

I've also noticed all the rails generators and severs also use it.

Scott


On Mar 20, 2007, at 4:57 AM, <noreply at rubyforge.org>   
<noreply at rubyforge.org> wrote:

> Bugs item #8103, was opened at 2007-01-24 02:22
> You can respond by visiting:
> http://rubyforge.org/tracker/? 
> func=detail&atid=3149&aid=8103&group_id=797
>
> Category: runner module
> Group: v1.0 (example)
> Status: Open
> Resolution: None
> Priority: 3
> Submitted By: Aslak Helles?y (aslak_hellesoy)
> Assigned to: Aslak Helles?y (aslak_hellesoy)
> Summary: RSpec not installing spec script correctly
>
> Initial Comment:
> From Charles Oliver Nutter:
>
> Hey, I just noticed this today...installed RSpec with JRuby, and at  
> the
> top of the spec script:
>
> #!/usr/bin/env ruby
>
> That dog won't hunt, Monsignor.
>
> Rails and rake install scripts that correctly run with JRuby, so  
> that's
> probably good examples to follow. Unfortunately I have no clue how  
> they
> do it.
>
> - Charlie
>
> ----------------------------------------------------------------------
>
>> Comment By: Aslak Helles?y (aslak_hellesoy)
> Date: 2007-03-20 04:57
>
> Message:
> The reason why I'm asking is that rubygems generates files with
>
> #!/usr/bin/env ruby
>
> in the header - it's not RSpec. I need to know what Rubygems  
> version you are using, and what the path of the said file is (so I  
> can determine whether this is a file made by the RSpec team or the  
> Rubygems program.
>
> ----------------------------------------------------------------------
>
> Comment By: Aslak Helles?y (aslak_hellesoy)
> Date: 2007-03-20 03:19
>
> Message:
> Are you talking about the rubygems-generated wrapper script? What's  
> the path of the script you're talking abouth (after installation  
> and in our sources).
>
>
> ----------------------------------------------------------------------
>
> Comment By: Scott Taylor (smtlaissezfaire)
> Date: 2007-03-20 02:36
>
> Message:
> What is the best way to get around this?  I have a little script  
> which searches the $PATH environment variable for a given name, hence:
>
> euclid% find_file_in_path ruby
> /opt/local/bin
> /usr/local/bin
> /usr/bin
>
> euclid% find_file_in_path spec
> /opt/local/bin
>
> Would something like this be useful to use?  How about for the  
> windows folks?
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> http://rubyforge.org/tracker/? 
> func=detail&atid=3149&aid=8103&group_id=797
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Tue Mar 20 17:52:49 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 20 Mar 2007 16:52:49 -0500
Subject: [rspec-devel] [ rspec-Feature Requests-8654 ] Aspects
In-Reply-To: <6cf2a94f0703201109r6538a2bfna4454db21013cebe@mail.gmail.com>
References: <20070319134055.A83BA52409C1@rubyforge.org>
	<6cf2a94f0703201109r6538a2bfna4454db21013cebe@mail.gmail.com>
Message-ID: <57c63afe0703201452t63c29e6fy88786e2a373ead39@mail.gmail.com>

On 3/20/07, Dean Wampler <deanwampler at gmail.com> wrote:
> Maybe "scenario" or "(use)case"?

"scenario" has some baggage associated with it as well, not to mention
that it means something specific in BDD - granular acceptance criteria
for a user story.

Unfortunately, a lot of otherwise good words have been gobbled up.

Keep 'em coming!

David


>
> context "New Document instance" do
>  scenario "(versioning)" do
>    specify "should have no versions" do
>      ...
>
> context "New Document instance" do
>  usecase "(versioning)" do
>    specify "should have no versions" do
>      ...
>
> Hmm. Scenario seems better.
>
> I agree that "aspect" is the wrong choice because of the association with AOP.
>
> Dean
>
> On 3/19/07, noreply at rubyforge.org <noreply at rubyforge.org> wrote:
> > ..
> > ----------------------------------------------------------------------
> >
> > Comment By: Wincent Colaiuta (wincent)
> > Date: 2007-03-19 13:40
> >
> > Message:
> > > Any other suggestions? I want to come up w/ the right name
> > > before we add this.
> >
> > "Facet"?
> >
>
> --
> Dean Wampler
> http://www.objectmentor.com
> http://www.aspectprogramming.com
> http://www.contract4j.org
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From mailing_lists at railsnewbie.com  Wed Mar 21 02:07:58 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 02:07:58 -0400
Subject: [rspec-devel] spec's for edge failing
Message-ID: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>


If I run rake spec for spec's edge (revision ...), I get the  
following spec which isn't passing:

1)
Errno::ENOENT in 'HtmlFormatter should produce HTML identical to the  
one we designed manually'
No such file or directory - ./spec/spec/runner/formatter/ 
html_formatted-1.8.6.html
./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
./spec/spec/runner/formatter/html_formatter_spec.rb:8:
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/specification.rb:75:in `instance_eval'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/specification.rb:75:in `execute_spec'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/specification.rb:40:in `run'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/context.rb:37:in `run'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/context.rb:34:in `each'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/context.rb:34:in `run'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/context_runner.rb:27:in `run'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/context_runner.rb:26:in `each'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/context_runner.rb:26:in `run'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/ 
spec/runner/command_line.rb:17:in `run'
/Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/bin/ 
spec:4:
/opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in `load'
/opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
/opt/local/bin/rcov:16:in `load'
/opt/local/bin/rcov:16:

I'm trying to submit a patch, so I'll wait for you guys to fix this one,

Scott

From aslak.hellesoy at gmail.com  Wed Mar 21 04:07:00 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 21 Mar 2007 09:07:00 +0100
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
Message-ID: <8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>

On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> If I run rake spec for spec's edge (revision ...), I get the
> following spec which isn't passing:
>
> 1)
> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to the
> one we designed manually'
> No such file or directory - ./spec/spec/runner/formatter/
> html_formatted-1.8.6.html

Due to differences in the way different rubies render backtraces, we
need one expected html
file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
solution is to add the missing file. Also look at the failing spec.

> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/specification.rb:75:in `instance_eval'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/specification.rb:75:in `execute_spec'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/specification.rb:40:in `run'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/context.rb:37:in `run'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/context.rb:34:in `each'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/context.rb:34:in `run'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/context_runner.rb:27:in `run'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/context_runner.rb:26:in `each'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/context_runner.rb:26:in `run'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> spec/runner/command_line.rb:17:in `run'
> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/bin/
> spec:4:
> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in `load'
> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
> /opt/local/bin/rcov:16:in `load'
> /opt/local/bin/rcov:16:
>
> I'm trying to submit a patch, so I'll wait for you guys to fix this one,
>

What do you mean? Are you submitting a patch that fixes this?

Aslak

> Scott
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Wed Mar 21 04:19:11 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 21 Mar 2007 09:19:11 +0100
Subject: [rspec-devel] describe-it: what do we call our files?
Message-ID: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>

On the 0.9-dev branch the context-specify pair has been largely
replaced by describe-it, thanks to a brilliant suggestion by Dan
North.

I've been writing err TESTS ;-) in this format for a while now, and I
really dig it. It pushes me even further to think about behaviour,
because it *reads* much better than before:

describe "Coffee for Aslak" do # Creates a new Spec::DSL::Behaviour
  it "should never have sugar" do # Creates a new Spec::DSL::Example
    ...
  end
end

So far so good. My question to the list is:

Assuming describe-it is the recommended way forward, how should we
name our files?
I'm leaning towards coffee_behaviour.rb.

Is this the end of specs and speccing/spec'ing and the start of
behaviours and examplifications?

(We'll support context-specify for a while still)

WDYT?

Aslak

From noreply at rubyforge.org  Wed Mar 21 06:11:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Mar 2007 06:11:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9421 ] --line doesn't work with
	behaviours that use class names
Message-ID: <20070321101116.7283EA970004@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: David Chelimsky (dchelimsky)
Summary: --line doesn't work with behaviours that use class names

Initial Comment:
To reproduce, do:

ruby bin/spec spec/spec/dsl/behaviour_spec.rb -l 22

Finished in 1.4e-05 seconds

0 examples, 0 failures

This is because SpecParser always looks for quotes - it has to be smarter


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

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

From mailing_lists at railsnewbie.com  Wed Mar 21 06:39:26 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 06:39:26 -0400
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
Message-ID: <0F3FAC7D-B750-49E0-88A2-D1E9BF0F26E2@railsnewbie.com>


Ah, I see what you mean.  One confusion:

If I run the specs from the rspec/ dir, I get a different file than  
from the trunk dir.

Which shall I use?


Thanks,

Scott



On Mar 21, 2007, at 4:07 AM, aslak hellesoy wrote:

> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> If I run rake spec for spec's edge (revision ...), I get the
>> following spec which isn't passing:
>>
>> 1)
>> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to the
>> one we designed manually'
>> No such file or directory - ./spec/spec/runner/formatter/
>> html_formatted-1.8.6.html
>
> Due to differences in the way different rubies render backtraces, we
> need one expected html
> file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
> solution is to add the missing file. Also look at the failing spec.
>
>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/specification.rb:75:in `instance_eval'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/specification.rb:75:in `execute_spec'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/specification.rb:40:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context.rb:37:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context.rb:34:in `each'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context.rb:34:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context_runner.rb:27:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context_runner.rb:26:in `each'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context_runner.rb:26:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/command_line.rb:17:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/bin/
>> spec:4:
>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in `load'
>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
>> /opt/local/bin/rcov:16:in `load'
>> /opt/local/bin/rcov:16:
>>
>> I'm trying to submit a patch, so I'll wait for you guys to fix  
>> this one,
>>
>
> What do you mean? Are you submitting a patch that fixes this?
>
> Aslak
>
>> Scott
>> _______________________________________________
>> 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 mailing_lists at railsnewbie.com  Wed Mar 21 06:42:26 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 06:42:26 -0400
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
Message-ID: <F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>


I probably should have clarified the last email.

If I simply copy html_formatted-1.8.5.html to html_formatted-1.8.6  
and run it from the spec's from the trunk directory, I have no  
problems.  But if I run the specs from the rspec directory, I get  
something like this:

Diff:
@@ -119,11 +119,11 @@
        <div class="failure" id="failure_1">
          <div class="message"><pre>Mock 'poke me' expected :poke  
with (any args) once, but received it 0 times</pre></div>
          <div class="backtrace"><pre>./failing_examples/ 
mocking_example.rb:13:
-./html_formatter_spec.rb:19:
-./html_formatter_spec.rb:15:in `chdir'
-./html_formatter_spec.rb:15:
-./html_formatter_spec.rb:14:in `each'
-./html_formatter_spec.rb:14:</pre></div>
+./spec/spec/runner/formatter/html_formatter_spec.rb:16:
+./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
+./spec/spec/runner/formatter/html_formatter_spec.rb:12:
+./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
+./spec/spec/runner/formatter/html_formatter_spec.rb:11:</pre></div>


As you can see, the line numbers change based on where the spec is  
run from.  So should I run the specs from the trunk or from the rspec  
dir?

Scott


On Mar 21, 2007, at 4:07 AM, aslak hellesoy wrote:

> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> If I run rake spec for spec's edge (revision ...), I get the
>> following spec which isn't passing:
>>
>> 1)
>> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to the
>> one we designed manually'
>> No such file or directory - ./spec/spec/runner/formatter/
>> html_formatted-1.8.6.html
>
> Due to differences in the way different rubies render backtraces, we
> need one expected html
> file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
> solution is to add the missing file. Also look at the failing spec.
>
>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/specification.rb:75:in `instance_eval'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/specification.rb:75:in `execute_spec'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/specification.rb:40:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context.rb:37:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context.rb:34:in `each'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context.rb:34:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context_runner.rb:27:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context_runner.rb:26:in `each'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/context_runner.rb:26:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
>> spec/runner/command_line.rb:17:in `run'
>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/bin/
>> spec:4:
>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in `load'
>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
>> /opt/local/bin/rcov:16:in `load'
>> /opt/local/bin/rcov:16:
>>
>> I'm trying to submit a patch, so I'll wait for you guys to fix  
>> this one,
>>
>
> What do you mean? Are you submitting a patch that fixes this?
>
> Aslak
>
>> Scott
>> _______________________________________________
>> 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 mailing_lists at railsnewbie.com  Wed Mar 21 06:49:50 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 06:49:50 -0400
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
	<F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
Message-ID: <F5C4A91D-19F5-4BD6-AF73-AD011AA4B25C@railsnewbie.com>


Looks like I spoke "what is not" in the last few emails.  Disregard  
them.

Sorry,

Scott


On Mar 21, 2007, at 6:42 AM, Scott Taylor wrote:

>
> I probably should have clarified the last email.
>
> If I simply copy html_formatted-1.8.5.html to html_formatted-1.8.6
> and run it from the spec's from the trunk directory, I have no
> problems.  But if I run the specs from the rspec directory, I get
> something like this:
>
> Diff:
> @@ -119,11 +119,11 @@
>         <div class="failure" id="failure_1">
>           <div class="message"><pre>Mock 'poke me' expected :poke
> with (any args) once, but received it 0 times</pre></div>
>           <div class="backtrace"><pre>./failing_examples/
> mocking_example.rb:13:
> -./html_formatter_spec.rb:19:
> -./html_formatter_spec.rb:15:in `chdir'
> -./html_formatter_spec.rb:15:
> -./html_formatter_spec.rb:14:in `each'
> -./html_formatter_spec.rb:14:</pre></div>
> +./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
> +./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11:</pre></div>
>
>
> As you can see, the line numbers change based on where the spec is
> run from.  So should I run the specs from the trunk or from the rspec
> dir?
>
> Scott
>
>
> On Mar 21, 2007, at 4:07 AM, aslak hellesoy wrote:
>
>> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>
>>> If I run rake spec for spec's edge (revision ...), I get the
>>> following spec which isn't passing:
>>>
>>> 1)
>>> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to the
>>> one we designed manually'
>>> No such file or directory - ./spec/spec/runner/formatter/
>>> html_formatted-1.8.6.html
>>
>> Due to differences in the way different rubies render backtraces, we
>> need one expected html
>> file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
>> solution is to add the missing file. Also look at the failing spec.
>>
>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/specification.rb:75:in `instance_eval'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/specification.rb:75:in `execute_spec'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/specification.rb:40:in `run'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/context.rb:37:in `run'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/context.rb:34:in `each'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/context.rb:34:in `run'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/context_runner.rb:27:in `run'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/context_runner.rb:26:in `each'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/context_runner.rb:26:in `run'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> lib/
>>> spec/runner/command_line.rb:17:in `run'
>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>> bin/
>>> spec:4:
>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in  
>>> `load'
>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
>>> /opt/local/bin/rcov:16:in `load'
>>> /opt/local/bin/rcov:16:
>>>
>>> I'm trying to submit a patch, so I'll wait for you guys to fix
>>> this one,
>>>
>>
>> What do you mean? Are you submitting a patch that fixes this?
>>
>> Aslak
>>
>>> Scott
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From mailing_lists at railsnewbie.com  Wed Mar 21 07:24:43 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 07:24:43 -0400
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <F5C4A91D-19F5-4BD6-AF73-AD011AA4B25C@railsnewbie.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
	<F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
	<F5C4A91D-19F5-4BD6-AF73-AD011AA4B25C@railsnewbie.com>
Message-ID: <64B8CA0A-A7FA-4F3E-946C-363AE5DA17B9@railsnewbie.com>


So, your suggestion to remove the bug has made me go on a hunt to  
remove it! :)

Here is one thing I can't figure out.  If I add a blank line to the  
spec (i.e. I use this as the spec:

require File.dirname(__FILE__) + '/../../../spec_helper.rb'
require 'stringio'

context "HtmlFormatter" do
   specify "should produce HTML identical to the one we designed  
manually" do
     root = File.expand_path(File.dirname(__FILE__) + '/../../../..')
     expected_file = File.dirname(__FILE__) + "/html_formatted-# 
{VERSION}.html"
     .....


(as opposed to this - they are the same except the one blank line)

require File.dirname(__FILE__) + '/../../../spec_helper.rb'
require 'stringio'

context "HtmlFormatter" do
   specify "should produce HTML identical to the one we designed  
manually" do
     root = File.expand_path(File.dirname(__FILE__) + '/../../../..')

     expected_file = File.dirname(__FILE__) + "/html_formatted-# 
{VERSION}.html"
     ....


then the spec numbers get thrown off by one in the generated html.   
The spec numbers are off by two with two blank lines, and so on.  Why  
is this the case?

Best,

Scott



On Mar 21, 2007, at 6:49 AM, Scott Taylor wrote:

>
> Looks like I spoke "what is not" in the last few emails.  Disregard
> them.
>
> Sorry,
>
> Scott
>
>
> On Mar 21, 2007, at 6:42 AM, Scott Taylor wrote:
>
>>
>> I probably should have clarified the last email.
>>
>> If I simply copy html_formatted-1.8.5.html to html_formatted-1.8.6
>> and run it from the spec's from the trunk directory, I have no
>> problems.  But if I run the specs from the rspec directory, I get
>> something like this:
>>
>> Diff:
>> @@ -119,11 +119,11 @@
>>         <div class="failure" id="failure_1">
>>           <div class="message"><pre>Mock 'poke me' expected :poke
>> with (any args) once, but received it 0 times</pre></div>
>>           <div class="backtrace"><pre>./failing_examples/
>> mocking_example.rb:13:
>> -./html_formatter_spec.rb:19:
>> -./html_formatter_spec.rb:15:in `chdir'
>> -./html_formatter_spec.rb:15:
>> -./html_formatter_spec.rb:14:in `each'
>> -./html_formatter_spec.rb:14:</pre></div>
>> +./spec/spec/runner/formatter/html_formatter_spec.rb:16:
>> +./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
>> +./spec/spec/runner/formatter/html_formatter_spec.rb:12:
>> +./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
>> +./spec/spec/runner/formatter/html_formatter_spec.rb:11:</pre></div>
>>
>>
>> As you can see, the line numbers change based on where the spec is
>> run from.  So should I run the specs from the trunk or from the rspec
>> dir?
>>
>> Scott
>>
>>
>> On Mar 21, 2007, at 4:07 AM, aslak hellesoy wrote:
>>
>>> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>>
>>>> If I run rake spec for spec's edge (revision ...), I get the
>>>> following spec which isn't passing:
>>>>
>>>> 1)
>>>> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to  
>>>> the
>>>> one we designed manually'
>>>> No such file or directory - ./spec/spec/runner/formatter/
>>>> html_formatted-1.8.6.html
>>>
>>> Due to differences in the way different rubies render backtraces, we
>>> need one expected html
>>> file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
>>> solution is to add the missing file. Also look at the failing spec.
>>>
>>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
>>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/specification.rb:75:in `instance_eval'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/specification.rb:75:in `execute_spec'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/specification.rb:40:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/context.rb:37:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/context.rb:34:in `each'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/context.rb:34:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/context_runner.rb:27:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/context_runner.rb:26:in `each'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/context_runner.rb:26:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> lib/
>>>> spec/runner/command_line.rb:17:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
>>>> bin/
>>>> spec:4:
>>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in
>>>> `load'
>>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
>>>> /opt/local/bin/rcov:16:in `load'
>>>> /opt/local/bin/rcov:16:
>>>>
>>>> I'm trying to submit a patch, so I'll wait for you guys to fix
>>>> this one,
>>>>
>>>
>>> What do you mean? Are you submitting a patch that fixes this?
>>>
>>> Aslak
>>>
>>>> Scott
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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 aslak.hellesoy at gmail.com  Wed Mar 21 07:29:32 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 21 Mar 2007 12:29:32 +0100
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
	<F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
Message-ID: <8d961d900703210429y2d76788bve0cc8473751ad5ca@mail.gmail.com>

On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> I probably should have clarified the last email.
>
> If I simply copy html_formatted-1.8.5.html to html_formatted-1.8.6
> and run it from the spec's from the trunk directory, I have no
> problems.  But if I run the specs from the rspec directory, I get
> something like this:
>
> Diff:
> @@ -119,11 +119,11 @@
>         <div class="failure" id="failure_1">
>           <div class="message"><pre>Mock 'poke me' expected :poke
> with (any args) once, but received it 0 times</pre></div>
>           <div class="backtrace"><pre>./failing_examples/
> mocking_example.rb:13:
> -./html_formatter_spec.rb:19:
> -./html_formatter_spec.rb:15:in `chdir'
> -./html_formatter_spec.rb:15:
> -./html_formatter_spec.rb:14:in `each'
> -./html_formatter_spec.rb:14:</pre></div>
> +./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
> +./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
> +./spec/spec/runner/formatter/html_formatter_spec.rb:11:</pre></div>
>
>
> As you can see, the line numbers change based on where the spec is
> run from.  So should I run the specs from the trunk or from the rspec
> dir?

>From the rspec dir. And please use branches/0.9-dev - this is where
work is currently happening. We'll notify the list when we go back to
trunk.

We don't write the expected HTML files by hand. Instead, we comment
out the File.open line in html_formatter_spec.rb. We eyeball the
generated HTML, and if it looks good, put the comment back and use
this as the expected HTML from there on.

Aslak

>
> Scott
>
>
> On Mar 21, 2007, at 4:07 AM, aslak hellesoy wrote:
>
> > On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >>
> >> If I run rake spec for spec's edge (revision ...), I get the
> >> following spec which isn't passing:
> >>
> >> 1)
> >> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to the
> >> one we designed manually'
> >> No such file or directory - ./spec/spec/runner/formatter/
> >> html_formatted-1.8.6.html
> >
> > Due to differences in the way different rubies render backtraces, we
> > need one expected html
> > file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
> > solution is to add the missing file. Also look at the failing spec.
> >
> >> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
> >> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/specification.rb:75:in `instance_eval'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/specification.rb:75:in `execute_spec'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/specification.rb:40:in `run'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/context.rb:37:in `run'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/context.rb:34:in `each'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/context.rb:34:in `run'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/context_runner.rb:27:in `run'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/context_runner.rb:26:in `each'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/context_runner.rb:26:in `run'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/lib/
> >> spec/runner/command_line.rb:17:in `run'
> >> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/bin/
> >> spec:4:
> >> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in `load'
> >> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
> >> /opt/local/bin/rcov:16:in `load'
> >> /opt/local/bin/rcov:16:
> >>
> >> I'm trying to submit a patch, so I'll wait for you guys to fix
> >> this one,
> >>
> >
> > What do you mean? Are you submitting a patch that fixes this?
> >
> > Aslak
> >
> >> Scott
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Mar 21 07:35:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Mar 2007 07:35:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9423 ] --diff is broken for Strings
Message-ID: <20070321113541.1E31A5240955@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: David Chelimsky (dchelimsky)
Summary: --diff is broken for Strings

Initial Comment:
To reproduce:
ruby bin/spec failing_examples/diffing_spec.rb --diff  

Only the second example produces a diff, but both should.

I think this is a quite recent regression, and it seems to have to do with the arguments passed to Spec::Expectations#fail_with (spec/expectations.rb). For some odd reason it only diffs when the message is an Array of length 3, which doesn't happen when two different strings are compared. I got lost trying to figure out why.



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

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

From aslak.hellesoy at gmail.com  Wed Mar 21 07:39:45 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 21 Mar 2007 12:39:45 +0100
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <64B8CA0A-A7FA-4F3E-946C-363AE5DA17B9@railsnewbie.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
	<F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
	<F5C4A91D-19F5-4BD6-AF73-AD011AA4B25C@railsnewbie.com>
	<64B8CA0A-A7FA-4F3E-946C-363AE5DA17B9@railsnewbie.com>
Message-ID: <8d961d900703210439l2e72974fkae0a8686da61d901@mail.gmail.com>

On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> So, your suggestion to remove the bug has made me go on a hunt to
> remove it! :)
>

I'm still confused about what you meant in your first post when you
said "I'm trying to submit a patch, (...)"

I thought maybe you were saying that you were going to fix this bug.

And disregard my last comment about the branch - it's ok to do it on trunk.

Run the spec once with the File.open line commented out. It should
pass on the next run.

Aslak

> Here is one thing I can't figure out.  If I add a blank line to the
> spec (i.e. I use this as the spec:
>
> require File.dirname(__FILE__) + '/../../../spec_helper.rb'
> require 'stringio'
>
> context "HtmlFormatter" do
>    specify "should produce HTML identical to the one we designed
> manually" do
>      root = File.expand_path(File.dirname(__FILE__) + '/../../../..')
>      expected_file = File.dirname(__FILE__) + "/html_formatted-#
> {VERSION}.html"
>      .....
>
>
> (as opposed to this - they are the same except the one blank line)
>
> require File.dirname(__FILE__) + '/../../../spec_helper.rb'
> require 'stringio'
>
> context "HtmlFormatter" do
>    specify "should produce HTML identical to the one we designed
> manually" do
>      root = File.expand_path(File.dirname(__FILE__) + '/../../../..')
>
>      expected_file = File.dirname(__FILE__) + "/html_formatted-#
> {VERSION}.html"
>      ....
>
>
> then the spec numbers get thrown off by one in the generated html.
> The spec numbers are off by two with two blank lines, and so on.  Why
> is this the case?
>
> Best,
>
> Scott
>
>
>
> On Mar 21, 2007, at 6:49 AM, Scott Taylor wrote:
>
> >
> > Looks like I spoke "what is not" in the last few emails.  Disregard
> > them.
> >
> > Sorry,
> >
> > Scott
> >
> >
> > On Mar 21, 2007, at 6:42 AM, Scott Taylor wrote:
> >
> >>
> >> I probably should have clarified the last email.
> >>
> >> If I simply copy html_formatted-1.8.5.html to html_formatted-1.8.6
> >> and run it from the spec's from the trunk directory, I have no
> >> problems.  But if I run the specs from the rspec directory, I get
> >> something like this:
> >>
> >> Diff:
> >> @@ -119,11 +119,11 @@
> >>         <div class="failure" id="failure_1">
> >>           <div class="message"><pre>Mock 'poke me' expected :poke
> >> with (any args) once, but received it 0 times</pre></div>
> >>           <div class="backtrace"><pre>./failing_examples/
> >> mocking_example.rb:13:
> >> -./html_formatter_spec.rb:19:
> >> -./html_formatter_spec.rb:15:in `chdir'
> >> -./html_formatter_spec.rb:15:
> >> -./html_formatter_spec.rb:14:in `each'
> >> -./html_formatter_spec.rb:14:</pre></div>
> >> +./spec/spec/runner/formatter/html_formatter_spec.rb:16:
> >> +./spec/spec/runner/formatter/html_formatter_spec.rb:12:in `chdir'
> >> +./spec/spec/runner/formatter/html_formatter_spec.rb:12:
> >> +./spec/spec/runner/formatter/html_formatter_spec.rb:11:in `each'
> >> +./spec/spec/runner/formatter/html_formatter_spec.rb:11:</pre></div>
> >>
> >>
> >> As you can see, the line numbers change based on where the spec is
> >> run from.  So should I run the specs from the trunk or from the rspec
> >> dir?
> >>
> >> Scott
> >>
> >>
> >> On Mar 21, 2007, at 4:07 AM, aslak hellesoy wrote:
> >>
> >>> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >>>>
> >>>> If I run rake spec for spec's edge (revision ...), I get the
> >>>> following spec which isn't passing:
> >>>>
> >>>> 1)
> >>>> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to
> >>>> the
> >>>> one we designed manually'
> >>>> No such file or directory - ./spec/spec/runner/formatter/
> >>>> html_formatted-1.8.6.html
> >>>
> >>> Due to differences in the way different rubies render backtraces, we
> >>> need one expected html
> >>> file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
> >>> solution is to add the missing file. Also look at the failing spec.
> >>>
> >>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
> >>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/specification.rb:75:in `instance_eval'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/specification.rb:75:in `execute_spec'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/specification.rb:40:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context.rb:37:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context.rb:34:in `each'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context.rb:34:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context_runner.rb:27:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context_runner.rb:26:in `each'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context_runner.rb:26:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/command_line.rb:17:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> bin/
> >>>> spec:4:
> >>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in
> >>>> `load'
> >>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
> >>>> /opt/local/bin/rcov:16:in `load'
> >>>> /opt/local/bin/rcov:16:
> >>>>
> >>>> I'm trying to submit a patch, so I'll wait for you guys to fix
> >>>> this one,
> >>>>
> >>>
> >>> What do you mean? Are you submitting a patch that fixes this?
> >>>
> >>> Aslak
> >>>
> >>>> Scott
> >>>> _______________________________________________
> >>>> 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
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From mailing_lists at railsnewbie.com  Wed Mar 21 07:43:44 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 07:43:44 -0400
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <8d961d900703210429y2d76788bve0cc8473751ad5ca@mail.gmail.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
	<F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
	<8d961d900703210429y2d76788bve0cc8473751ad5ca@mail.gmail.com>
Message-ID: <7AC2F3FF-72E8-4711-94D8-D01A4D867F88@railsnewbie.com>


So you let the spec fail, and look at the diff?  I think I'll do that.

Scott



> work is currently happening. We'll notify the list when we go back to
> trunk.
>
> We don't write the expected HTML files by hand. Instead, we comment
> out the File.open line in html_formatter_spec.rb. We eyeball the
> generated HTML, and if it looks good, put the comment back and use
> this as the expected HTML from there on.
>
> Aslak
>
>>
>> Scott
>>
>>
>> On Mar 21, 2007, at 4:07 AM, aslak hellesoy wrote:
>>
>>> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>>
>>>> If I run rake spec for spec's edge (revision ...), I get the
>>>> following spec which isn't passing:
>>>>
>>>> 1)
>>>> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to  
>>>> the
>>>> one we designed manually'
>>>> No such file or directory - ./spec/spec/runner/formatter/
>>>> html_formatted-1.8.6.html
>>>
>>> Due to differences in the way different rubies render backtraces, we
>>> need one expected html
>>> file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
>>> solution is to add the missing file. Also look at the failing spec.
>>>
>>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
>>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/specification.rb:75:in `instance_eval'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/specification.rb:75:in `execute_spec'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/specification.rb:40:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/context.rb:37:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/context.rb:34:in `each'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/context.rb:34:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/context_runner.rb:27:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/context_runner.rb:26:in `each'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/context_runner.rb:26:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> lib/
>>>> spec/runner/command_line.rb:17:in `run'
>>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/ 
>>>> bin/
>>>> spec:4:
>>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in  
>>>> `load'
>>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
>>>> /opt/local/bin/rcov:16:in `load'
>>>> /opt/local/bin/rcov:16:
>>>>
>>>> I'm trying to submit a patch, so I'll wait for you guys to fix
>>>> this one,
>>>>
>>>
>>> What do you mean? Are you submitting a patch that fixes this?
>>>
>>> Aslak
>>>
>>>> Scott
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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 mailing_lists at railsnewbie.com  Wed Mar 21 07:44:05 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 07:44:05 -0400
Subject: [rspec-devel] webgen
Message-ID: <97786FC3-1E49-4859-9B0D-3FA80A0B2682@railsnewbie.com>


What version(s) of webgen are you running?  I'm having the following  
problem with webgen when  running rake pre_commit:

sudo gem install webgen

ERROR while running webgen: /opt/local/lib/ruby/site_ruby/1.8/ 
rubygems/custom_require.rb:27:in `gem_original_require': no such file  
to load -- webgen/plugins/tags/tags (LoadError)
         from /opt/local/lib/ruby/site_ruby/1.8/rubygems/ 
custom_require.rb:27:in `require'
         from /Users/smtlaissezfaire/ruby/projects/rspec/trunk/doc/ 
plugin/version.rb:1:in `load_plugin'
         from /opt/local/lib/ruby/gems/1.8/gems/webgen-0.4.2/lib/ 
webgen/plugin.rb:224:in `load_from_file'
...

Scott


From aslak.hellesoy at gmail.com  Wed Mar 21 07:45:30 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 21 Mar 2007 12:45:30 +0100
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <7AC2F3FF-72E8-4711-94D8-D01A4D867F88@railsnewbie.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
	<F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
	<8d961d900703210429y2d76788bve0cc8473751ad5ca@mail.gmail.com>
	<7AC2F3FF-72E8-4711-94D8-D01A4D867F88@railsnewbie.com>
Message-ID: <8d961d900703210445p7588e6d9u38bb258009eebeb8@mail.gmail.com>

On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> So you let the spec fail, and look at the diff?  I think I'll do that.
>

1) uncomment the File.open line in the spec
2) run the spec (it should fail)
3) put the comment back
4) run the spec (it should pass now)
5) eyeball the html file to see if it's ok
6) create a patch

aslak

> Scott
>
>
>
> > work is currently happening. We'll notify the list when we go back to
> > trunk.
> >
> > We don't write the expected HTML files by hand. Instead, we comment
> > out the File.open line in html_formatter_spec.rb. We eyeball the
> > generated HTML, and if it looks good, put the comment back and use
> > this as the expected HTML from there on.
> >
> > Aslak
> >
> >>
> >> Scott
> >>
> >>
> >> On Mar 21, 2007, at 4:07 AM, aslak hellesoy wrote:
> >>
> >>> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >>>>
> >>>> If I run rake spec for spec's edge (revision ...), I get the
> >>>> following spec which isn't passing:
> >>>>
> >>>> 1)
> >>>> Errno::ENOENT in 'HtmlFormatter should produce HTML identical to
> >>>> the
> >>>> one we designed manually'
> >>>> No such file or directory - ./spec/spec/runner/formatter/
> >>>> html_formatted-1.8.6.html
> >>>
> >>> Due to differences in the way different rubies render backtraces, we
> >>> need one expected html
> >>> file per ruby version. So far we've only used 1.8.4 and 1.8.5. The
> >>> solution is to add the missing file. Also look at the failing spec.
> >>>
> >>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:in `read'
> >>>> ./spec/spec/runner/formatter/html_formatter_spec.rb:8:
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/specification.rb:75:in `instance_eval'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/specification.rb:75:in `execute_spec'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/specification.rb:40:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context.rb:37:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context.rb:34:in `each'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context.rb:34:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context_runner.rb:27:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context_runner.rb:26:in `each'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/context_runner.rb:26:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> lib/
> >>>> spec/runner/command_line.rb:17:in `run'
> >>>> /Users/smtlaissezfaire/proj/ruby/projects/rspec_copy/trunk/rspec/
> >>>> bin/
> >>>> spec:4:
> >>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:in
> >>>> `load'
> >>>> /opt/local/lib/ruby/gems/1.8/gems/rcov-0.8.0.2/bin/rcov:516:
> >>>> /opt/local/bin/rcov:16:in `load'
> >>>> /opt/local/bin/rcov:16:
> >>>>
> >>>> I'm trying to submit a patch, so I'll wait for you guys to fix
> >>>> this one,
> >>>>
> >>>
> >>> What do you mean? Are you submitting a patch that fixes this?
> >>>
> >>> Aslak
> >>>
> >>>> Scott
> >>>> _______________________________________________
> >>>> 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
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Wed Mar 21 07:50:12 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 21 Mar 2007 12:50:12 +0100
Subject: [rspec-devel] webgen
In-Reply-To: <97786FC3-1E49-4859-9B0D-3FA80A0B2682@railsnewbie.com>
References: <97786FC3-1E49-4859-9B0D-3FA80A0B2682@railsnewbie.com>
Message-ID: <8d961d900703210450s2059e6f1ra2e01e3bee72561d@mail.gmail.com>

On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> What version(s) of webgen are you running?  I'm having the following
> problem with webgen when  running rake pre_commit:
>

0.3.8

> sudo gem install webgen
>
> ERROR while running webgen: /opt/local/lib/ruby/site_ruby/1.8/
> rubygems/custom_require.rb:27:in `gem_original_require': no such file
> to load -- webgen/plugins/tags/tags (LoadError)
>          from /opt/local/lib/ruby/site_ruby/1.8/rubygems/
> custom_require.rb:27:in `require'
>          from /Users/smtlaissezfaire/ruby/projects/rspec/trunk/doc/
> plugin/version.rb:1:in `load_plugin'
>          from /opt/local/lib/ruby/gems/1.8/gems/webgen-0.4.2/lib/
> webgen/plugin.rb:224:in `load_from_file'
> ...
>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Mar 21 07:52:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Mar 2007 07:52:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9423 ] --diff is broken for Strings
Message-ID: <20070321115239.D469D5240958@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: David Chelimsky (dchelimsky)
Summary: --diff is broken for Strings

Initial Comment:
To reproduce:
ruby bin/spec failing_examples/diffing_spec.rb --diff  

Only the second example produces a diff, but both should.

I think this is a quite recent regression, and it seems to have to do with the arguments passed to Spec::Expectations#fail_with (spec/expectations.rb). For some odd reason it only diffs when the message is an Array of length 3, which doesn't happen when two different strings are compared. I got lost trying to figure out why.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-21 11:52

Message:
FYI - this is in the 0.9-dev branch.

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

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

From mailing_lists at railsnewbie.com  Wed Mar 21 07:54:31 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 07:54:31 -0400
Subject: [rspec-devel] spec's for edge failing
In-Reply-To: <8d961d900703210439l2e72974fkae0a8686da61d901@mail.gmail.com>
References: <511E3607-827B-463F-8708-7E980A25D3B4@railsnewbie.com>
	<8d961d900703210107v678c0172u2c8d8ae7c2ab4e1f@mail.gmail.com>
	<F16C2428-CB6D-4C94-B70F-233C3350FAF5@railsnewbie.com>
	<F5C4A91D-19F5-4BD6-AF73-AD011AA4B25C@railsnewbie.com>
	<64B8CA0A-A7FA-4F3E-946C-363AE5DA17B9@railsnewbie.com>
	<8d961d900703210439l2e72974fkae0a8686da61d901@mail.gmail.com>
Message-ID: <28091B8D-A7C5-4551-9FFD-F360E6806342@railsnewbie.com>


On Mar 21, 2007, at 7:39 AM, aslak hellesoy wrote:

>>
>
> I'm still confused about what you meant in your first post when you
> said "I'm trying to submit a patch, (...)"

It is unrelated to this.  It is not a bugfix, but an enhancement, so  
that spec.opts can use a single line (or multiple lines) for the  
options.  Just a one-liner.  But rake pre_commit has led me off into  
this tangent.

Scott


>
> I thought maybe you were saying that you were going to fix this bug.
>
> And disregard my last comment about the branch - it's ok to do it  
> on trunk.
>
> Run the spec once with the File.open line commented out. It should
> pass on the next run.
>
> Aslak
>


From mailing_lists at railsnewbie.com  Wed Mar 21 08:07:49 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 08:07:49 -0400
Subject: [rspec-devel] webgen
In-Reply-To: <8d961d900703210450s2059e6f1ra2e01e3bee72561d@mail.gmail.com>
References: <97786FC3-1E49-4859-9B0D-3FA80A0B2682@railsnewbie.com>
	<8d961d900703210450s2059e6f1ra2e01e3bee72561d@mail.gmail.com>
Message-ID: <740F4556-945A-4519-8A2D-EFCB1FFEE950@railsnewbie.com>


I'm running 0.4.2, which is the latest version.  Here is what plugins/ 
tags of the new webgen gem looks like:

-rw-r--r--   1 root  admin   2230 Mar 21 07:29 block.rb
-rw-r--r--   1 root  admin   2600 Mar 21 07:29 breadcrumbtrail.rb
-rw-r--r--   1 root  admin   1706 Mar 21 07:29 customvar.rb
-rw-r--r--   1 root  admin   1489 Mar 21 07:29 date.rb
-rw-r--r--   1 root  admin   4983 Mar 21 07:29 download.rb
-rw-r--r--   1 root  admin   2686 Mar 21 07:29 executecommand.rb
-rw-r--r--   1 root  admin   2611 Mar 21 07:29 includefile.rb
-rw-r--r--   1 root  admin   2058 Mar 21 07:29 langbar.rb
-rw-r--r--   1 root  admin   3455 Mar 21 07:29 menu.rb
-rw-r--r--   1 root  admin   1750 Mar 21 07:29 meta.rb
-rw-r--r--   1 root  admin   3283 Mar 21 07:29 relocatable.rb
-rw-r--r--   1 root  admin   2728 Mar 21 07:29 sitemap.rb
-rw-r--r--   1 root  admin  10247 Mar 21 07:29 tag_processor.rb
-rw-r--r--   1 root  admin   2184 Mar 21 07:29 wikilink.rb

Scott


> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> What version(s) of webgen are you running?  I'm having the following
>> problem with webgen when  running rake pre_commit:
>>
>
> 0.3.8
>
>> sudo gem install webgen
>>
>> ERROR while running webgen: /opt/local/lib/ruby/site_ruby/1.8/
>> rubygems/custom_require.rb:27:in `gem_original_require': no such file
>> to load -- webgen/plugins/tags/tags (LoadError)
>>          from /opt/local/lib/ruby/site_ruby/1.8/rubygems/
>> custom_require.rb:27:in `require'
>>          from /Users/smtlaissezfaire/ruby/projects/rspec/trunk/doc/
>> plugin/version.rb:1:in `load_plugin'
>>          from /opt/local/lib/ruby/gems/1.8/gems/webgen-0.4.2/lib/
>> webgen/plugin.rb:224:in `load_from_file'
>> ...
>>
>> Scott
>>
>> _______________________________________________
>> 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  Wed Mar 21 08:33:23 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 07:33:23 -0500
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
Message-ID: <57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>

On 3/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On the 0.9-dev branch the context-specify pair has been largely
> replaced by describe-it, thanks to a brilliant suggestion by Dan
> North.
>
> I've been writing err TESTS ;-) in this format for a while now, and I
> really dig it. It pushes me even further to think about behaviour,
> because it *reads* much better than before:
>
> describe "Coffee for Aslak" do # Creates a new Spec::DSL::Behaviour
>   it "should never have sugar" do # Creates a new Spec::DSL::Example
>     ...
>   end
> end
>
> So far so good. My question to the list is:
>
> Assuming describe-it is the recommended way forward, how should we
> name our files?
> I'm leaning towards coffee_behaviour.rb.

Great idea. I think we should support this, but in addition to *_spec,
at least for the foreseeable future.

>
> Is this the end of specs and speccing/spec'ing and the start of
> behaviours and examplifications?

I like "example" over "specification" because "specification" has
always carried some baggage with it. Example is a word that Brian
Marick (http://www.exampler.com/) has been using for years, and I
think it resonates with what we're trying to do here.

I'm mostly there re: "behaviour" as the outer block, but there are
some things about it that don't quite roll off the tongue correctly.
For example, we don't setup a behaviour. In fact, we set up a context
for a behaviour. It does work really well, however, when you think
"describe Behaviour, it (should) Example".

Other thoughts?


>
> (We'll support context-specify for a while still)
>
> WDYT?
>
> Aslak
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From chad at spicycode.com  Wed Mar 21 09:14:39 2007
From: chad at spicycode.com (Chad Humphries)
Date: Wed, 21 Mar 2007 09:14:39 -0400
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
Message-ID: <16f722280703210614g194072fbt34c2045e9237929f@mail.gmail.com>

Going forward (sorry if I missed this in another thread) will context
and specify still be supported as well?

-Chad

On 3/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 3/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On the 0.9-dev branch the context-specify pair has been largely
> > replaced by describe-it, thanks to a brilliant suggestion by Dan
> > North.
> >
> > I've been writing err TESTS ;-) in this format for a while now, and I
> > really dig it. It pushes me even further to think about behaviour,
> > because it *reads* much better than before:
> >
> > describe "Coffee for Aslak" do # Creates a new Spec::DSL::Behaviour
> >   it "should never have sugar" do # Creates a new Spec::DSL::Example
> >     ...
> >   end
> > end
> >
> > So far so good. My question to the list is:
> >
> > Assuming describe-it is the recommended way forward, how should we
> > name our files?
> > I'm leaning towards coffee_behaviour.rb.
>
> Great idea. I think we should support this, but in addition to *_spec,
> at least for the foreseeable future.
>
> >
> > Is this the end of specs and speccing/spec'ing and the start of
> > behaviours and examplifications?
>
> I like "example" over "specification" because "specification" has
> always carried some baggage with it. Example is a word that Brian
> Marick (http://www.exampler.com/) has been using for years, and I
> think it resonates with what we're trying to do here.
>
> I'm mostly there re: "behaviour" as the outer block, but there are
> some things about it that don't quite roll off the tongue correctly.
> For example, we don't setup a behaviour. In fact, we set up a context
> for a behaviour. It does work really well, however, when you think
> "describe Behaviour, it (should) Example".
>
> Other thoughts?
>
>
> >
> > (We'll support context-specify for a while still)
> >
> > WDYT?
> >
> > Aslak
> > _______________________________________________
> > 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  Wed Mar 21 09:21:03 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 08:21:03 -0500
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <16f722280703210614g194072fbt34c2045e9237929f@mail.gmail.com>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
	<16f722280703210614g194072fbt34c2045e9237929f@mail.gmail.com>
Message-ID: <57c63afe0703210621o3293141p9449aa2a914bc6e5@mail.gmail.com>

On 3/21/07, Chad Humphries <chad at spicycode.com> wrote:
> Going forward (sorry if I missed this in another thread) will context
> and specify still be supported as well?

We'll keep them around as aliases. Even if we ever get rid of them,
you could always simply alias them in spec_helper.rb, so if we ever do
get there it won't be painful.

>
> -Chad
>
> On 3/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 3/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On the 0.9-dev branch the context-specify pair has been largely
> > > replaced by describe-it, thanks to a brilliant suggestion by Dan
> > > North.
> > >
> > > I've been writing err TESTS ;-) in this format for a while now, and I
> > > really dig it. It pushes me even further to think about behaviour,
> > > because it *reads* much better than before:
> > >
> > > describe "Coffee for Aslak" do # Creates a new Spec::DSL::Behaviour
> > >   it "should never have sugar" do # Creates a new Spec::DSL::Example
> > >     ...
> > >   end
> > > end
> > >
> > > So far so good. My question to the list is:
> > >
> > > Assuming describe-it is the recommended way forward, how should we
> > > name our files?
> > > I'm leaning towards coffee_behaviour.rb.
> >
> > Great idea. I think we should support this, but in addition to *_spec,
> > at least for the foreseeable future.
> >
> > >
> > > Is this the end of specs and speccing/spec'ing and the start of
> > > behaviours and examplifications?
> >
> > I like "example" over "specification" because "specification" has
> > always carried some baggage with it. Example is a word that Brian
> > Marick (http://www.exampler.com/) has been using for years, and I
> > think it resonates with what we're trying to do here.
> >
> > I'm mostly there re: "behaviour" as the outer block, but there are
> > some things about it that don't quite roll off the tongue correctly.
> > For example, we don't setup a behaviour. In fact, we set up a context
> > for a behaviour. It does work really well, however, when you think
> > "describe Behaviour, it (should) Example".
> >
> > Other thoughts?
> >
> >
> > >
> > > (We'll support context-specify for a while still)
> > >
> > > WDYT?
> > >
> > > Aslak
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Wed Mar 21 09:24:49 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 08:24:49 -0500
Subject: [rspec-devel] branches/0.9-dev
Message-ID: <57c63afe0703210624u3271296dmcb5bebc0aba98a61@mail.gmail.com>

We've started up a new branch for 0.9 development:

svn://rubyforge.org/var/svn/rspec/branches/0.9-dev
http://subtlety.errtheblog.com/O_o/1e.xml

This branch is quite volatile and somewhat experimental right now, but
if you're interested in seeing the changes we are exploring for 0.9,
this is the place to look. We've already removed sugar and separated
document structure (Spec::DSL with Behaviour and Example replacing
Context and Specification) from the runner (Spec::Runner), among other
things.

I would really not recommend trunksters switching over to this branch.
Things are changing quite rapidly. But please feel free to observe and
comment.

Once we've releases the translator and the bigger changes targeted for
in 0.9 have been fleshed out a bit, we'll move 0.8 maintenance to a
branch and 0.9 to the trunk. I'll announce when this is happening.

Cheers,
David

From aslak.hellesoy at gmail.com  Wed Mar 21 09:44:59 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 21 Mar 2007 14:44:59 +0100
Subject: [rspec-devel] RSpec on Google Summer of Code
Message-ID: <8d961d900703210644h287c210bgdd97699502d833df@mail.gmail.com>

Google Summer of Code (GSoC) is starting soon, and there are two
suggestions for RSpec-related projects:

http://www.rubycentral.org/projects/soc2007/ideas

Although not on this list (yet) I'd love to see someone taking the
challenge to implement RSpec support in RDT/RadRails/Eclipse, NetBeans
or IntelliJ IDEA (or all of them!).

Other RSpec related projects are of course welcome too.

Applications are due March 26th (http://code.google.com/soc), so if
you want to be part of it you better get ready!

RSpec(t),
Aslak

From aslak.hellesoy at gmail.com  Wed Mar 21 09:45:45 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 21 Mar 2007 14:45:45 +0100
Subject: [rspec-devel] webgen
In-Reply-To: <740F4556-945A-4519-8A2D-EFCB1FFEE950@railsnewbie.com>
References: <97786FC3-1E49-4859-9B0D-3FA80A0B2682@railsnewbie.com>
	<8d961d900703210450s2059e6f1ra2e01e3bee72561d@mail.gmail.com>
	<740F4556-945A-4519-8A2D-EFCB1FFEE950@railsnewbie.com>
Message-ID: <8d961d900703210645k3327fb74vb89d35560865e8db@mail.gmail.com>

On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> I'm running 0.4.2, which is the latest version.  Here is what plugins/
> tags of the new webgen gem looks like:
>

You need 0.3.8, unless you patch RSpec's doc system to work with newer versions.

> -rw-r--r--   1 root  admin   2230 Mar 21 07:29 block.rb
> -rw-r--r--   1 root  admin   2600 Mar 21 07:29 breadcrumbtrail.rb
> -rw-r--r--   1 root  admin   1706 Mar 21 07:29 customvar.rb
> -rw-r--r--   1 root  admin   1489 Mar 21 07:29 date.rb
> -rw-r--r--   1 root  admin   4983 Mar 21 07:29 download.rb
> -rw-r--r--   1 root  admin   2686 Mar 21 07:29 executecommand.rb
> -rw-r--r--   1 root  admin   2611 Mar 21 07:29 includefile.rb
> -rw-r--r--   1 root  admin   2058 Mar 21 07:29 langbar.rb
> -rw-r--r--   1 root  admin   3455 Mar 21 07:29 menu.rb
> -rw-r--r--   1 root  admin   1750 Mar 21 07:29 meta.rb
> -rw-r--r--   1 root  admin   3283 Mar 21 07:29 relocatable.rb
> -rw-r--r--   1 root  admin   2728 Mar 21 07:29 sitemap.rb
> -rw-r--r--   1 root  admin  10247 Mar 21 07:29 tag_processor.rb
> -rw-r--r--   1 root  admin   2184 Mar 21 07:29 wikilink.rb
>
> Scott
>
>
> > On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >>
> >> What version(s) of webgen are you running?  I'm having the following
> >> problem with webgen when  running rake pre_commit:
> >>
> >
> > 0.3.8
> >
> >> sudo gem install webgen
> >>
> >> ERROR while running webgen: /opt/local/lib/ruby/site_ruby/1.8/
> >> rubygems/custom_require.rb:27:in `gem_original_require': no such file
> >> to load -- webgen/plugins/tags/tags (LoadError)
> >>          from /opt/local/lib/ruby/site_ruby/1.8/rubygems/
> >> custom_require.rb:27:in `require'
> >>          from /Users/smtlaissezfaire/ruby/projects/rspec/trunk/doc/
> >> plugin/version.rb:1:in `load_plugin'
> >>          from /opt/local/lib/ruby/gems/1.8/gems/webgen-0.4.2/lib/
> >> webgen/plugin.rb:224:in `load_from_file'
> >> ...
> >>
> >> Scott
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From mailing_lists at railsnewbie.com  Wed Mar 21 10:11:23 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 10:11:23 -0400
Subject: [rspec-devel] webgen
In-Reply-To: <8d961d900703210645k3327fb74vb89d35560865e8db@mail.gmail.com>
References: <97786FC3-1E49-4859-9B0D-3FA80A0B2682@railsnewbie.com>
	<8d961d900703210450s2059e6f1ra2e01e3bee72561d@mail.gmail.com>
	<740F4556-945A-4519-8A2D-EFCB1FFEE950@railsnewbie.com>
	<8d961d900703210645k3327fb74vb89d35560865e8db@mail.gmail.com>
Message-ID: <F1D8E063-3D35-4364-8988-8957D2F73BAA@railsnewbie.com>


If I patch it to work with the newest version, do I need to make it  
backwards compatible?

Scott


On Mar 21, 2007, at 9:45 AM, aslak hellesoy wrote:

> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> I'm running 0.4.2, which is the latest version.  Here is what  
>> plugins/
>> tags of the new webgen gem looks like:
>>
>
> You need 0.3.8, unless you patch RSpec's doc system to work with  
> newer versions.
>
>> -rw-r--r--   1 root  admin   2230 Mar 21 07:29 block.rb
>> -rw-r--r--   1 root  admin   2600 Mar 21 07:29 breadcrumbtrail.rb
>> -rw-r--r--   1 root  admin   1706 Mar 21 07:29 customvar.rb
>> -rw-r--r--   1 root  admin   1489 Mar 21 07:29 date.rb
>> -rw-r--r--   1 root  admin   4983 Mar 21 07:29 download.rb
>> -rw-r--r--   1 root  admin   2686 Mar 21 07:29 executecommand.rb
>> -rw-r--r--   1 root  admin   2611 Mar 21 07:29 includefile.rb
>> -rw-r--r--   1 root  admin   2058 Mar 21 07:29 langbar.rb
>> -rw-r--r--   1 root  admin   3455 Mar 21 07:29 menu.rb
>> -rw-r--r--   1 root  admin   1750 Mar 21 07:29 meta.rb
>> -rw-r--r--   1 root  admin   3283 Mar 21 07:29 relocatable.rb
>> -rw-r--r--   1 root  admin   2728 Mar 21 07:29 sitemap.rb
>> -rw-r--r--   1 root  admin  10247 Mar 21 07:29 tag_processor.rb
>> -rw-r--r--   1 root  admin   2184 Mar 21 07:29 wikilink.rb
>>
>> Scott
>>
>>
>>> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>>
>>>> What version(s) of webgen are you running?  I'm having the  
>>>> following
>>>> problem with webgen when  running rake pre_commit:
>>>>
>>>
>>> 0.3.8
>>>
>>>> sudo gem install webgen
>>>>
>>>> ERROR while running webgen: /opt/local/lib/ruby/site_ruby/1.8/
>>>> rubygems/custom_require.rb:27:in `gem_original_require': no such  
>>>> file
>>>> to load -- webgen/plugins/tags/tags (LoadError)
>>>>          from /opt/local/lib/ruby/site_ruby/1.8/rubygems/
>>>> custom_require.rb:27:in `require'
>>>>          from /Users/smtlaissezfaire/ruby/projects/rspec/trunk/doc/
>>>> plugin/version.rb:1:in `load_plugin'
>>>>          from /opt/local/lib/ruby/gems/1.8/gems/webgen-0.4.2/lib/
>>>> webgen/plugin.rb:224:in `load_from_file'
>>>> ...
>>>>
>>>> Scott
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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 mailing_lists at railsnewbie.com  Wed Mar 21 10:23:59 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 10:23:59 -0400
Subject: [rspec-devel] RSpec on Google Summer of Code
In-Reply-To: <8d961d900703210644h287c210bgdd97699502d833df@mail.gmail.com>
References: <8d961d900703210644h287c210bgdd97699502d833df@mail.gmail.com>
Message-ID: <217BED10-0E48-4556-AF59-3A41CCFEB471@railsnewbie.com>


What does this one mean?

"Build an RSpec suite that validates the Ruby core (for use by  
multiple implementations)"

Validation of the C code?  Does it already have Test::Unit support?

Scott


On Mar 21, 2007, at 9:44 AM, aslak hellesoy wrote:

> Google Summer of Code (GSoC) is starting soon, and there are two
> suggestions for RSpec-related projects:
>
> http://www.rubycentral.org/projects/soc2007/ideas
>
> Although not on this list (yet) I'd love to see someone taking the
> challenge to implement RSpec support in RDT/RadRails/Eclipse, NetBeans
> or IntelliJ IDEA (or all of them!).
>
> Other RSpec related projects are of course welcome too.
>
> Applications are due March 26th (http://code.google.com/soc), so if
> you want to be part of it you better get ready!
>
> RSpec(t),
> Aslak
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Wed Mar 21 10:24:34 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 09:24:34 -0500
Subject: [rspec-devel] webgen
In-Reply-To: <F1D8E063-3D35-4364-8988-8957D2F73BAA@railsnewbie.com>
References: <97786FC3-1E49-4859-9B0D-3FA80A0B2682@railsnewbie.com>
	<8d961d900703210450s2059e6f1ra2e01e3bee72561d@mail.gmail.com>
	<740F4556-945A-4519-8A2D-EFCB1FFEE950@railsnewbie.com>
	<8d961d900703210645k3327fb74vb89d35560865e8db@mail.gmail.com>
	<F1D8E063-3D35-4364-8988-8957D2F73BAA@railsnewbie.com>
Message-ID: <57c63afe0703210724w2be10bebs2eda5381e685de38@mail.gmail.com>

On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> If I patch it to work with the newest version, do I need to make it
> backwards compatible?

I don't think that's necessary. We're talking about something that is
only meaningful to people who build the entire rspec suite, and
upgrading to webgen 0.4 is a one command operation.

David

>
> Scott
>
>
> On Mar 21, 2007, at 9:45 AM, aslak hellesoy wrote:
>
> > On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >>
> >> I'm running 0.4.2, which is the latest version.  Here is what
> >> plugins/
> >> tags of the new webgen gem looks like:
> >>
> >
> > You need 0.3.8, unless you patch RSpec's doc system to work with
> > newer versions.
> >
> >> -rw-r--r--   1 root  admin   2230 Mar 21 07:29 block.rb
> >> -rw-r--r--   1 root  admin   2600 Mar 21 07:29 breadcrumbtrail.rb
> >> -rw-r--r--   1 root  admin   1706 Mar 21 07:29 customvar.rb
> >> -rw-r--r--   1 root  admin   1489 Mar 21 07:29 date.rb
> >> -rw-r--r--   1 root  admin   4983 Mar 21 07:29 download.rb
> >> -rw-r--r--   1 root  admin   2686 Mar 21 07:29 executecommand.rb
> >> -rw-r--r--   1 root  admin   2611 Mar 21 07:29 includefile.rb
> >> -rw-r--r--   1 root  admin   2058 Mar 21 07:29 langbar.rb
> >> -rw-r--r--   1 root  admin   3455 Mar 21 07:29 menu.rb
> >> -rw-r--r--   1 root  admin   1750 Mar 21 07:29 meta.rb
> >> -rw-r--r--   1 root  admin   3283 Mar 21 07:29 relocatable.rb
> >> -rw-r--r--   1 root  admin   2728 Mar 21 07:29 sitemap.rb
> >> -rw-r--r--   1 root  admin  10247 Mar 21 07:29 tag_processor.rb
> >> -rw-r--r--   1 root  admin   2184 Mar 21 07:29 wikilink.rb
> >>
> >> Scott
> >>
> >>
> >>> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >>>>
> >>>> What version(s) of webgen are you running?  I'm having the
> >>>> following
> >>>> problem with webgen when  running rake pre_commit:
> >>>>
> >>>
> >>> 0.3.8
> >>>
> >>>> sudo gem install webgen
> >>>>
> >>>> ERROR while running webgen: /opt/local/lib/ruby/site_ruby/1.8/
> >>>> rubygems/custom_require.rb:27:in `gem_original_require': no such
> >>>> file
> >>>> to load -- webgen/plugins/tags/tags (LoadError)
> >>>>          from /opt/local/lib/ruby/site_ruby/1.8/rubygems/
> >>>> custom_require.rb:27:in `require'
> >>>>          from /Users/smtlaissezfaire/ruby/projects/rspec/trunk/doc/
> >>>> plugin/version.rb:1:in `load_plugin'
> >>>>          from /opt/local/lib/ruby/gems/1.8/gems/webgen-0.4.2/lib/
> >>>> webgen/plugin.rb:224:in `load_from_file'
> >>>> ...
> >>>>
> >>>> Scott
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Mar 21 10:25:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Mar 2007 10:25:30 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9423 ] --diff is broken for Strings
Message-ID: <20070321142530.6B01B5240A77@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: David Chelimsky (dchelimsky)
Summary: --diff is broken for Strings

Initial Comment:
To reproduce:
ruby bin/spec failing_examples/diffing_spec.rb --diff  

Only the second example produces a diff, but both should.

I think this is a quite recent regression, and it seems to have to do with the arguments passed to Spec::Expectations#fail_with (spec/expectations.rb). For some odd reason it only diffs when the message is an Array of length 3, which doesn't happen when two different strings are compared. I got lost trying to figure out why.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-21 14:25

Message:
Fixed in branches/0.9-dev (rev 1636)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-21 11:52

Message:
FYI - this is in the 0.9-dev branch.

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

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

From noreply at rubyforge.org  Wed Mar 21 10:26:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Mar 2007 10:26:46 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-6707 ] cannot run controller / helper
	tests via rails_spec or spec only works with rake
Message-ID: <20070321142647.06D5352409F9@rubyforge.org>

Bugs item #6707, was opened at 2006-11-16 14:55
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=6707&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Nobody (None)
Assigned to: David Chelimsky (dchelimsky)
Summary: cannot run controller / helper tests via rails_spec or spec only works with rake

Initial Comment:
I've tried four methods for running rails specs and here are the results for 0.7.2 (plugin and gem) on windows

ruby spec/controllers/admin/some_controller_spec.rb - WORKS but not sure if supposed to do things this way?

spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for <Spec::Runner::ContextEvalModule:0x3630680> (NoMethodError)

Start rails_spec_server then
ruby script\rails_spec spec/controllers/admin/some_controller_spec.rb - ERROR undefined method `controller_name' for <Spec::Runner::ContextEvalModule:0x3630680> (NoMethodError) (SAME AS BEFORE)

rake spec - WORKS FINE

---
the sample test
---
require File.dirname(__FILE__) + '/../../spec_helper'

context "The Admin::TalentPoolsController" do
  # fixtures :talent_pools
  controller_name "admin/talent_pools"

  specify "should be a Admin::TalentPoolsController" do
    controller.should_be_an_instance_of Admin::TalentPoolsController
  end


  specify "should have more specifications" do
    violated "not enough specs"
  end
end
---
It seems that the module that contains the class method for controller_name does not get loaded except with rake / ruby?

we really need the test suite not to reload each time (current rake takes 25 minutes or longer!)
---
the same error happens with helpers and the call to helper_name


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

Comment By: Stephan Kaag (synchrosteve)
Date: 2007-03-20 13:38

Message:
David: rake tasks didn't produce an error
the command from the root map did the trick..

tnq..


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

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

Message:
Stephan - do the rake tasks work for you?

Also, you CD'd into spec/controllers. How about standing in the project root and saying:

spec spec/controllers/item_controller_spec.rb

Does that produce a similar error?

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

Comment By: Stephan Kaag (synchrosteve)
Date: 2007-03-20 11:23

Message:
I still run into the same error..

Im using
Rails 1.1.6
with:
RSpec 0.8.2 (r1560)
on:
a mac

to regenerate:
$ ./script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_8_2/rspec_on_rails/vendor/plugins/rspec_on_rails
$ ./script/generate rspec
$ ./script/generate rspec_controller 'item'
$ cd spec/controllers/
$spec item_controller_spec.rb

result:
/usr/local/lib/ruby/gems/1.8/gems/rspec-0.8.2/lib/spec/expectations/sugar.rb:14:in `call': undefined method `controller_name' for #<Spec::Runner::ContextEvalModule:0x270e83c> (NoMethodError)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2006-11-17 04:15

Message:
Fixed in trunk (rev 1120).

The problem was a path Regexp that failed to account for windows slashes.

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

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

From dchelimsky at gmail.com  Wed Mar 21 10:28:45 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 09:28:45 -0500
Subject: [rspec-devel] RSpec on Google Summer of Code
In-Reply-To: <217BED10-0E48-4556-AF59-3A41CCFEB471@railsnewbie.com>
References: <8d961d900703210644h287c210bgdd97699502d833df@mail.gmail.com>
	<217BED10-0E48-4556-AF59-3A41CCFEB471@railsnewbie.com>
Message-ID: <57c63afe0703210728u527cc060x2b20efb341a6b4f3@mail.gmail.com>

On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> What does this one mean?
>
> "Build an RSpec suite that validates the Ruby core (for use by
> multiple implementations)"
>
> Validation of the C code?  Does it already have Test::Unit support?

There are other implementations emerging like jruby and rubinius. The
goal would be to have a single specification that all ruby
implementations should pass. Interesting problem, I think.

>
> Scott
>
>
> On Mar 21, 2007, at 9:44 AM, aslak hellesoy wrote:
>
> > Google Summer of Code (GSoC) is starting soon, and there are two
> > suggestions for RSpec-related projects:
> >
> > http://www.rubycentral.org/projects/soc2007/ideas
> >
> > Although not on this list (yet) I'd love to see someone taking the
> > challenge to implement RSpec support in RDT/RadRails/Eclipse, NetBeans
> > or IntelliJ IDEA (or all of them!).
> >
> > Other RSpec related projects are of course welcome too.
> >
> > Applications are due March 26th (http://code.google.com/soc), so if
> > you want to be part of it you better get ready!
> >
> > RSpec(t),
> > Aslak
> > _______________________________________________
> > 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 noreply at rubyforge.org  Wed Mar 21 10:34:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Mar 2007 10:34:53 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9423 ] --diff is broken for Strings
Message-ID: <20070321143453.6622952409A0@rubyforge.org>

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

Category: runner module
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: David Chelimsky (dchelimsky)
Summary: --diff is broken for Strings

Initial Comment:
To reproduce:
ruby bin/spec failing_examples/diffing_spec.rb --diff  

Only the second example produces a diff, but both should.

I think this is a quite recent regression, and it seems to have to do with the arguments passed to Spec::Expectations#fail_with (spec/expectations.rb). For some odd reason it only diffs when the message is an Array of length 3, which doesn't happen when two different strings are compared. I got lost trying to figure out why.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-21 14:34

Message:
FYI - Spec::Expectations#fail_with only diffs when it gets an Array because it needs to know what to diff. It becomes the burden of the matcher calling #fail_with to send it the right stuff to diff.

Any suggestions to improve that design?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-21 14:25

Message:
Fixed in branches/0.9-dev (rev 1636)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-21 11:52

Message:
FYI - this is in the 0.9-dev branch.

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

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

From noreply at rubyforge.org  Wed Mar 21 10:44:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Mar 2007 10:44:25 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9265 ] [Documentation] These are NOT
	deprecated. See Spec::Matchers should not be red
Message-ID: <20070321144425.4FA7C524097E@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: [Documentation] These are NOT deprecated. See Spec::Matchers should not be red

Initial Comment:
It is confusing to see "These are NOT deprecated. See Spec::Matchers" in red text because it looks like it is being deprecated.

Perhaps it should be green?

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-21 14:44

Message:
I tried changing it to green, but then it gets lost. In a page full of red messages, I want people to see this one so they don't think that the non-deprecated messages are deprecated - and the NOT brings it out for me.

Any other suggestions? I'm all for doing something that will make this as clear as possible.

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

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

From noreply at rubyforge.org  Wed Mar 21 11:02:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 21 Mar 2007 11:02:51 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-6550 ] Mix in several
	modules and do it in one place only
Message-ID: <20070321150251.9C9C2524097E@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Nobody (None)
Summary: Mix in several modules and do it in one place only

Initial Comment:
We need a way to mixin several modules and do it in one place only. Like in the spec_helper.rb file used by spec/rails



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

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

Message:
Actually, how about a rails-style initializer/configurator:

Spec.configure do |config|
  config.mock_with :my_favorite_mock_framework
  config.include MyHelperMethods
  config.include MyCustomMatchers

  #for rails
  config.use_transactional_fixtures = true
end

This keeps the interface simple, exposes less structure, and let's rspec delegate these configuration options to different parts of the system as necessary.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-15 19:05

Message:
We have a need to add this soon. Here's what I'm thinking:

#in spec_helper.rb

module Spec
  module Config
    mock_with :my_favorite_mock_framework
    include MyHelperMethods
    include MyCustomMatchers
  end
end

Everything defined or declared here would impact all specs. We'd make it work the same for Spec::Rails.

Sound reasonable?

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

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

From dan at tastapod.com  Wed Mar 21 11:22:35 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 21 Mar 2007 15:22:35 +0000
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
Message-ID: <46014DBB.8060107@tastapod.com>

David Chelimsky wrote:
> On 3/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>   
>> On the 0.9-dev branch the context-specify pair has been largely
>> replaced by describe-it, thanks to a brilliant suggestion by Dan
>> North.
>>
>>     
I have to claim the Shoulders of Giants amendment. You guys have put 
together a really nice framework so it meant I got to play with some 
words without having to think about the technology.
>> Assuming describe-it is the recommended way forward, how should we
>> name our files?
>> I'm leaning towards coffee_behaviour.rb.
>>     
I'm calling mine coffee_behaviour.rb. Also the directory they live in is 
called behaviour and the "daddy" file is called all_behaviours.rb, and 
just contains:

    require 'find'
    Find.find('behaviour') { |f| require f if f ~= /_behaviour.rb$/ }

Another symmetry I noticed that made me smile is this. In my behaviour 
files, I /describe/ the class's behaviour. In the source file, I 
/def/ine its implementation. So Ruby was giving me the clues all along.
> I like "example" over "specification" because "specification" has
> always carried some baggage with it. Example is a word that Brian
> Marick (http://www.exampler.com/) has been using for years, and I
> think it resonates with what we're trying to do here.
>   
I agree. It's a more natural vocabulary to talk about describing an 
object's /behaviour/ by way of /examples/. Initially I was very 
reluctant about the word "should" in the context of 
some_object.*should*_have_some_value, but I've come round to its 
readability, especially now I can create domain-specific matchers.
> I'm mostly there re: "behaviour" as the outer block, but there are
> some things about it that don't quite roll off the tongue correctly.
> For example, we don't setup a behaviour. In fact, we set up a context
> for a behaviour. It does work really well, however, when you think
> "describe Behaviour, it (should) Example".
>
> Other thoughts?
>   
It still feels like there is something missing "in the middle". I'm 
thinking:

describe PatternMatcher do                        # <-- description

  it "should match variable-length strings" do    # <-- responsibility?

    always do                                     # <-- common context
      @matcher = PatternMatcher.new('/a*/')
    end

    example "single character string" do          # <-- examples
      @matcher.matches?('a').should be_true
    end

    example "empty string" do
      @matcher.matches?('').should be_true
    end

    example "several chars" do
      @matcher.matches?('aaaa').should be_true
    end
  end
end

This is just a rough idea at the moment, but always would work like 
set_up, run before each example, and each example would run in its own 
instance of an object, so there wouldn't  be any carry-over of state 
between examples.

Mostly, I find the responsibility and the example are the same thing (or 
rather, the responsibility can be described with a single example), so 
they both collapse into the it block, but it might be useful to be able 
to describe a single responsibility with multiple examples.

Then you could choose to describe the classes either at a responsibility 
level or at a finer-grained example level:

PatternMatcher
- should match variable-length strings
- should do other stuff

or

PatternMatcher
- should match variable-length strings
   - e.g. single character string
   - e.g. zero length string
   - e.g. several chars
- should do other stuff
   - e.g. another example

Like I said, I'm just playing with the words at the moment, but 
something like this feels very natural to me.

What do you guys think?
>> (We'll support context-specify for a while still)
>>     
I think this is very important. We should support whatever people are 
using to not-think-about-tests. That seems to be the first step to 
genuinely thinking about behaviour :)
>> WDYT?
>>
>> Aslak
>>     
Cheers,
Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070321/377c3bb9/attachment.html 

From dchelimsky at gmail.com  Wed Mar 21 12:17:07 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 11:17:07 -0500
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <46014DBB.8060107@tastapod.com>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
	<46014DBB.8060107@tastapod.com>
Message-ID: <57c63afe0703210917y3dc54539qf5c9d72286fa4f6b@mail.gmail.com>

On 3/21/07, Dan North <dan at tastapod.com> wrote:
>  It still feels like there is something missing "in the middle". I'm
> thinking:
>
>  describe PatternMatcher do                        # <-- description
>
>    it "should match variable-length strings" do    # <-- responsibility?
>
>      always do                                     # <--
> common context
>        @matcher = PatternMatcher.new('/a*/')
>      end
>
>      example "single character string" do          # <-- examples
>        @matcher.matches?('a').should be_true
>      end
>
>      example "empty string" do
>        @matcher.matches?('').should be_true
>      end
>
>      example "several chars" do
>        @matcher.matches?('aaaa').should be_true
>      end
>    end
>  end
>
>  This is just a rough idea at the moment, but always would work like set_up,
> run before each example, and each example would run in its own instance of
> an object, so there wouldn't  be any carry-over of state between examples.
>
>  Mostly, I find the responsibility and the example are the same thing (or
> rather, the responsibility can be described with a single example), so they
> both collapse into the it block, but it might be useful to be able to
> describe a single responsibility with multiple examples.
>
>  Then you could choose to describe the classes either at a responsibility
> level or at a finer-grained example level:
>
>  PatternMatcher
>  - should match variable-length strings
>  - should do other stuff
>
>  or
>
>  PatternMatcher
>  - should match variable-length strings
>     - e.g. single character string
>     - e.g. zero length string
>     - e.g. several chars
>  - should do other stuff
>     - e.g. another example
>
>  Like I said, I'm just playing with the words at the moment, but something
> like this feels very natural to me.
>
>  What do you guys think?

There are a couple of open RFE's that talk about nesting things in
some way or another. This is similar to the one about Aspects, and
we've been struggling for the words. This takes a step towards solving
that, but it also puts a burden on the example-author to nest three
structures deep. There's no sane way (that I've seen) to arbitrarily
nest the same type - for example:

Behaviour
  Example
    Example

That leads to all sorts of conflicts w/ state sharing, etc. This could work:

Behaviour
  ExampleGroup
    Example

But it would require that developers ALWAYS use all three structures.
Personally, I'm OK w/ that.

Other opinions?


>
>
>  (We'll support context-specify for a while still)
>
>  I think this is very important. We should support whatever people are using
> to not-think-about-tests. That seems to be the first step to genuinely
> thinking about behaviour :)

Agreed!

David

>
>
>  WDYT?
>
> Aslak
>
>  Cheers,
>  Dan
>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dan at tastapod.com  Wed Mar 21 12:27:19 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 21 Mar 2007 16:27:19 +0000
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <57c63afe0703210917y3dc54539qf5c9d72286fa4f6b@mail.gmail.com>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>	<46014DBB.8060107@tastapod.com>
	<57c63afe0703210917y3dc54539qf5c9d72286fa4f6b@mail.gmail.com>
Message-ID: <46015CE7.7090804@tastapod.com>

David Chelimsky wrote:
>
> There's no sane way (that I've seen) to arbitrarily
> nest the same type - for example:
>
> Behaviour
>   Example
>     Example
>   
I'm talking about having behaviour in /either/ the it ... block (most 
common case) or the example ... block (if you want to split things 
further). So:

describe SimpleThing do
    it 'does simple stuff' do
        # simple stuff
    end

    it 'does other simple stuff' do
       # other simple stuff
    end
end

describe ComplicatedThing do
    it 'does complicated stuff' do
       always do
          # setup for complicated stuff
       end

       example 'one complicated thing' do
          # ...
       end

       example 'another complicated thing' do
          # ...
       end
    end
end

The behaviour runner and documenter would Just Work (TM) because they 
would traverse responsibilities (the "it"s) with zero or more examples. 
Or something like that.
> That leads to all sorts of conflicts w/ state sharing, etc.
Yeah, it would need some thinking about, but it seems the most natural 
way to write it.
>  This could work:
>
> Behaviour
>   ExampleGroup
>     Example
>
> But it would require that developers ALWAYS use all three structures.
> Personally, I'm OK w/ that.
>   
I'd prefer that if users didn't care about the distinction between 
responsibilities and examples, then they shouldn't need to know ("it 
just /does/ stuff"). Like I said, it's just an idea at the moment. 
There's definitely scope for a semantic that means "bunch of examples" 
though.

Cheers,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070321/33271f00/attachment-0001.html 

From mailing_lists at railsnewbie.com  Wed Mar 21 12:28:22 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 21 Mar 2007 12:28:22 -0400
Subject: [rspec-devel] RSpec on Google Summer of Code
In-Reply-To: <57c63afe0703210728u527cc060x2b20efb341a6b4f3@mail.gmail.com>
References: <8d961d900703210644h287c210bgdd97699502d833df@mail.gmail.com>
	<217BED10-0E48-4556-AF59-3A41CCFEB471@railsnewbie.com>
	<57c63afe0703210728u527cc060x2b20efb341a6b4f3@mail.gmail.com>
Message-ID: <A62EA6B6-F375-487B-AFD0-5BE145DBFD3B@railsnewbie.com>


Yes, it does sound very cool.  I guess my question was "How does it  
differ from the following:

Enhance RSpec to run on one platform but test another (e.g., run on  
Ruby 1.8.6, but test rubinius)"

Is anyone signing up for any rspec-related projects for the summer of  
code?  Can students work in teams?

Scott


On Mar 21, 2007, at 10:28 AM, David Chelimsky wrote:

> On 3/21/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> What does this one mean?
>>
>> "Build an RSpec suite that validates the Ruby core (for use by
>> multiple implementations)"
>>
>> Validation of the C code?  Does it already have Test::Unit support?
>
> There are other implementations emerging like jruby and rubinius. The
> goal would be to have a single specification that all ruby
> implementations should pass. Interesting problem, I think.
>
>>
>> Scott
>>
>>
>> On Mar 21, 2007, at 9:44 AM, aslak hellesoy wrote:
>>
>>> Google Summer of Code (GSoC) is starting soon, and there are two
>>> suggestions for RSpec-related projects:
>>>
>>> http://www.rubycentral.org/projects/soc2007/ideas
>>>
>>> Although not on this list (yet) I'd love to see someone taking the
>>> challenge to implement RSpec support in RDT/RadRails/Eclipse,  
>>> NetBeans
>>> or IntelliJ IDEA (or all of them!).
>>>
>>> Other RSpec related projects are of course welcome too.
>>>
>>> Applications are due March 26th (http://code.google.com/soc), so if
>>> you want to be part of it you better get ready!
>>>
>>> RSpec(t),
>>> Aslak
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From bob.cotton at rallydev.com  Wed Mar 21 12:59:24 2007
From: bob.cotton at rallydev.com (Bob Cotton)
Date: Wed, 21 Mar 2007 10:59:24 -0600
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <46014DBB.8060107@tastapod.com> (Dan North's message of "Wed, 21
	Mar 2007 15:22:35 +0000")
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
	<46014DBB.8060107@tastapod.com>
Message-ID: <m1mz26edn7.fsf@boblaptop.local>

Dan North <dan at tastapod.com> writes:
> describe PatternMatcher do

So what are the parameters to #describe? Can it still be a String?

- bob

From dchelimsky at gmail.com  Wed Mar 21 13:26:23 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 12:26:23 -0500
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <46015CE7.7090804@tastapod.com>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
	<46014DBB.8060107@tastapod.com>
	<57c63afe0703210917y3dc54539qf5c9d72286fa4f6b@mail.gmail.com>
	<46015CE7.7090804@tastapod.com>
Message-ID: <57c63afe0703211026v5b7ef2d8h89d16bf4d96a6470@mail.gmail.com>

On 3/21/07, Dan North <dan at tastapod.com> wrote:
>  I'm talking about having behaviour in either the it ... block (most common
> case) or the example ... block (if you want to split things further). So:
>
>  describe SimpleThing do
>      it 'does simple stuff' do
>          # simple stuff
>      end
>
>      it 'does other simple stuff' do
>         # other simple stuff
>      end
>  end
>
>  describe ComplicatedThing do
>      it 'does complicated stuff' do
>         always do
>            # setup for complicated stuff
>         end
>
>         example 'one complicated thing' do
>            # ...
>         end
>
>         example 'another complicated thing' do
>            # ...
>         end
>      end
>  end

I'm not a big fan of having #it work in two different ways depending
on the structure. I think that will make things more difficult to
understand.

Dan and I were just bouncing around ideas off-line and one idea that
came up was this:

describe SimpleThing do
  it 'does simple stuff' do
    # simple stuff
  end

  it 'does other simple stuff' do
    # other simple stuff
  end
end

describe ComplicatedThing do
  responsibility 'does complicated stuff' do
    always do
      # setup for complicated stuff
    end

    example 'one complicated thing' do
      # ...
    end

    example 'another complicated thing' do
      # ...
    end
  end
end

This aligns really well w/ the Aspect idea that Yurii proposed, keeps
rspec's internals simple, provides the desired mechanism and doesn't
change the meaning of #it.

I'm not in love w/ #always because everybody understands what #setup
means and it doesn't really speak to me anyhow - always what? Just an
opinion.

Thoughts?

From dchelimsky at gmail.com  Wed Mar 21 13:27:32 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 12:27:32 -0500
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <m1mz26edn7.fsf@boblaptop.local>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
	<46014DBB.8060107@tastapod.com> <m1mz26edn7.fsf@boblaptop.local>
Message-ID: <57c63afe0703211027s394c3712jd70fbe3869bb91da@mail.gmail.com>

On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote:
> Dan North <dan at tastapod.com> writes:
> > describe PatternMatcher do
>
> So what are the parameters to #describe? Can it still be a String?

Yes. Right now it takes two args and calls to_s on the first, so the
first arg can be anything that responds to to_s (which, I believe, is
everything).

>
> - bob
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Wed Mar 21 13:28:21 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 12:28:21 -0500
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <57c63afe0703211027s394c3712jd70fbe3869bb91da@mail.gmail.com>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>
	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>
	<46014DBB.8060107@tastapod.com> <m1mz26edn7.fsf@boblaptop.local>
	<57c63afe0703211027s394c3712jd70fbe3869bb91da@mail.gmail.com>
Message-ID: <57c63afe0703211028y25503a37m454bf38a0736c521@mail.gmail.com>

On 3/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 3/21/07, Bob Cotton <bob.cotton at rallydev.com> wrote:
> > Dan North <dan at tastapod.com> writes:
> > > describe PatternMatcher do
> >
> > So what are the parameters to #describe? Can it still be a String?
>
> Yes. Right now it takes two args and calls to_s on the first, so the
> first arg can be anything that responds to to_s (which, I believe, is
> everything).

Also - the second arg is optional. So this is completely backwards compatible.

>
> >
> > - bob
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>

From dan at tastapod.com  Wed Mar 21 13:30:13 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 21 Mar 2007 17:30:13 +0000
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <m1mz26edn7.fsf@boblaptop.local>
References: <8d961d900703210119y13069eb3sefd9e29fbd4e9013@mail.gmail.com>	<57c63afe0703210533v7e577ad1gf1a948779d35edb1@mail.gmail.com>	<46014DBB.8060107@tastapod.com>
	<m1mz26edn7.fsf@boblaptop.local>
Message-ID: <46016BA5.9060804@tastapod.com>

I wouldn't want to restrict anything anyone is currently doing. Anything 
that you can to_s is fair game.

I tend to use class or module names because a) I'm describing the 
behaviour of an object, and b) the first thing that fails when I run it 
is that the module or class doesn't exist.


Bob Cotton wrote:
> Dan North <dan at tastapod.com> writes:
>   
>> describe PatternMatcher do
>>     
>
> So what are the parameters to #describe? Can it still be a String?
>
> - bob
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070321/cabd4e90/attachment.html 

From undees at gmail.com  Wed Mar 21 14:49:16 2007
From: undees at gmail.com (Ian Dees)
Date: Wed, 21 Mar 2007 11:49:16 -0700
Subject: [rspec-devel] describe-it: what do we call our files?
Message-ID: <ad4f9af90703211149n47b00421o53d0df26526f9810@mail.gmail.com>

One problem with using "behaviour" as part of the expected file name
or the spec language is the transatlantic spelling issue: we crazy
Americans leave out the "u".  So whichever way it appears in specs, it
will look a little "off" to a bunch of people.

It's not a problem to have it in internal class names, which most
RSpec users will never see.  But interaction with test writers is
another story.  It would be nice not to have to pause whenever I type
the word "behavio(u)r" and think, "Am I in the middle of composing an
RSpec test, or am I writing an e-mail message to a colleague?" before
I know which way to spell it.

Maybe RSpec could accept both variants?

Reminds me of a project which had both "color" and "colour" scattered
all over the source code in function/variable names....  ;-)

BTW, what happened to given/when/then?  Are we abandoning that?  Was
it the keyword issue with "when"?

--Ian

From dchelimsky at gmail.com  Wed Mar 21 15:20:15 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 21 Mar 2007 14:20:15 -0500
Subject: [rspec-devel] describe-it: what do we call our files?
In-Reply-To: <ad4f9af90703211149n47b00421o53d0df26526f9810@mail.gmail.com>
References: <ad4f9af90703211149n47b00421o53d0df26526f9810@mail.gmail.com>
Message-ID: <57c63afe0703211220h4cbfc76ch31f15a5767f464b1@mail.gmail.com>

On 3/21/07, Ian Dees <undees at gmail.com> wrote:
> One problem with using "behaviour" as part of the expected file name
> or the spec language is the transatlantic spelling issue: we crazy
> Americans leave out the "u".  So whichever way it appears in specs, it
> will look a little "off" to a bunch of people.
>
> It's not a problem to have it in internal class names, which most
> RSpec users will never see.  But interaction with test writers is
> another story.  It would be nice not to have to pause whenever I type
> the word "behavio(u)r" and think, "Am I in the middle of composing an
> RSpec test, or am I writing an e-mail message to a colleague?" before
> I know which way to spell it.
>
> Maybe RSpec could accept both variants?

Very likely. If it's a public facing word, we'd probably support both.

>
> Reminds me of a project which had both "color" and "colour" scattered
> all over the source code in function/variable names....  ;-)

Actually, rspec's current command line options support both --color
and --colour.

>
> BTW, what happened to given/when/then?  Are we abandoning that?  Was
> it the keyword issue with "when"?

That's going to be baked into rbehave, so we're waiting for that to
emerge. The vision, which I believe will play out, is that these two
tools will play nice together w/ rbehave targeted at higher level
examples (i.e. user stories, and acceptance criteria) and rspec
targeted at lower levels (i.e. modules, classes and methods).

Dan's perspective, and I'm inclined to agree philosophically, is that
GWT gets a little too verbose for most of the things we want to
describe at the class/method level.

Make sense?

David



>
> --Ian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Thu Mar 22 04:49:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 22 Mar 2007 04:49:25 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9458 ] The rspec_resource generator
	does not take into account class nesting
Message-ID: <20070322084925.EA7D852408D9@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Steve Tendon (progfrog)
Assigned to: Nobody (None)
Summary: The rspec_resource generator does not take into account class nesting

Initial Comment:
The rspec_resource generator will not generate the correct require paths if you generate with a module. 

For example:

?./script/generate rspec_resource 'railfrog/content'

will put:

  require File.dirname(__FILE__) + '/../spec_helper'

in the generated controller, while it should generate:

  require File.dirname(__FILE__) + '<%= '/..' * class_nesting_depth %>/../spec_helper'

Similar problems in the generated views.

This patch corrects the genertor templates accordingly.

====

This contribution comes from the Pond http://railfrog.com/

Croak! Croak!

--progfrog

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

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

From noreply at rubyforge.org  Thu Mar 22 12:12:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 22 Mar 2007 12:12:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070322161236.6FEFC5240953@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

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

From noreply at rubyforge.org  Thu Mar 22 12:23:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 22 Mar 2007 12:23:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070322162320.D39135240953@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-22 16:23

Message:
I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time.

We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this:

describe "AllEditions", :shared => true do
 it "should do something" do
 end
end

describe LargeEdition do
  it_should_behave_as "AllEditions"

  it "should also do something else" do
  end
end

That reads kinda nice, ay?


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

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

From noreply at rubyforge.org  Thu Mar 22 14:45:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 22 Mar 2007 14:45:08 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070322184508.6EF68A970001@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

>Comment By: Bob Cotton (bcotton)
Date: 2007-03-22 12:45

Message:

Very nice.

it_should_behave_as

Brainstorming with a co-worker:
behaving_as
behaves_like
sharing
acts_like
an_example_of
shares_behavior_with
shares_behavior_of
same_as
same_behavior_as
just_like
equivalent_to
it_doppelgangers

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-22 10:23

Message:
I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time.

We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this:

describe "AllEditions", :shared => true do
 it "should do something" do
 end
end

describe LargeEdition do
  it_should_behave_as "AllEditions"

  it "should also do something else" do
  end
end

That reads kinda nice, ay?


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

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

From mailing_lists at railsnewbie.com  Fri Mar 23 12:08:02 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 12:08:02 -0400
Subject: [rspec-devel] Building rspec_on_rails: errors_on
Message-ID: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>


I'm trying to build rspec_on_rails.  All of the specs in  
rails_expectations_spec.rb are failing.

Here's the first spec:

class Animal < ActiveRecord::Base
   validates_presence_of :age, :name
   validates_numericality_of :age
end

context "receiver.should have(n).errors_on(:attribute)" do
   setup do
     @animal = Animal.new
   end

   specify "should fail if the expected error count is more than the  
actual count" do
     lambda {
       @animal.should have(7).errors_on(:age)
     }.should_fail_with "expected 7 errors on :age, got 2"
   end


Rails doesn't seem to have errors_on(col_name).  But @animal.errors.on 
(:name) => ["name cannot be blank"], and @animals.errors.on 
(:name).size => 1

Should I re-spec these so that @animals.errors.on(:name).size.should  
== 7 ?

Scott


From dchelimsky at gmail.com  Fri Mar 23 12:13:24 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 23 Mar 2007 11:13:24 -0500
Subject: [rspec-devel] structural changes in 0.9-dev branch
Message-ID: <57c63afe0703230913y42725a9an1dc7e67b0f31cec@mail.gmail.com>

For those of you following 0.9 development, I just moved the rails
plugin up to the project root directory, parallel with rspec core. So,
if you're feeling risky, to install the latest in your rails app:

ruby script/plugin install
svn://rubyforge.org/var/svn/rspec/branches/0.9-dev/rspec
ruby script/plugin install
svn://rubyforge.org/var/svn/rspec/branches/0.9-dev/rspec_on_rails
ruby script/generate rspec

Then run specs using the rake tasks or the spec command in the scripts dir:

rake spec
script/spec spec

This is NOT recommended yet. The branch is under heavy development
with lots of structural changes, etc. Once things stabilize we'll move
this over to trunk.

Cheers,
David

From mailing_lists at railsnewbie.com  Fri Mar 23 12:22:23 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 12:22:23 -0400
Subject: [rspec-devel] Building rspec_on_rails: errors_on
In-Reply-To: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
References: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
Message-ID: <84A86B87-C71E-498A-AAFD-4786EC2932C5@railsnewbie.com>


Well, you can forget about my last comment.  I hadn't realized that  
you had added errors_on to rails...

Any thoughts on why the specs might not be passing?

Scott


On Mar 23, 2007, at 12:08 PM, Scott Taylor wrote:

>
> I'm trying to build rspec_on_rails.  All of the specs in
> rails_expectations_spec.rb are failing.
>
> Here's the first spec:
>
> class Animal < ActiveRecord::Base
>    validates_presence_of :age, :name
>    validates_numericality_of :age
> end
>
> context "receiver.should have(n).errors_on(:attribute)" do
>    setup do
>      @animal = Animal.new
>    end
>
>    specify "should fail if the expected error count is more than the
> actual count" do
>      lambda {
>        @animal.should have(7).errors_on(:age)
>      }.should_fail_with "expected 7 errors on :age, got 2"
>    end
>
>
> Rails doesn't seem to have errors_on(col_name).  But @animal.errors.on
> (:name) => ["name cannot be blank"], and @animals.errors.on
> (:name).size => 1
>
> Should I re-spec these so that @animals.errors.on(:name).size.should
> == 7 ?
>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Fri Mar 23 12:30:50 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 23 Mar 2007 11:30:50 -0500
Subject: [rspec-devel] Building rspec_on_rails: errors_on
In-Reply-To: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
References: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
Message-ID: <57c63afe0703230930v2b33d5d9te2d7a062f2402ec6@mail.gmail.com>

On 3/23/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> I'm trying to build rspec_on_rails.  All of the specs in
> rails_expectations_spec.rb are failing.
>
> Here's the first spec:
>
> class Animal < ActiveRecord::Base
>    validates_presence_of :age, :name
>    validates_numericality_of :age
> end
>
> context "receiver.should have(n).errors_on(:attribute)" do
>    setup do
>      @animal = Animal.new
>    end
>
>    specify "should fail if the expected error count is more than the
> actual count" do
>      lambda {
>        @animal.should have(7).errors_on(:age)
>      }.should_fail_with "expected 7 errors on :age, got 2"
>    end
>
>
> Rails doesn't seem to have errors_on(col_name).  But @animal.errors.on
> (:name) => ["name cannot be blank"], and @animals.errors.on
> (:name).size => 1
>
> Should I re-spec these so that @animals.errors.on(:name).size.should
> == 7 ?

Nope. #errors_on gets added to AR (look in
vendor/plugins/rspec_on_rails/lib/spec/rails/extensions).

What versions of everything (rails, rspec, rspec_on_rails) are you
working with, and what commands are you using to try to build it?


>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From mailing_lists at railsnewbie.com  Fri Mar 23 12:41:02 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 12:41:02 -0400
Subject: [rspec-devel] Building rspec_on_rails: errors_on
In-Reply-To: <57c63afe0703230930v2b33d5d9te2d7a062f2402ec6@mail.gmail.com>
References: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
	<57c63afe0703230930v2b33d5d9te2d7a062f2402ec6@mail.gmail.com>
Message-ID: <C1F37455-AE66-4F17-BE5C-F74E15F9A0EC@railsnewbie.com>


Well, it says its running against: running against rails 1.2.2

I have ruby 1.8.6
rspec_on_rails: trunk, 1649

I'm using "rake -f Multirails.rake pre_commit" from within in the  
rspec_on_rails directory in trunk.

Scott


On Mar 23, 2007, at 12:30 PM, David Chelimsky wrote:

> On 3/23/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> I'm trying to build rspec_on_rails.  All of the specs in
>> rails_expectations_spec.rb are failing.
>>
>> Here's the first spec:
>>
>> class Animal < ActiveRecord::Base
>>    validates_presence_of :age, :name
>>    validates_numericality_of :age
>> end
>>
>> context "receiver.should have(n).errors_on(:attribute)" do
>>    setup do
>>      @animal = Animal.new
>>    end
>>
>>    specify "should fail if the expected error count is more than the
>> actual count" do
>>      lambda {
>>        @animal.should have(7).errors_on(:age)
>>      }.should_fail_with "expected 7 errors on :age, got 2"
>>    end
>>
>>
>> Rails doesn't seem to have errors_on(col_name).  But  
>> @animal.errors.on
>> (:name) => ["name cannot be blank"], and @animals.errors.on
>> (:name).size => 1
>>
>> Should I re-spec these so that @animals.errors.on(:name).size.should
>> == 7 ?
>
> Nope. #errors_on gets added to AR (look in
> vendor/plugins/rspec_on_rails/lib/spec/rails/extensions).
>
> What versions of everything (rails, rspec, rspec_on_rails) are you
> working with, and what commands are you using to try to build it?
>
>
>>
>> Scott
>>
>> _______________________________________________
>> 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 mailing_lists at railsnewbie.com  Fri Mar 23 13:57:33 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 13:57:33 -0400
Subject: [rspec-devel] Building rspec_on_rails: errors_on
In-Reply-To: <57c63afe0703230930v2b33d5d9te2d7a062f2402ec6@mail.gmail.com>
References: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
	<57c63afe0703230930v2b33d5d9te2d7a062f2402ec6@mail.gmail.com>
Message-ID: <9547B779-69A5-44D4-A0F6-5A58F6526D29@railsnewbie.com>


I can tell you that the error on the object is never getting set.   
Observe:


class Animal < ActiveRecord::Base
   validates_presence_of :age
   validates_presence_of :name
   validates_numericality_of :age
end

context "receiver.should have(n).errors_on(:attribute)" do
   setup do
     @animal = Animal.new
   end

   specify "should work!" do
     @animal.valid?
     @animal.errors.on(:name).should_not == nil
   end

   ...
end



1)
'receiver.should have(n).errors_on(:attribute) should work!' FAILED
expected not == nil, got nil
./vendor/plugins/rspec_on_rails/spec/rails/expectations/ 
should_have_errors_spec.rb:18:


I have no idea why this is happening!

Scott




On Mar 23, 2007, at 12:30 PM, David Chelimsky wrote:

> On 3/23/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> I'm trying to build rspec_on_rails.  All of the specs in
>> rails_expectations_spec.rb are failing.
>>
>> Here's the first spec:
>>
>> class Animal < ActiveRecord::Base
>>    validates_presence_of :age, :name
>>    validates_numericality_of :age
>> end
>>
>> context "receiver.should have(n).errors_on(:attribute)" do
>>    setup do
>>      @animal = Animal.new
>>    end
>>
>>    specify "should fail if the expected error count is more than the
>> actual count" do
>>      lambda {
>>        @animal.should have(7).errors_on(:age)
>>      }.should_fail_with "expected 7 errors on :age, got 2"
>>    end
>>
>>
>> Rails doesn't seem to have errors_on(col_name).  But  
>> @animal.errors.on
>> (:name) => ["name cannot be blank"], and @animals.errors.on
>> (:name).size => 1
>>
>> Should I re-spec these so that @animals.errors.on(:name).size.should
>> == 7 ?
>
> Nope. #errors_on gets added to AR (look in
> vendor/plugins/rspec_on_rails/lib/spec/rails/extensions).
>
> What versions of everything (rails, rspec, rspec_on_rails) are you
> working with, and what commands are you using to try to build it?
>
>
>>
>> Scott
>>
>> _______________________________________________
>> 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 mailing_lists at railsnewbie.com  Fri Mar 23 14:16:50 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 14:16:50 -0400
Subject: [rspec-devel] Building rspec_on_rails: errors_on
In-Reply-To: <9547B779-69A5-44D4-A0F6-5A58F6526D29@railsnewbie.com>
References: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
	<57c63afe0703230930v2b33d5d9te2d7a062f2402ec6@mail.gmail.com>
	<9547B779-69A5-44D4-A0F6-5A58F6526D29@railsnewbie.com>
Message-ID: <5570BCAF-C06C-4E58-8C2E-D9F8499B51F2@railsnewbie.com>


A Yaml dump of the object gives this:

....................--- &id001 !ruby/object:ActiveRecord::Errors
base: !ruby/object:Animal
   attributes:
     name: "'NULL'"
     age: 0.0
     person_id: 0
   errors: *id001
   new_record: true
errors: {}

I think this is occuring because of the schema of the database:

class CreateAnimals < ActiveRecord::Migration
   def self.up
     create_table :animals do |t|
       t.column :name,      :string, :default => nil
       t.column :person_id, :integer
     end
   end

   def self.down
     drop_table :animals
   end
end


class Animals < ActiveRecord::Migration
   def self.up
     add_column :animals, :age, :float
   end

   def self.down
     remove_column :animals, :age
   end
end

The errors start with Rails version 1.2.1 (Rails 1.2.1 seem fine).   
I'm using sqlite as a database.  So maybe this is a bug in how Rails  
Migrations work with sqlite?

I'll check this out after my class is over at 3.30.

Scott





On Mar 23, 2007, at 1:57 PM, Scott Taylor wrote:

>
> I can tell you that the error on the object is never getting set.
> Observe:
>
>
> class Animal < ActiveRecord::Base
>    validates_presence_of :age
>    validates_presence_of :name
>    validates_numericality_of :age
> end
>
> context "receiver.should have(n).errors_on(:attribute)" do
>    setup do
>      @animal = Animal.new
>    end
>
>    specify "should work!" do
>      @animal.valid?
>      @animal.errors.on(:name).should_not == nil
>    end
>
>    ...
> end
>
>
>
> 1)
> 'receiver.should have(n).errors_on(:attribute) should work!' FAILED
> expected not == nil, got nil
> ./vendor/plugins/rspec_on_rails/spec/rails/expectations/
> should_have_errors_spec.rb:18:
>
>
> I have no idea why this is happening!
>
> Scott
>
>
>
>
> On Mar 23, 2007, at 12:30 PM, David Chelimsky wrote:
>
>> On 3/23/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>
>>> I'm trying to build rspec_on_rails.  All of the specs in
>>> rails_expectations_spec.rb are failing.
>>>
>>> Here's the first spec:
>>>
>>> class Animal < ActiveRecord::Base
>>>    validates_presence_of :age, :name
>>>    validates_numericality_of :age
>>> end
>>>
>>> context "receiver.should have(n).errors_on(:attribute)" do
>>>    setup do
>>>      @animal = Animal.new
>>>    end
>>>
>>>    specify "should fail if the expected error count is more than the
>>> actual count" do
>>>      lambda {
>>>        @animal.should have(7).errors_on(:age)
>>>      }.should_fail_with "expected 7 errors on :age, got 2"
>>>    end
>>>
>>>
>>> Rails doesn't seem to have errors_on(col_name).  But
>>> @animal.errors.on
>>> (:name) => ["name cannot be blank"], and @animals.errors.on
>>> (:name).size => 1
>>>
>>> Should I re-spec these so that @animals.errors.on(:name).size.should
>>> == 7 ?
>>
>> Nope. #errors_on gets added to AR (look in
>> vendor/plugins/rspec_on_rails/lib/spec/rails/extensions).
>>
>> What versions of everything (rails, rspec, rspec_on_rails) are you
>> working with, and what commands are you using to try to build it?
>>
>>
>>>
>>> Scott
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From mailing_lists at railsnewbie.com  Fri Mar 23 19:19:04 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 19:19:04 -0400
Subject: [rspec-devel] Building rspec_on_rails: errors_on
In-Reply-To: <5570BCAF-C06C-4E58-8C2E-D9F8499B51F2@railsnewbie.com>
References: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
	<57c63afe0703230930v2b33d5d9te2d7a062f2402ec6@mail.gmail.com>
	<9547B779-69A5-44D4-A0F6-5A58F6526D29@railsnewbie.com>
	<5570BCAF-C06C-4E58-8C2E-D9F8499B51F2@railsnewbie.com>
Message-ID: <23E4E182-064E-4AF1-B082-921DEF16D4AD@railsnewbie.com>


I wonder if the bug has anything to do with this:

http://weblog.rubyonrails.org/2007/2/6/rails-1-2-2-sqlite3-gems- 
singular-resources

?

Best,

Scott


From mailing_lists at railsnewbie.com  Fri Mar 23 19:19:49 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 19:19:49 -0400
Subject: [rspec-devel] Building Errors with Rspec
Message-ID: <469C6E52-FC77-49F1-848B-D1747271CD5A@railsnewbie.com>

I think there are some things in the Docs which need changing -  
namely better support for developers of rspec.

Not only is webgen needed, but version 0.3.8
webgen requires rmagick, which requires imagemagick (and  
graphicsmagick?  I needed both for it to work on my system of Mac OS  
X.4.8), as well as rb-rmagick (through darwin ports) and the syntax gem

I don't know if you guys are all running on Linux, and just have  
imagemagicks/graphicsmagick installed by default?

rake install_dependencies must also be run
and the appropriate rspec config/database.xxx.yml must be moved (or  
copied) to config/database.yml

Anyway, when I finally get rspec built, I'll probably submit some  
sort of patch to the docs with this info...

Scott


From mailing_lists at railsnewbie.com  Fri Mar 23 20:35:50 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 20:35:50 -0400
Subject: [rspec-devel] Building rspec_on_rails: errors_on
In-Reply-To: <23E4E182-064E-4AF1-B082-921DEF16D4AD@railsnewbie.com>
References: <714CAA51-1AA4-42FB-8468-60421A7CCD2A@railsnewbie.com>
	<57c63afe0703230930v2b33d5d9te2d7a062f2402ec6@mail.gmail.com>
	<9547B779-69A5-44D4-A0F6-5A58F6526D29@railsnewbie.com>
	<5570BCAF-C06C-4E58-8C2E-D9F8499B51F2@railsnewbie.com>
	<23E4E182-064E-4AF1-B082-921DEF16D4AD@railsnewbie.com>
Message-ID: <3D0B5545-9729-43F0-9CF3-A26CC2DB25B1@railsnewbie.com>


Yep - It was the sqlite bug.  The specs ran just fine under mysql.

Am I being annoying?  I'll stop emailing the group if no one cares.

Scott



On Mar 23, 2007, at 7:19 PM, Scott Taylor wrote:

>
> I wonder if the bug has anything to do with this:
>
> http://weblog.rubyonrails.org/2007/2/6/rails-1-2-2-sqlite3-gems-
> singular-resources
>
> ?
>
> Best,
>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From mailing_lists at railsnewbie.com  Fri Mar 23 21:07:07 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 23 Mar 2007 21:07:07 -0400
Subject: [rspec-devel] Patch info...
Message-ID: <2F9CE579-B223-497F-84AB-5410C09C4642@railsnewbie.com>


I've run rake pre_commit - where do I submit my patch?

Thanks for all of the help, and sorry for my many emails,

Scott


From dchelimsky at gmail.com  Sat Mar 24 00:40:17 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 24 Mar 2007 04:40:17 +0000
Subject: [rspec-devel] Patch info...
In-Reply-To: <2F9CE579-B223-497F-84AB-5410C09C4642@railsnewbie.com>
References: <2F9CE579-B223-497F-84AB-5410C09C4642@railsnewbie.com>
Message-ID: <57c63afe0703232140k14b2092fj3bc10aa9efd81d30@mail.gmail.com>

On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> I've run rake pre_commit - where do I submit my patch?

http://rspec.rubyforge.org/contribute.html
http://rubyforge.org/tracker/?atid=3151&group_id=797&func=browse

Looking forward to it.

>
> Thanks for all of the help, and sorry for my many emails,
>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Sat Mar 24 00:54:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 00:54:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324045409.91DC45240D41@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

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

From noreply at rubyforge.org  Sat Mar 24 00:56:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 00:56:30 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324045630.6F7405240D41@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From noreply at rubyforge.org  Sat Mar 24 00:57:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 00:57:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324045736.756B05240D41@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From noreply at rubyforge.org  Sat Mar 24 00:58:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 00:58:59 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324045859.C4BA85240D41@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From noreply at rubyforge.org  Sat Mar 24 01:03:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 01:03:37 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9510 ] Added File for Ruby 1.8.6
Message-ID: <20070324050337.7CF8B5240D41@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Added File for Ruby 1.8.6

Initial Comment:
Not really a patch, just an added file for those developers who may be using ruby version 1.8.6

The file: rspec/spec/spec/runner/formatter/html_formatted-1.8.6.html

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

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

From noreply at rubyforge.org  Sat Mar 24 02:39:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 02:39:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9511 ] Clarification to README file
	in spec/
Message-ID: <20070324063921.AC9B55240D41@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Clarification to README file in spec/

Initial Comment:

While building rspec I had quite a go of it.  Mainly because the README left out a few things (nothing which the devoted developers on the mailing list couldn't solve, though).  Here is what was left out:


webgen should be at version 0.3.8, not at it's latest version, which (as of March 24, 2007) is 0.4.2.

webgen requires rmagick, which in turn requires either imagemagick or graphicsmagick.

I installed the last packages through darwinports.  I believe that the rb-magick port must also be installed.  In the end, I ended up installing:

port: imagemagick
port: graphicsmagick
port: rb-rmagick
gem: rmagick
gem: webgen -v 0.3.8

All of this needs to be clarified in the documentation somewhere.  The README seems like the natural place, since already most of the info on building rspec is there.  Maybe it would be wise to separate this into another file?



Here is the diff:

Index: README
===================================================================
--- README      (revision 1650)
+++ README      (working copy)
@@ -35,18 +35,25 @@
   gem install pkg/rspec-0.x.x.gem (you may have to sudo)
 
 == Running the specs ==
-In order to run RSpec's full suite of specs (rake pre_commit) you must install the following gems:
+In order to run RSpec's full suite of specs (rake pre_commit) you must have either GraphicsMagick or ImageMagick
+installed.  If you are running MacOS X, these packages can be obtained through DarwinPorts.  Make sure you also
+install the port rb-rmagick.
 
-* rake          # Runs the build script
-* rcov          # Verifies that the code is 100% covered by specs
-* webgen        # Generates the static HTML website
-* RedCloth      # Required by webgen
-* syntax        # Required by our own custom webgen extension to highlight ruby code
-* diff-lcs      # Required if you use the --diff switch
-* win32console  # Required by the --colour switch if you're on Windows
-* meta_project  # Required in order to make releases at RubyForge
-* heckle        # Required if you use the --heckle switch
+The following gems are also required:
 
+* rake              # Runs the build script
+* rcov              # Verifies that the code is 100% covered by specs
+* webgen (v 0.3.8)  # Generates the static HTML website 
+* RedCloth          # Required by webgen
+* rmagick           # Also required by webgen
+* syntax            # Required by our own custom webgen extension to highlight ruby code
+* diff-lcs          # Required if you use the --diff switch
+* win32console      # Required by the --colour switch if you're on Windows
+* meta_project      # Required in order to make releases at RubyForge
+* heckle            # Required if you use the --heckle switch
+
+Make sure you install webgen version 0.3.8; later versions will break the build.        
+
 Note that RSpec itself - once built - doesn't have any dependencies outside the Ruby core 
 and stdlib - with a few exceptions:


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

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

From noreply at rubyforge.org  Sat Mar 24 06:17:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 06:17:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324101740.3E8E15240A0A@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

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

Message:
Scott,

We need this in diff format. This is to avoid that your file overwrites someone else's recent changes.

Stand in the root and do
svn diff > allow_spaces_in_spec_opts.patch



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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 00:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From noreply at rubyforge.org  Sat Mar 24 06:24:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 06:24:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9511 ] Clarification to README file
	in spec/
Message-ID: <20070324102458.CA8005240A6E@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Clarification to README file in spec/

Initial Comment:

While building rspec I had quite a go of it.  Mainly because the README left out a few things (nothing which the devoted developers on the mailing list couldn't solve, though).  Here is what was left out:


webgen should be at version 0.3.8, not at it's latest version, which (as of March 24, 2007) is 0.4.2.

webgen requires rmagick, which in turn requires either imagemagick or graphicsmagick.

I installed the last packages through darwinports.  I believe that the rb-magick port must also be installed.  In the end, I ended up installing:

port: imagemagick
port: graphicsmagick
port: rb-rmagick
gem: rmagick
gem: webgen -v 0.3.8

All of this needs to be clarified in the documentation somewhere.  The README seems like the natural place, since already most of the info on building rspec is there.  Maybe it would be wise to separate this into another file?



Here is the diff:

Index: README
===================================================================
--- README      (revision 1650)
+++ README      (working copy)
@@ -35,18 +35,25 @@
   gem install pkg/rspec-0.x.x.gem (you may have to sudo)
 
 == Running the specs ==
-In order to run RSpec's full suite of specs (rake pre_commit) you must install the following gems:
+In order to run RSpec's full suite of specs (rake pre_commit) you must have either GraphicsMagick or ImageMagick
+installed.  If you are running MacOS X, these packages can be obtained through DarwinPorts.  Make sure you also
+install the port rb-rmagick.
 
-* rake          # Runs the build script
-* rcov          # Verifies that the code is 100% covered by specs
-* webgen        # Generates the static HTML website
-* RedCloth      # Required by webgen
-* syntax        # Required by our own custom webgen extension to highlight ruby code
-* diff-lcs      # Required if you use the --diff switch
-* win32console  # Required by the --colour switch if you're on Windows
-* meta_project  # Required in order to make releases at RubyForge
-* heckle        # Required if you use the --heckle switch
+The following gems are also required:
 
+* rake              # Runs the build script
+* rcov              # Verifies that the code is 100% covered by specs
+* webgen (v 0.3.8)  # Generates the static HTML website 
+* RedCloth          # Required by webgen
+* rmagick           # Also required by webgen
+* syntax            # Required by our own custom webgen extension to highlight ruby code
+* diff-lcs          # Required if you use the --diff switch
+* win32console      # Required by the --colour switch if you're on Windows
+* meta_project      # Required in order to make releases at RubyForge
+* heckle            # Required if you use the --heckle switch
+
+Make sure you install webgen version 0.3.8; later versions will break the build.        
+
 Note that RSpec itself - once built - doesn't have any dependencies outside the Ruby core 
 and stdlib - with a few exceptions:


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

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

Message:
I just uninstalled RMagick and rake webgen still runs fine (on my mac). You must be doing something wrong.

Why do you think it's needed?

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

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

From noreply at rubyforge.org  Sat Mar 24 06:26:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 06:26:07 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324102607.C2EF45240ABC@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 10:26

Message:
Sorry about that. 

This diff also contains the other two "patches" - the one is
simply the addition of the html file for ruby 1.8.6, the
other is the change in the readme file.  Both have been
opened as separate patch tickets, so you may want to close
them after you get this.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:17

Message:
Scott,

We need this in diff format. This is to avoid that your file overwrites someone else's recent changes.

Stand in the root and do
svn diff > allow_spaces_in_spec_opts.patch



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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From noreply at rubyforge.org  Sat Mar 24 08:28:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 08:28:25 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324122825.6F6A05240A9C@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 12:28

Message:
Hi Scott - sorry if this seems like a pain, but we really want patches to be more atomic - addressing only one issue each.

I'm going to open up a separate thread on the rspec-devel list about this.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 10:26

Message:
Sorry about that. 

This diff also contains the other two "patches" - the one is
simply the addition of the html file for ruby 1.8.6, the
other is the change in the readme file.  Both have been
opened as separate patch tickets, so you may want to close
them after you get this.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:17

Message:
Scott,

We need this in diff format. This is to avoid that your file overwrites someone else's recent changes.

Stand in the root and do
svn diff > allow_spaces_in_spec_opts.patch



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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From dchelimsky at gmail.com  Sat Mar 24 08:38:04 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 24 Mar 2007 07:38:04 -0500
Subject: [rspec-devel] submitting multiple patches
Message-ID: <57c63afe0703240538j168270dehe0df1093baf1e21b@mail.gmail.com>

Hi all,

How do you all deal with submitting multiple patches to OSS projects,
creating new patches before your previously submitted patches have
been applied?

My approach thus far has been to keep all of my patches for a given
project in a directory. I grab a fresh copy of trunk, develop the new
patch, making sure it works without the other patches. Once I'm happy
w/ the patch at hand, I back it out and then apply it after all of the
other patches to make sure that they all play nice together.

This all seems a bit tedious, and I'm hoping there is a better way.

What do you do?

Thanks,
David

From noreply at rubyforge.org  Sat Mar 24 14:39:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 14:39:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9522 ] support using rspec's
	expectations with test/unit
Message-ID: <20070324183941.DEE2352408D9@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: support using rspec's expectations with test/unit

Initial Comment:
We already have support to use test/unit assertions in rspec specs. Let's add support for rspec's expectations in test/unit tests.

Here's how it should work:

require 'rubygems'
require 'spec/test_case_adapter'

class ThreeTest < Test::Unit::TestCase
  def test_should_be_less_than_four
    3.should be < 4
  end
end

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

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

From noreply at rubyforge.org  Sat Mar 24 14:41:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 14:41:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9522 ] support using rspec's
	expectations with test/unit
Message-ID: <20070324184135.F3BAC52408D9@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
>Assigned to: David Chelimsky (dchelimsky)
Summary: support using rspec's expectations with test/unit

Initial Comment:
We already have support to use test/unit assertions in rspec specs. Let's add support for rspec's expectations in test/unit tests.

Here's how it should work:

require 'rubygems'
require 'spec/test_case_adapter'

class ThreeTest < Test::Unit::TestCase
  def test_should_be_less_than_four
    3.should be < 4
  end
end

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 18:41

Message:
Added 'spec/test_case_adapter' to 0.9-dev branch (rev 1651)

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

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

From noreply at rubyforge.org  Sat Mar 24 15:30:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 15:30:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324193048.5419A52408D9@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 19:30

Message:
Do you want me to submit the patches separately again, with
the diffs?  Or is the spec.opts patch (alone) not atomic
enough???

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 12:28

Message:
Hi Scott - sorry if this seems like a pain, but we really want patches to be more atomic - addressing only one issue each.

I'm going to open up a separate thread on the rspec-devel list about this.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 10:26

Message:
Sorry about that. 

This diff also contains the other two "patches" - the one is
simply the addition of the html file for ruby 1.8.6, the
other is the change in the readme file.  Both have been
opened as separate patch tickets, so you may want to close
them after you get this.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:17

Message:
Scott,

We need this in diff format. This is to avoid that your file overwrites someone else's recent changes.

Stand in the root and do
svn diff > allow_spaces_in_spec_opts.patch



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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From mailing_lists at railsnewbie.com  Sat Mar 24 15:43:57 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Sat, 24 Mar 2007 15:43:57 -0400
Subject: [rspec-devel] submitting multiple patches
In-Reply-To: <57c63afe0703240538j168270dehe0df1093baf1e21b@mail.gmail.com>
References: <57c63afe0703240538j168270dehe0df1093baf1e21b@mail.gmail.com>
Message-ID: <18D57FFC-DB96-4515-8572-3C1EB9DF893C@railsnewbie.com>


Well one way is to give open commit rights.  I think with a system  
like this people will be eager to give a good patch.  I also think  
that people will use discretion when commiting.

The patch that I submitted was a little tricky, because I obviously  
had to add a file just to get rake pre_commit to run on my original  
patch.  As for the third patch, I already started to do work on the  
README after I had submitted the patch.  This sort of thing would be  
solved with open commit rights, giving commit rights after the first  
patch is accepted into the code base.

The problem to open commit rights is that you don't want bad patches  
submitted.  I think with a system like this people will be hesitant  
to submit controversial patches.  I know that with my change to the  
readme I would have first consulted you whether or not this should go  
directly into the readme or into another file, if the verbage sounded  
good or if you'd suggest a change, etc.

Thanks,

Scott


On Mar 24, 2007, at 8:38 AM, David Chelimsky wrote:

> Hi all,
>
> How do you all deal with submitting multiple patches to OSS projects,
> creating new patches before your previously submitted patches have
> been applied?
>
> My approach thus far has been to keep all of my patches for a given
> project in a directory. I grab a fresh copy of trunk, develop the new
> patch, making sure it works without the other patches. Once I'm happy
> w/ the patch at hand, I back it out and then apply it after all of the
> other patches to make sure that they all play nice together.
>
> This all seems a bit tedious, and I'm hoping there is a better way.
>
> What do you do?
>
> Thanks,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Sat Mar 24 16:25:56 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 24 Mar 2007 15:25:56 -0500
Subject: [rspec-devel] submitting multiple patches
In-Reply-To: <18D57FFC-DB96-4515-8572-3C1EB9DF893C@railsnewbie.com>
References: <57c63afe0703240538j168270dehe0df1093baf1e21b@mail.gmail.com>
	<18D57FFC-DB96-4515-8572-3C1EB9DF893C@railsnewbie.com>
Message-ID: <57c63afe0703241325q28759fa5i9a12da8d4a7db697@mail.gmail.com>

On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> Well one way is to give open commit rights.  I think with a system
> like this people will be eager to give a good patch.  I also think
> that people will use discretion when commiting.
>
> The patch that I submitted was a little tricky, because I obviously
> had to add a file just to get rake pre_commit to run on my original
> patch.  As for the third patch, I already started to do work on the
> README after I had submitted the patch.  This sort of thing would be
> solved with open commit rights, giving commit rights after the first
> patch is accepted into the code base.
>
> The problem to open commit rights is that you don't want bad patches
> submitted.  I think with a system like this people will be hesitant
> to submit controversial patches.  I know that with my change to the
> readme I would have first consulted you whether or not this should go
> directly into the readme or into another file, if the verbage sounded
> good or if you'd suggest a change, etc.
>
> Thanks,
>
> Scott

Hi Scott,

This isn't really what I was asking. y question was not "how can OSS
projects make it easier for you to commit". It was "given OSS projects
that accept patches, how can I make it easier on myself to commit
multiple patches?".

As for opening up rspec to open commits, I can't see that working.
Patching is a pretty standard mechanism for accepting contributions,
and it also allows project managers to review those contributions and
absorb them as time and resources permit. This quality control is
essential, in my view.

David

>
> On Mar 24, 2007, at 8:38 AM, David Chelimsky wrote:
>
> > Hi all,
> >
> > How do you all deal with submitting multiple patches to OSS projects,
> > creating new patches before your previously submitted patches have
> > been applied?
> >
> > My approach thus far has been to keep all of my patches for a given
> > project in a directory. I grab a fresh copy of trunk, develop the new
> > patch, making sure it works without the other patches. Once I'm happy
> > w/ the patch at hand, I back it out and then apply it after all of the
> > other patches to make sure that they all play nice together.
> >
> > This all seems a bit tedious, and I'm hoping there is a better way.
> >
> > What do you do?
> >
> > Thanks,
> > David
> > _______________________________________________
> > 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 noreply at rubyforge.org  Sat Mar 24 16:39:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 16:39:08 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324203908.2E8DF52408D9@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 20:39

Message:
Applied in trunk(1652).

I went ahead and applied this, but for future, what we'd want is a single patch that has all of the changes (and only those changes) relevant to a given RFE.

Thanks for playing.

David

ps - leaving this open because it needs to be applied to 0.9-dev branch too.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 19:30

Message:
Do you want me to submit the patches separately again, with
the diffs?  Or is the spec.opts patch (alone) not atomic
enough???

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 12:28

Message:
Hi Scott - sorry if this seems like a pain, but we really want patches to be more atomic - addressing only one issue each.

I'm going to open up a separate thread on the rspec-devel list about this.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 10:26

Message:
Sorry about that. 

This diff also contains the other two "patches" - the one is
simply the addition of the html file for ruby 1.8.6, the
other is the change in the readme file.  Both have been
opened as separate patch tickets, so you may want to close
them after you get this.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:17

Message:
Scott,

We need this in diff format. This is to avoid that your file overwrites someone else's recent changes.

Stand in the root and do
svn diff > allow_spaces_in_spec_opts.patch



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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From mailing_lists at railsnewbie.com  Sat Mar 24 16:47:41 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Sat, 24 Mar 2007 16:47:41 -0400
Subject: [rspec-devel] submitting multiple patches
In-Reply-To: <57c63afe0703241325q28759fa5i9a12da8d4a7db697@mail.gmail.com>
References: <57c63afe0703240538j168270dehe0df1093baf1e21b@mail.gmail.com>
	<18D57FFC-DB96-4515-8572-3C1EB9DF893C@railsnewbie.com>
	<57c63afe0703241325q28759fa5i9a12da8d4a7db697@mail.gmail.com>
Message-ID: <5E4A71C2-CE24-45E9-8537-89BA4D8001E6@railsnewbie.com>


On Mar 24, 2007, at 4:25 PM, David Chelimsky wrote:

> On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> Well one way is to give open commit rights.  I think with a system
>> like this people will be eager to give a good patch.  I also think
>> that people will use discretion when commiting.
>>
>> The patch that I submitted was a little tricky, because I obviously
>> had to add a file just to get rake pre_commit to run on my original
>> patch.  As for the third patch, I already started to do work on the
>> README after I had submitted the patch.  This sort of thing would be
>> solved with open commit rights, giving commit rights after the first
>> patch is accepted into the code base.
>>
>> The problem to open commit rights is that you don't want bad patches
>> submitted.  I think with a system like this people will be hesitant
>> to submit controversial patches.  I know that with my change to the
>> readme I would have first consulted you whether or not this should go
>> directly into the readme or into another file, if the verbage sounded
>> good or if you'd suggest a change, etc.
>>
>> Thanks,
>>
>> Scott
>
> Hi Scott,
>
> This isn't really what I was asking. y question was not "how can OSS
> projects make it easier for you to commit". It was "given OSS projects
> that accept patches, how can I make it easier on myself to commit
> multiple patches?".
>
> As for opening up rspec to open commits, I can't see that working.
> Patching is a pretty standard mechanism for accepting contributions,
> and it also allows project managers to review those contributions and
> absorb them as time and resources permit. This quality control is
> essential, in my view.
>
> David


Yeah, I agree with you.  Nor do I think it is appropriate to have an  
open commit system for rspec.

Thanks for applying the patch, btw.  Its my first contribution to an  
Open Source project.  I'll try to follow your guidelines more closely  
next time.

Scott


>
>>
>> On Mar 24, 2007, at 8:38 AM, David Chelimsky wrote:
>>
>>> Hi all,
>>>
>>> How do you all deal with submitting multiple patches to OSS  
>>> projects,
>>> creating new patches before your previously submitted patches have
>>> been applied?
>>>
>>> My approach thus far has been to keep all of my patches for a given
>>> project in a directory. I grab a fresh copy of trunk, develop the  
>>> new
>>> patch, making sure it works without the other patches. Once I'm  
>>> happy
>>> w/ the patch at hand, I back it out and then apply it after all  
>>> of the
>>> other patches to make sure that they all play nice together.
>>>
>>> This all seems a bit tedious, and I'm hoping there is a better way.
>>>
>>> What do you do?
>>>
>>> Thanks,
>>> David
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Sat Mar 24 16:52:07 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 24 Mar 2007 15:52:07 -0500
Subject: [rspec-devel] submitting multiple patches
In-Reply-To: <5E4A71C2-CE24-45E9-8537-89BA4D8001E6@railsnewbie.com>
References: <57c63afe0703240538j168270dehe0df1093baf1e21b@mail.gmail.com>
	<18D57FFC-DB96-4515-8572-3C1EB9DF893C@railsnewbie.com>
	<57c63afe0703241325q28759fa5i9a12da8d4a7db697@mail.gmail.com>
	<5E4A71C2-CE24-45E9-8537-89BA4D8001E6@railsnewbie.com>
Message-ID: <57c63afe0703241352l4bcdc228s18fb8b4440f811df@mail.gmail.com>

On 3/24/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> Thanks for applying the patch, btw.  Its my first contribution to an
> Open Source project.

Congratulations! Keep 'em coming.

Cheers,
David

From noreply at rubyforge.org  Sat Mar 24 16:56:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 16:56:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324205626.663055240960@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: Nobody (None)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 20:56

Message:
Do you want me to submit the patches separately again, with
the diffs?  Or is the spec.opts patch (alone) not atomic
enough???

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 20:39

Message:
Applied in trunk(1652).

I went ahead and applied this, but for future, what we'd want is a single patch that has all of the changes (and only those changes) relevant to a given RFE.

Thanks for playing.

David

ps - leaving this open because it needs to be applied to 0.9-dev branch too.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 19:30

Message:
Do you want me to submit the patches separately again, with
the diffs?  Or is the spec.opts patch (alone) not atomic
enough???

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 12:28

Message:
Hi Scott - sorry if this seems like a pain, but we really want patches to be more atomic - addressing only one issue each.

I'm going to open up a separate thread on the rspec-devel list about this.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 10:26

Message:
Sorry about that. 

This diff also contains the other two "patches" - the one is
simply the addition of the html file for ruby 1.8.6, the
other is the change in the readme file.  Both have been
opened as separate patch tickets, so you may want to close
them after you get this.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:17

Message:
Scott,

We need this in diff format. This is to avoid that your file overwrites someone else's recent changes.

Stand in the root and do
svn diff > allow_spaces_in_spec_opts.patch



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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From noreply at rubyforge.org  Sat Mar 24 17:02:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 17:02:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9510 ] Added File for Ruby 1.8.6
Message-ID: <20070324210215.954E352408D9@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Added File for Ruby 1.8.6

Initial Comment:
Not really a patch, just an added file for those developers who may be using ruby version 1.8.6

The file: rspec/spec/spec/runner/formatter/html_formatted-1.8.6.html

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

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

Message:
applied to trunk and 0.9-dev (as of rev 1654)

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

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

From noreply at rubyforge.org  Sat Mar 24 17:03:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 17:03:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9511 ] Clarification to README file
	in spec/
Message-ID: <20070324210319.AAEEA5240960@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Clarification to README file in spec/

Initial Comment:

While building rspec I had quite a go of it.  Mainly because the README left out a few things (nothing which the devoted developers on the mailing list couldn't solve, though).  Here is what was left out:


webgen should be at version 0.3.8, not at it's latest version, which (as of March 24, 2007) is 0.4.2.

webgen requires rmagick, which in turn requires either imagemagick or graphicsmagick.

I installed the last packages through darwinports.  I believe that the rb-magick port must also be installed.  In the end, I ended up installing:

port: imagemagick
port: graphicsmagick
port: rb-rmagick
gem: rmagick
gem: webgen -v 0.3.8

All of this needs to be clarified in the documentation somewhere.  The README seems like the natural place, since already most of the info on building rspec is there.  Maybe it would be wise to separate this into another file?



Here is the diff:

Index: README
===================================================================
--- README      (revision 1650)
+++ README      (working copy)
@@ -35,18 +35,25 @@
   gem install pkg/rspec-0.x.x.gem (you may have to sudo)
 
 == Running the specs ==
-In order to run RSpec's full suite of specs (rake pre_commit) you must install the following gems:
+In order to run RSpec's full suite of specs (rake pre_commit) you must have either GraphicsMagick or ImageMagick
+installed.  If you are running MacOS X, these packages can be obtained through DarwinPorts.  Make sure you also
+install the port rb-rmagick.
 
-* rake          # Runs the build script
-* rcov          # Verifies that the code is 100% covered by specs
-* webgen        # Generates the static HTML website
-* RedCloth      # Required by webgen
-* syntax        # Required by our own custom webgen extension to highlight ruby code
-* diff-lcs      # Required if you use the --diff switch
-* win32console  # Required by the --colour switch if you're on Windows
-* meta_project  # Required in order to make releases at RubyForge
-* heckle        # Required if you use the --heckle switch
+The following gems are also required:
 
+* rake              # Runs the build script
+* rcov              # Verifies that the code is 100% covered by specs
+* webgen (v 0.3.8)  # Generates the static HTML website 
+* RedCloth          # Required by webgen
+* rmagick           # Also required by webgen
+* syntax            # Required by our own custom webgen extension to highlight ruby code
+* diff-lcs          # Required if you use the --diff switch
+* win32console      # Required by the --colour switch if you're on Windows
+* meta_project      # Required in order to make releases at RubyForge
+* heckle            # Required if you use the --heckle switch
+
+Make sure you install webgen version 0.3.8; later versions will break the build.        
+
 Note that RSpec itself - once built - doesn't have any dependencies outside the Ruby core 
 and stdlib - with a few exceptions:


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

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

Message:
applied to trunk and 0.9-dev (as of rev 1654)

Leaving this open though until Aslak's question gets answered. This is why we need to keep patches separate. Oops.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:24

Message:
I just uninstalled RMagick and rake webgen still runs fine (on my mac). You must be doing something wrong.

Why do you think it's needed?

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

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

From noreply at rubyforge.org  Sat Mar 24 17:03:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 17:03:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9509 ] allow spaced options in
	spec.opts
Message-ID: <20070324210339.CB16952408D9@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: allow spaced options in spec.opts

Initial Comment:
This will allow spaced options in spec.opts.  The old format of a newline between each option will still work.  These can also be combined, so, spec.opts could look like any of the following:

____________________________

-color
-format
s
____________________________

--color
--format s

____________________________

--color --format s
____________________________

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

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

Message:
applied to trunk and 0.9-dev (as of rev 1654)

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 20:56

Message:
Do you want me to submit the patches separately again, with
the diffs?  Or is the spec.opts patch (alone) not atomic
enough???

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 20:39

Message:
Applied in trunk(1652).

I went ahead and applied this, but for future, what we'd want is a single patch that has all of the changes (and only those changes) relevant to a given RFE.

Thanks for playing.

David

ps - leaving this open because it needs to be applied to 0.9-dev branch too.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 19:30

Message:
Do you want me to submit the patches separately again, with
the diffs?  Or is the spec.opts patch (alone) not atomic
enough???

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 12:28

Message:
Hi Scott - sorry if this seems like a pain, but we really want patches to be more atomic - addressing only one issue each.

I'm going to open up a separate thread on the rspec-devel list about this.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 10:26

Message:
Sorry about that. 

This diff also contains the other two "patches" - the one is
simply the addition of the html file for ruby 1.8.6, the
other is the change in the readme file.  Both have been
opened as separate patch tickets, so you may want to close
them after you get this.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:17

Message:
Scott,

We need this in diff format. This is to avoid that your file overwrites someone else's recent changes.

Stand in the root and do
svn diff > allow_spaces_in_spec_opts.patch



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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 04:56

Message:
Obviously the first example given in the last post should be:

--color
--format
s

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

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

From noreply at rubyforge.org  Sat Mar 24 17:04:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 17:04:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9510 ] Added File for Ruby 1.8.6
Message-ID: <20070324210404.69CE95240960@rubyforge.org>

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

Category: None
Group: None
Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Added File for Ruby 1.8.6

Initial Comment:
Not really a patch, just an added file for those developers who may be using ruby version 1.8.6

The file: rspec/spec/spec/runner/formatter/html_formatted-1.8.6.html

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

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

Message:
applied to trunk and 0.9-dev (as of rev 1654)

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

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

From noreply at rubyforge.org  Sat Mar 24 18:29:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 18:29:52 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070324222952.404535240A23@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

>Comment By: Bob Cotton (bcotton)
Date: 2007-03-24 16:29

Message:

I'm about to start implementing this. A couple of questions:

1. I suppose the only way to locate a shared 'describe'
would be through its description
2. I'll need to add an attr_reader for :examples to
Spec::DSL::Behavior::ModuleMethods so I can grab all shared
Examples and add them to the current Behavior just before
running.
3. I'll need to add either an attr_reader for :behaviors or
a find method to Spec::Runner::BehaviorRunner so I can
lookup behaviors by descritpion.

Thoughts?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-22 12:45

Message:

Very nice.

it_should_behave_as

Brainstorming with a co-worker:
behaving_as
behaves_like
sharing
acts_like
an_example_of
shares_behavior_with
shares_behavior_of
same_as
same_behavior_as
just_like
equivalent_to
it_doppelgangers

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-22 10:23

Message:
I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time.

We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this:

describe "AllEditions", :shared => true do
 it "should do something" do
 end
end

describe LargeEdition do
  it_should_behave_as "AllEditions"

  it "should also do something else" do
  end
end

That reads kinda nice, ay?


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

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

From noreply at rubyforge.org  Sat Mar 24 19:24:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 19:24:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070324232420.A00F95240A4D@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 23:24

Message:
Hi Bob - I assume you're working in the 0.9 branch, yes? If not, please do.

As for your questions - this is BDD! Write some specs! If we have any issues w/ the design, we'll talk about it later. Cool?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-24 22:29

Message:

I'm about to start implementing this. A couple of questions:

1. I suppose the only way to locate a shared 'describe'
would be through its description
2. I'll need to add an attr_reader for :examples to
Spec::DSL::Behavior::ModuleMethods so I can grab all shared
Examples and add them to the current Behavior just before
running.
3. I'll need to add either an attr_reader for :behaviors or
a find method to Spec::Runner::BehaviorRunner so I can
lookup behaviors by descritpion.

Thoughts?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-22 18:45

Message:

Very nice.

it_should_behave_as

Brainstorming with a co-worker:
behaving_as
behaves_like
sharing
acts_like
an_example_of
shares_behavior_with
shares_behavior_of
same_as
same_behavior_as
just_like
equivalent_to
it_doppelgangers

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-22 16:23

Message:
I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time.

We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this:

describe "AllEditions", :shared => true do
 it "should do something" do
 end
end

describe LargeEdition do
  it_should_behave_as "AllEditions"

  it "should also do something else" do
  end
end

That reads kinda nice, ay?


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

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

From noreply at rubyforge.org  Sat Mar 24 19:33:00 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 19:33:00 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070324233300.8AA375240A4D@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 23:33

Message:
Following up - I guess there's nothing wrong w/ talking about design a LITTLE first.

How about a collection on Spec::Runner with methods to interact with it right on the module. Something like:

Spec::Runner.add_shared_behaviour(behaviour)
Spec::Runner.find_shared_behaviour(:name)

This way you don't have to expose anything and those methods can handle the management of the collection.

Thoughts? Feel free to throw a BDD pie in my face instead of answering.

Cheers,
David

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

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

Message:
Hi Bob - I assume you're working in the 0.9 branch, yes? If not, please do.

As for your questions - this is BDD! Write some specs! If we have any issues w/ the design, we'll talk about it later. Cool?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-24 22:29

Message:

I'm about to start implementing this. A couple of questions:

1. I suppose the only way to locate a shared 'describe'
would be through its description
2. I'll need to add an attr_reader for :examples to
Spec::DSL::Behavior::ModuleMethods so I can grab all shared
Examples and add them to the current Behavior just before
running.
3. I'll need to add either an attr_reader for :behaviors or
a find method to Spec::Runner::BehaviorRunner so I can
lookup behaviors by descritpion.

Thoughts?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-22 18:45

Message:

Very nice.

it_should_behave_as

Brainstorming with a co-worker:
behaving_as
behaves_like
sharing
acts_like
an_example_of
shares_behavior_with
shares_behavior_of
same_as
same_behavior_as
just_like
equivalent_to
it_doppelgangers

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-22 16:23

Message:
I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time.

We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this:

describe "AllEditions", :shared => true do
 it "should do something" do
 end
end

describe LargeEdition do
  it_should_behave_as "AllEditions"

  it "should also do something else" do
  end
end

That reads kinda nice, ay?


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

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

From noreply at rubyforge.org  Sat Mar 24 19:44:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 24 Mar 2007 19:44:37 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9511 ] Clarification to README file
	in spec/
Message-ID: <20070324234437.69D165240A4D@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Clarification to README file in spec/

Initial Comment:

While building rspec I had quite a go of it.  Mainly because the README left out a few things (nothing which the devoted developers on the mailing list couldn't solve, though).  Here is what was left out:


webgen should be at version 0.3.8, not at it's latest version, which (as of March 24, 2007) is 0.4.2.

webgen requires rmagick, which in turn requires either imagemagick or graphicsmagick.

I installed the last packages through darwinports.  I believe that the rb-magick port must also be installed.  In the end, I ended up installing:

port: imagemagick
port: graphicsmagick
port: rb-rmagick
gem: rmagick
gem: webgen -v 0.3.8

All of this needs to be clarified in the documentation somewhere.  The README seems like the natural place, since already most of the info on building rspec is there.  Maybe it would be wise to separate this into another file?



Here is the diff:

Index: README
===================================================================
--- README      (revision 1650)
+++ README      (working copy)
@@ -35,18 +35,25 @@
   gem install pkg/rspec-0.x.x.gem (you may have to sudo)
 
 == Running the specs ==
-In order to run RSpec's full suite of specs (rake pre_commit) you must install the following gems:
+In order to run RSpec's full suite of specs (rake pre_commit) you must have either GraphicsMagick or ImageMagick
+installed.  If you are running MacOS X, these packages can be obtained through DarwinPorts.  Make sure you also
+install the port rb-rmagick.
 
-* rake          # Runs the build script
-* rcov          # Verifies that the code is 100% covered by specs
-* webgen        # Generates the static HTML website
-* RedCloth      # Required by webgen
-* syntax        # Required by our own custom webgen extension to highlight ruby code
-* diff-lcs      # Required if you use the --diff switch
-* win32console  # Required by the --colour switch if you're on Windows
-* meta_project  # Required in order to make releases at RubyForge
-* heckle        # Required if you use the --heckle switch
+The following gems are also required:
 
+* rake              # Runs the build script
+* rcov              # Verifies that the code is 100% covered by specs
+* webgen (v 0.3.8)  # Generates the static HTML website 
+* RedCloth          # Required by webgen
+* rmagick           # Also required by webgen
+* syntax            # Required by our own custom webgen extension to highlight ruby code
+* diff-lcs          # Required if you use the --diff switch
+* win32console      # Required by the --colour switch if you're on Windows
+* meta_project      # Required in order to make releases at RubyForge
+* heckle            # Required if you use the --heckle switch
+
+Make sure you install webgen version 0.3.8; later versions will break the build.        
+
 Note that RSpec itself - once built - doesn't have any dependencies outside the Ruby core 
 and stdlib - with a few exceptions:


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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 23:44

Message:
Aslak was right - neither rmagick, imagemagick,
graphicsmagick, nor the rb-rmagick port was needed, so I"ve
removed them from the documentation.  I've left in the note
about webgen 0.3.8, though. 

Not sure why I thought this was needed - I was pretty sure
that I saw some error message about rmagick needed in the
build.  Maybe this was only for the newer webgen gem.

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

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

Message:
applied to trunk and 0.9-dev (as of rev 1654)

Leaving this open though until Aslak's question gets answered. This is why we need to keep patches separate. Oops.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:24

Message:
I just uninstalled RMagick and rake webgen still runs fine (on my mac). You must be doing something wrong.

Why do you think it's needed?

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

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

From mailing_lists at railsnewbie.com  Sun Mar 25 03:29:25 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Sun, 25 Mar 2007 03:29:25 -0400
Subject: [rspec-devel] svn update after a patch
Message-ID: <95A63F50-88E8-4373-A88F-28544C581827@railsnewbie.com>


After running rake pre_commit, I can no longer run svn update.  Is  
there a better way to do it then deleting the whole trunk directory  
and checking it out again?

Thanks for your help,

Scott


From aslak.hellesoy at gmail.com  Sun Mar 25 06:23:36 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 25 Mar 2007 12:23:36 +0200
Subject: [rspec-devel] svn update after a patch
In-Reply-To: <95A63F50-88E8-4373-A88F-28544C581827@railsnewbie.com>
References: <95A63F50-88E8-4373-A88F-28544C581827@railsnewbie.com>
Message-ID: <8d961d900703250323l19bd60f8s254e87f9dbef1f43@mail.gmail.com>

On 3/25/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> After running rake pre_commit, I can no longer run svn update.

It sounds like you're having a conflict. (Some of your recent changes
are in conflict with some of ours).

> Is
> there a better way to do it then deleting the whole trunk directory
> and checking it out again?
>

If the conflicted files are the version.rb files - then just delete
them locally and svn up again.

If your problem is due to a different conflict, you can resolve the
conflict with 'svn resolve'.
http://svnbook.red-bean.com/nightly/en/svn.tour.cycle.html#svn.tour.cycle.resolve

Please show us the output from 'svn up' and 'svn stat'.

Aslak

> Thanks for your help,
>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Sun Mar 25 09:36:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 25 Mar 2007 09:36:50 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070325133650.896775240989@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

>Comment By: Bob Cotton (bcotton)
Date: 2007-03-25 07:36

Message:
Yes, I'll be doing the work on 0.9. 

No BDD pie necessary, not being that familar with the code
base, just wanted to make sure I wasn't missing anything.

Before I can define behavior, I want to make sure I've got
all the right classes.

Don't worry, there will be specs!

Thanks for the followup

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 17:33

Message:
Following up - I guess there's nothing wrong w/ talking about design a LITTLE first.

How about a collection on Spec::Runner with methods to interact with it right on the module. Something like:

Spec::Runner.add_shared_behaviour(behaviour)
Spec::Runner.find_shared_behaviour(:name)

This way you don't have to expose anything and those methods can handle the management of the collection.

Thoughts? Feel free to throw a BDD pie in my face instead of answering.

Cheers,
David

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

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

Message:
Hi Bob - I assume you're working in the 0.9 branch, yes? If not, please do.

As for your questions - this is BDD! Write some specs! If we have any issues w/ the design, we'll talk about it later. Cool?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-24 16:29

Message:

I'm about to start implementing this. A couple of questions:

1. I suppose the only way to locate a shared 'describe'
would be through its description
2. I'll need to add an attr_reader for :examples to
Spec::DSL::Behavior::ModuleMethods so I can grab all shared
Examples and add them to the current Behavior just before
running.
3. I'll need to add either an attr_reader for :behaviors or
a find method to Spec::Runner::BehaviorRunner so I can
lookup behaviors by descritpion.

Thoughts?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-22 12:45

Message:

Very nice.

it_should_behave_as

Brainstorming with a co-worker:
behaving_as
behaves_like
sharing
acts_like
an_example_of
shares_behavior_with
shares_behavior_of
same_as
same_behavior_as
just_like
equivalent_to
it_doppelgangers

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-22 10:23

Message:
I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time.

We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this:

describe "AllEditions", :shared => true do
 it "should do something" do
 end
end

describe LargeEdition do
  it_should_behave_as "AllEditions"

  it "should also do something else" do
  end
end

That reads kinda nice, ay?


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

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

From brian.takita at gmail.com  Sun Mar 25 18:12:49 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 25 Mar 2007 15:12:49 -0700
Subject: [rspec-devel] Code Coverage Failures
Message-ID: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>

Hello,

I tried running rake for rspec and got a rcov error.

Coverage: 89.9% (threshold: 100.0%)
rake aborted!
Coverage must be at least 100.0% but was 89.9%

In spectask.rb I am also using system("ruby #{rest_of_cmd)") instead of
ruby(cmd) because Rake's ruby command does not seem to print out to stderr.

Here is my patch. Is anybody else getting this issue? I'm running on Ubuntu
and Ruby 1.8.6.

Thanks,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070325/9dd3649e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: more_transparent_spectask.patch
Type: text/x-patch
Size: 3777 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20070325/9dd3649e/attachment.bin 

From aslak.hellesoy at gmail.com  Sun Mar 25 19:14:37 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 26 Mar 2007 01:14:37 +0200
Subject: [rspec-devel] Code Coverage Failures
In-Reply-To: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
References: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
Message-ID: <8d961d900703251614j56630550n5825c83229db05a5@mail.gmail.com>

On 3/26/07, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> I tried running rake for rspec and got a rcov error.
>
> Coverage: 89.9% (threshold: 100.0%)
> rake aborted!
> Coverage must be at least 100.0% but was 89.9%
>
> In spectask.rb I am also using system("ruby #{rest_of_cmd)") instead of
> ruby(cmd) because Rake's ruby command does not seem to print out to stderr.
>
> Here is my patch. Is anybody else getting this issue? I'm running on Ubuntu
> and Ruby 1.8.6.
>

I'm still getting 100% coverage (on branches/0.9-dev). Are you in the
same spot or on trunk?

Aslak

> Thanks,
> Brian
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From aslak.hellesoy at gmail.com  Sun Mar 25 19:26:15 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 26 Mar 2007 01:26:15 +0200
Subject: [rspec-devel] Code Coverage Failures
In-Reply-To: <8d961d900703251614j56630550n5825c83229db05a5@mail.gmail.com>
References: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
	<8d961d900703251614j56630550n5825c83229db05a5@mail.gmail.com>
Message-ID: <8d961d900703251626u5e3253bbj5db5314350d4b40a@mail.gmail.com>

On 3/26/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 3/26/07, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > I tried running rake for rspec and got a rcov error.
> >
> > Coverage: 89.9% (threshold: 100.0%)
> > rake aborted!
> > Coverage must be at least 100.0% but was 89.9%
> >
> > In spectask.rb I am also using system("ruby #{rest_of_cmd)") instead of
> > ruby(cmd) because Rake's ruby command does not seem to print out to stderr.
> >
> > Here is my patch. Is anybody else getting this issue? I'm running on Ubuntu
> > and Ruby 1.8.6.
> >
>
> I'm still getting 100% coverage (on branches/0.9-dev). Are you in the
> same spot or on trunk?
>

I forgot to mention I'm still on ruby 1.8.4 :-D
David is exploring multiruby - it's most likely a 1.8.6 issue

Aslak

> Aslak
>
> > Thanks,
> > Brian
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
>

From aslak.hellesoy at gmail.com  Sun Mar 25 19:42:07 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 26 Mar 2007 01:42:07 +0200
Subject: [rspec-devel] Code Coverage Failures
In-Reply-To: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
References: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
Message-ID: <8d961d900703251642o5342fcc1v903b90164cb1c115@mail.gmail.com>

On 3/26/07, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> I tried running rake for rspec and got a rcov error.
>
> Coverage: 89.9% (threshold: 100.0%)
> rake aborted!
> Coverage must be at least 100.0% but was 89.9%
>

If you look at the generated rcov report, what's not covered? Could
you tar it up and send it to the list for inspection?

> In spectask.rb I am also using system("ruby #{rest_of_cmd)") instead of
> ruby(cmd) because Rake's ruby command does not seem to print out to stderr.
>
> Here is my patch. Is anybody else getting this issue? I'm running on Ubuntu
> and Ruby 1.8.6.
>

Just go ahead and commit it. Make sure you do it on the 0.9-dev
branch, which acts as trunk for the moment.

> Thanks,
> Brian
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From dchelimsky at gmail.com  Sun Mar 25 22:48:53 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 25 Mar 2007 21:48:53 -0500
Subject: [rspec-devel] Code Coverage Failures
In-Reply-To: <8d961d900703251642o5342fcc1v903b90164cb1c115@mail.gmail.com>
References: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
	<8d961d900703251642o5342fcc1v903b90164cb1c115@mail.gmail.com>
Message-ID: <57c63afe0703251948x7f585ee4sb30656ec32a22b6f@mail.gmail.com>

I updated 0.9-dev and ran rake and it just hangs now after running the
specs and reporting the coverage. I don't have time to look into this
tonight or probably at all tomorrow, so if anybody else can that would
be great.

Thanks,
David


On 3/25/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 3/26/07, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > I tried running rake for rspec and got a rcov error.
> >
> > Coverage: 89.9% (threshold: 100.0%)
> > rake aborted!
> > Coverage must be at least 100.0% but was 89.9%
> >
>
> If you look at the generated rcov report, what's not covered? Could
> you tar it up and send it to the list for inspection?
>
> > In spectask.rb I am also using system("ruby #{rest_of_cmd)") instead of
> > ruby(cmd) because Rake's ruby command does not seem to print out to stderr.
> >
> > Here is my patch. Is anybody else getting this issue? I'm running on Ubuntu
> > and Ruby 1.8.6.
> >
>
> Just go ahead and commit it. Make sure you do it on the 0.9-dev
> branch, which acts as trunk for the moment.
>
> > Thanks,
> > Brian
> >
> > _______________________________________________
> > 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 brian.takita at gmail.com  Mon Mar 26 00:09:21 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 25 Mar 2007 21:09:21 -0700
Subject: [rspec-devel] Code Coverage Failures
In-Reply-To: <57c63afe0703251948x7f585ee4sb30656ec32a22b6f@mail.gmail.com>
References: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
	<8d961d900703251642o5342fcc1v903b90164cb1c115@mail.gmail.com>
	<57c63afe0703251948x7f585ee4sb30656ec32a22b6f@mail.gmail.com>
Message-ID: <1d7ddd110703252109g738f9e9era031cb088b93e19@mail.gmail.com>

On 3/25/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> I updated 0.9-dev and ran rake and it just hangs now after running the
> specs and reporting the coverage. I don't have time to look into this
> tonight or probably at all tomorrow, so if anybody else can that would
> be great.


I just committed a change that will reintroduce the ruby method call. It
turns out that if you pass in a block, you can override Rake's way of
handling errors.
I commented out Rake's fail message. If your rake task still freezes, then
the fail method call seems to stop the process.

                ruby(ruby_cmd) do |ok, status|
#                  ok or fail "Command failed with status (#{
status.exitstatus}): [#{show_command}]"
                end

Thanks,
> David
>
>
> On 3/25/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 3/26/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > Hello,
> > >
> > > I tried running rake for rspec and got a rcov error.
> > >
> > > Coverage: 89.9% (threshold: 100.0%)
> > > rake aborted!
> > > Coverage must be at least 100.0% but was 89.9%
> > >
> >
> > If you look at the generated rcov report, what's not covered? Could
> > you tar it up and send it to the list for inspection?
> >
> > > In spectask.rb I am also using system("ruby #{rest_of_cmd)") instead
> of
> > > ruby(cmd) because Rake's ruby command does not seem to print out to
> stderr.
> > >
> > > Here is my patch. Is anybody else getting this issue? I'm running on
> Ubuntu
> > > and Ruby 1.8.6.
> > >
> >
> > Just go ahead and commit it. Make sure you do it on the 0.9-dev
> > branch, which acts as trunk for the moment.
> >
> > > Thanks,
> > > Brian
> > >
> > > _______________________________________________
> > > 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
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070325/71f7adf2/attachment.html 

From dchelimsky at gmail.com  Mon Mar 26 07:48:22 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 26 Mar 2007 06:48:22 -0500
Subject: [rspec-devel] Code Coverage Failures
In-Reply-To: <1d7ddd110703252109g738f9e9era031cb088b93e19@mail.gmail.com>
References: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
	<8d961d900703251642o5342fcc1v903b90164cb1c115@mail.gmail.com>
	<57c63afe0703251948x7f585ee4sb30656ec32a22b6f@mail.gmail.com>
	<1d7ddd110703252109g738f9e9era031cb088b93e19@mail.gmail.com>
Message-ID: <57c63afe0703260448u691f5d7fv9313965cc7fe47db@mail.gmail.com>

On 3/25/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 3/25/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > I updated 0.9-dev and ran rake and it just hangs now after running the
> > specs and reporting the coverage. I don't have time to look into this
> > tonight or probably at all tomorrow, so if anybody else can that would
> > be great.
>
> I just committed a change that will reintroduce the ruby method call. It
> turns out that if you pass in a block, you can override Rake's way of
> handling errors.
> I commented out Rake's fail message. If your rake task still freezes, then
> the fail method call seems to stop the process.
>
>                 ruby(ruby_cmd) do |ok, status|
> #                  ok or fail "Command failed with status
> (#{status.exitstatus}): [#{show_command}]"
>                 end
>

Thanks for trying Brian, but it still hangs for me in the same spot.
I'm running on 1.8.5.

I'll take a look at this tonight.

David


> > Thanks,
> > David
> >
> >
> > On 3/25/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 3/26/07, Brian Takita <brian.takita at gmail.com > wrote:
> > > > Hello,
> > > >
> > > > I tried running rake for rspec and got a rcov error.
> > > >
> > > > Coverage: 89.9% (threshold: 100.0%)
> > > > rake aborted!
> > > > Coverage must be at least 100.0% but was 89.9%
> > > >
> > >
> > > If you look at the generated rcov report, what's not covered? Could
> > > you tar it up and send it to the list for inspection?
> > >
> > > > In spectask.rb I am also using system("ruby #{rest_of_cmd)") instead
> of
> > > > ruby(cmd) because Rake's ruby command does not seem to print out to
> stderr.
> > > >
> > > > Here is my patch. Is anybody else getting this issue? I'm running on
> Ubuntu
> > > > and Ruby 1.8.6.
> > > >
> > >
> > > Just go ahead and commit it. Make sure you do it on the 0.9-dev
> > > branch, which acts as trunk for the moment.
> > >
> > > > Thanks,
> > > > Brian
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > _______________________________________________
> > 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 bob.cotton at rallydev.com  Mon Mar 26 11:27:50 2007
From: bob.cotton at rallydev.com (Bob Cotton)
Date: Mon, 26 Mar 2007 09:27:50 -0600
Subject: [rspec-devel] Multiple optional arguments to 'describe'
Message-ID: <m1fy7sja89.fsf@boblaptop.local>


I need to add an optional hash argument to 'describe' for shared
behaviors,

describe "Foo", :shared => true do
end

however, there is another optional argument present:

  def describe(type_or_description, additional_description=nil, &block)

If I add another optional argument, when specifying one, you will have
to specify both.

  def describe(type_or_description, additional_description=nil,
               options => {}, &block)

Thoughts on how to handle this?

describe_shared
shared_context

?

- Bob

From dchelimsky at gmail.com  Mon Mar 26 14:19:06 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 26 Mar 2007 13:19:06 -0500
Subject: [rspec-devel] Multiple optional arguments to 'describe'
In-Reply-To: <m1fy7sja89.fsf@boblaptop.local>
References: <m1fy7sja89.fsf@boblaptop.local>
Message-ID: <57c63afe0703261119o4d5b55c7rf8abae8617fbe5ef@mail.gmail.com>

I've typically seen this:

def method_name(*args, &block)
  if Hash === args.last
    opts = args.pop
  end
  ...
end

On 3/26/07, Bob Cotton <bob.cotton at rallydev.com> wrote:
>
> I need to add an optional hash argument to 'describe' for shared
> behaviors,
>
> describe "Foo", :shared => true do
> end
>
> however, there is another optional argument present:
>
>   def describe(type_or_description, additional_description=nil, &block)
>
> If I add another optional argument, when specifying one, you will have
> to specify both.
>
>   def describe(type_or_description, additional_description=nil,
>                options => {}, &block)
>
> Thoughts on how to handle this?
>
> describe_shared
> shared_context
>
> ?
>
> - Bob
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Mon Mar 26 16:10:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 26 Mar 2007 16:10:22 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9598 ] Change to Object.path2class to
	resolve conflicts with namespaced controllers
Message-ID: <20070326201023.2812F5240AED@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: bruno bornsztein (bborn)
Assigned to: Nobody (None)
Summary: Change to Object.path2class to resolve conflicts with namespaced controllers

Initial Comment:
The RSpec on Rails plugin adds a path2class method to Object, which is intended to get a class from a string; however the existing implementation failed when using namespaced classes, for example:

def self.path2class(klassname)
  klassname.split('::').inject(Object) { |k,n| k.const_get n }   
end

"TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController
"Admin::TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController

This is a problem if you have two controllers with the same name in different namespaces.

The solution uses Rails' Inflector.constantize instead:

def self.path2class(klassname)
  klassname.constantize  
end

"TenantsController".constantize
=> TenantsController
"Admin::TenantsController".constantize
=> Admin::TenantsController

This yields the expected result.

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

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

From noreply at rubyforge.org  Mon Mar 26 16:11:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 26 Mar 2007 16:11:22 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9598 ] Change to Object.path2class to
	resolve conflicts with namespaced controllers
Message-ID: <20070326201122.11B0C5240AF6@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: bruno bornsztein (bborn)
Assigned to: Nobody (None)
Summary: Change to Object.path2class to resolve conflicts with namespaced controllers

Initial Comment:
The RSpec on Rails plugin adds a path2class method to Object, which is intended to get a class from a string; however the existing implementation failed when using namespaced classes, for example:

def self.path2class(klassname)
  klassname.split('::').inject(Object) { |k,n| k.const_get n }   
end

"TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController
"Admin::TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController

This is a problem if you have two controllers with the same name in different namespaces.

The solution uses Rails' Inflector.constantize instead:

def self.path2class(klassname)
  klassname.constantize  
end

"TenantsController".constantize
=> TenantsController
"Admin::TenantsController".constantize
=> Admin::TenantsController

This yields the expected result.

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

>Comment By: bruno bornsztein (bborn)
Date: 2007-03-26 15:11

Message:
Here's a spec.

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

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

From noreply at rubyforge.org  Mon Mar 26 16:11:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 26 Mar 2007 16:11:49 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9598 ] Change to Object.path2class to
	resolve conflicts with namespaced controllers
Message-ID: <20070326201149.6FB8D5240AFA@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: bruno bornsztein (bborn)
Assigned to: Nobody (None)
Summary: Change to Object.path2class to resolve conflicts with namespaced controllers

Initial Comment:
The RSpec on Rails plugin adds a path2class method to Object, which is intended to get a class from a string; however the existing implementation failed when using namespaced classes, for example:

def self.path2class(klassname)
  klassname.split('::').inject(Object) { |k,n| k.const_get n }   
end

"TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController
"Admin::TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController

This is a problem if you have two controllers with the same name in different namespaces.

The solution uses Rails' Inflector.constantize instead:

def self.path2class(klassname)
  klassname.constantize  
end

"TenantsController".constantize
=> TenantsController
"Admin::TenantsController".constantize
=> Admin::TenantsController

This yields the expected result.

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

Comment By: bruno bornsztein (bborn)
Date: 2007-03-26 15:11

Message:
Here's a spec.

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

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

From noreply at rubyforge.org  Mon Mar 26 16:12:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 26 Mar 2007 16:12:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9598 ] Change to Object.path2class to
	resolve conflicts with namespaced controllers
Message-ID: <20070326201205.062DE5240AFA@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: bruno bornsztein (bborn)
Assigned to: Nobody (None)
Summary: Change to Object.path2class to resolve conflicts with namespaced controllers

Initial Comment:
The RSpec on Rails plugin adds a path2class method to Object, which is intended to get a class from a string; however the existing implementation failed when using namespaced classes, for example:

def self.path2class(klassname)
  klassname.split('::').inject(Object) { |k,n| k.const_get n }   
end

"TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController
"Admin::TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController

This is a problem if you have two controllers with the same name in different namespaces.

The solution uses Rails' Inflector.constantize instead:

def self.path2class(klassname)
  klassname.constantize  
end

"TenantsController".constantize
=> TenantsController
"Admin::TenantsController".constantize
=> Admin::TenantsController

This yields the expected result.

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

Comment By: bruno bornsztein (bborn)
Date: 2007-03-26 15:11

Message:
Here's a spec.

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

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

From noreply at rubyforge.org  Mon Mar 26 16:12:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 26 Mar 2007 16:12:33 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9598 ] Change to Object.path2class to
	resolve conflicts with namespaced controllers
Message-ID: <20070326201233.EB4005240AED@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: bruno bornsztein (bborn)
Assigned to: Nobody (None)
Summary: Change to Object.path2class to resolve conflicts with namespaced controllers

Initial Comment:
The RSpec on Rails plugin adds a path2class method to Object, which is intended to get a class from a string; however the existing implementation failed when using namespaced classes, for example:

def self.path2class(klassname)
  klassname.split('::').inject(Object) { |k,n| k.const_get n }   
end

"TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController
"Admin::TenantsController".inject(Object) { |k,n| k.const_get n }  
=> TenantsController

This is a problem if you have two controllers with the same name in different namespaces.

The solution uses Rails' Inflector.constantize instead:

def self.path2class(klassname)
  klassname.constantize  
end

"TenantsController".constantize
=> TenantsController
"Admin::TenantsController".constantize
=> Admin::TenantsController

This yields the expected result.

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

>Comment By: bruno bornsztein (bborn)
Date: 2007-03-26 15:12

Message:
Sorry... forgot to check the box when attaching files.

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

Comment By: bruno bornsztein (bborn)
Date: 2007-03-26 15:11

Message:
Here's a spec.

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

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

From noreply at rubyforge.org  Mon Mar 26 21:01:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 26 Mar 2007 21:01:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070327010157.ABE495240B03@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

>Comment By: Bob Cotton (bcotton)
Date: 2007-03-26 19:01

Message:
Thoughs on the wording for including shared behavior, before
I write the doc and submit the patch?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-25 07:36

Message:
Yes, I'll be doing the work on 0.9. 

No BDD pie necessary, not being that familar with the code
base, just wanted to make sure I wasn't missing anything.

Before I can define behavior, I want to make sure I've got
all the right classes.

Don't worry, there will be specs!

Thanks for the followup

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 17:33

Message:
Following up - I guess there's nothing wrong w/ talking about design a LITTLE first.

How about a collection on Spec::Runner with methods to interact with it right on the module. Something like:

Spec::Runner.add_shared_behaviour(behaviour)
Spec::Runner.find_shared_behaviour(:name)

This way you don't have to expose anything and those methods can handle the management of the collection.

Thoughts? Feel free to throw a BDD pie in my face instead of answering.

Cheers,
David

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

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

Message:
Hi Bob - I assume you're working in the 0.9 branch, yes? If not, please do.

As for your questions - this is BDD! Write some specs! If we have any issues w/ the design, we'll talk about it later. Cool?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-24 16:29

Message:

I'm about to start implementing this. A couple of questions:

1. I suppose the only way to locate a shared 'describe'
would be through its description
2. I'll need to add an attr_reader for :examples to
Spec::DSL::Behavior::ModuleMethods so I can grab all shared
Examples and add them to the current Behavior just before
running.
3. I'll need to add either an attr_reader for :behaviors or
a find method to Spec::Runner::BehaviorRunner so I can
lookup behaviors by descritpion.

Thoughts?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-22 12:45

Message:

Very nice.

it_should_behave_as

Brainstorming with a co-worker:
behaving_as
behaves_like
sharing
acts_like
an_example_of
shares_behavior_with
shares_behavior_of
same_as
same_behavior_as
just_like
equivalent_to
it_doppelgangers

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-22 10:23

Message:
I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time.

We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this:

describe "AllEditions", :shared => true do
 it "should do something" do
 end
end

describe LargeEdition do
  it_should_behave_as "AllEditions"

  it "should also do something else" do
  end
end

That reads kinda nice, ay?


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

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

From noreply at rubyforge.org  Mon Mar 26 21:24:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 26 Mar 2007 21:24:08 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9472 ] Provide way to
	extract specify/it into includable module
Message-ID: <20070327012408.40A8C5240B05@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Provide way to extract specify/it into includable module

Initial Comment:
Based on the conversation here http://rubyforge.org/pipermail/rspec-users/2007-March/000993.html

provide the ability to extract specify/it into a module that may be included into a context/describe

For example:


describe AllEditions, :shared => true do
 it "should" do
 end
end

describe LargeEdition do
  include AllEditions

  it "should also" do
  end
end



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-27 01:24

Message:
I need to think about how to word some things. Why don't you go ahead and give it your best shot and I'll tweak what I think needs tweaking. OK?

Thanks Bob - a lot of people have been waiting for a feature like this.

Cheers,
David

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 01:01

Message:
Thoughs on the wording for including shared behavior, before
I write the doc and submit the patch?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-25 13:36

Message:
Yes, I'll be doing the work on 0.9. 

No BDD pie necessary, not being that familar with the code
base, just wanted to make sure I wasn't missing anything.

Before I can define behavior, I want to make sure I've got
all the right classes.

Don't worry, there will be specs!

Thanks for the followup

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-24 23:33

Message:
Following up - I guess there's nothing wrong w/ talking about design a LITTLE first.

How about a collection on Spec::Runner with methods to interact with it right on the module. Something like:

Spec::Runner.add_shared_behaviour(behaviour)
Spec::Runner.find_shared_behaviour(:name)

This way you don't have to expose anything and those methods can handle the management of the collection.

Thoughts? Feel free to throw a BDD pie in my face instead of answering.

Cheers,
David

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

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

Message:
Hi Bob - I assume you're working in the 0.9 branch, yes? If not, please do.

As for your questions - this is BDD! Write some specs! If we have any issues w/ the design, we'll talk about it later. Cool?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-24 22:29

Message:

I'm about to start implementing this. A couple of questions:

1. I suppose the only way to locate a shared 'describe'
would be through its description
2. I'll need to add an attr_reader for :examples to
Spec::DSL::Behavior::ModuleMethods so I can grab all shared
Examples and add them to the current Behavior just before
running.
3. I'll need to add either an attr_reader for :behaviors or
a find method to Spec::Runner::BehaviorRunner so I can
lookup behaviors by descritpion.

Thoughts?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-22 18:45

Message:

Very nice.

it_should_behave_as

Brainstorming with a co-worker:
behaving_as
behaves_like
sharing
acts_like
an_example_of
shares_behavior_with
shares_behavior_of
same_as
same_behavior_as
just_like
equivalent_to
it_doppelgangers

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-22 16:23

Message:
I like this idea in general. I know we've been resistant to add any sort of example (spec) sharing, but perhaps now is the time.

We can't really just say describe AllEditions because Ruby would treat that as a constant and not be able to find it. Also, include implies a module - this is a bit different. So I'm thinking something like this:

describe "AllEditions", :shared => true do
 it "should do something" do
 end
end

describe LargeEdition do
  it_should_behave_as "AllEditions"

  it "should also do something else" do
  end
end

That reads kinda nice, ay?


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

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

From noreply at rubyforge.org  Tue Mar 27 00:08:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 00:08:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472,
	shared behaviour
Message-ID: <20070327040812.EF5585240B18@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Patch for ER 9472, shared behaviour

Initial Comment:
I chose behaves_as, as the inclusion method.
I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad.

Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another.

There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors!

 -Bob

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

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

From noreply at rubyforge.org  Tue Mar 27 00:10:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 00:10:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472,
	shared behaviour
Message-ID: <20070327041004.3E7365240B1A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Patch for ER 9472, shared behaviour

Initial Comment:
I chose behaves_as, as the inclusion method.
I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad.

Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another.

There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors!

 -Bob

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

>Comment By: Bob Cotton (bcotton)
Date: 2007-03-26 22:10

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

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

From noreply at rubyforge.org  Tue Mar 27 00:15:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 00:15:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472,
	shared behaviour
Message-ID: <20070327041557.DF91C5240B18@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Patch for ER 9472, shared behaviour

Initial Comment:
I chose behaves_as, as the inclusion method.
I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad.

Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another.

There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors!

 -Bob

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-27 04:15

Message:
Hi Bob - I'll take a look at this tomorrow. Thanks.

FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now.

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 04:10

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

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

From noreply at rubyforge.org  Tue Mar 27 00:16:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 00:16:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472,
	shared behaviour
Message-ID: <20070327041635.89FB65240B18@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Patch for ER 9472, shared behaviour

Initial Comment:
I chose behaves_as, as the inclusion method.
I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad.

Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another.

There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors!

 -Bob

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

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

Message:
File please.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-27 04:15

Message:
Hi Bob - I'll take a look at this tomorrow. Thanks.

FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now.

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 04:10

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

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

From noreply at rubyforge.org  Tue Mar 27 03:19:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 03:19:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9607 ] Rails 2.0 render issue
Message-ID: <20070327071919.460545240B1E@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Zach Inglis (zachinglis)
Assigned to: Nobody (None)
Summary: Rails 2.0 render issue

Initial Comment:
rspec gives the code:
render 'controller/action' which is not allowed in Rails 2.0 and will give you an error. It should render:
render :controller => "controller", :action => "action"

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

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

From noreply at rubyforge.org  Tue Mar 27 03:25:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 03:25:24 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9607 ] Rails 2.0 render issue
Message-ID: <20070327072524.E625F5240B1E@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Zach Inglis (zachinglis)
Assigned to: Nobody (None)
Summary: Rails 2.0 render issue

Initial Comment:
rspec gives the code:
render 'controller/action' which is not allowed in Rails 2.0 and will give you an error. It should render:
render :controller => "controller", :action => "action"

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

>Comment By: Zach Inglis (zachinglis)
Date: 2007-03-27 02:25

Message:
err, actually the substitute code gives me an error.

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

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

From noreply at rubyforge.org  Tue Mar 27 08:11:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 08:11:24 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472,
	shared behaviour
Message-ID: <20070327121124.AA21E5240B35@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Patch for ER 9472, shared behaviour

Initial Comment:
I chose behaves_as, as the inclusion method.
I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad.

Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another.

There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors!

 -Bob

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

>Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 06:11

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-26 22:16

Message:
File please.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-26 22:15

Message:
Hi Bob - I'll take a look at this tomorrow. Thanks.

FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now.

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-26 22:10

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

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

From noreply at rubyforge.org  Tue Mar 27 08:12:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 08:12:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472,
	shared behaviour
Message-ID: <20070327121213.9C1075240B42@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Patch for ER 9472, shared behaviour

Initial Comment:
I chose behaves_as, as the inclusion method.
I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad.

Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another.

There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors!

 -Bob

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

>Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 06:12

Message:
Missed the checkbox. Sorry.

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 06:11

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-26 22:16

Message:
File please.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-26 22:15

Message:
Hi Bob - I'll take a look at this tomorrow. Thanks.

FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now.

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-26 22:10

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

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

From noreply at rubyforge.org  Tue Mar 27 18:03:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 18:03:34 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9631 ] Custom Behaviour
	Runner
Message-ID: <20070327220335.14BE25240B47@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Custom Behaviour Runner

Initial Comment:
Command line switch for custom behaviour runner.

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

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

From noreply at rubyforge.org  Tue Mar 27 19:45:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 19:45:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9631 ] Custom Behaviour
	Runner
Message-ID: <20070327234536.158285240A56@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Custom Behaviour Runner

Initial Comment:
Command line switch for custom behaviour runner.

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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-27 19:45

Message:
Interesting feature. Could you elaborate a little on the need for custom runners? I'm not sceptical - just curious. What does *your* custom runner do differently? (I assume you have one)

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

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

From noreply at rubyforge.org  Tue Mar 27 22:17:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 27 Mar 2007 22:17:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9631 ] Custom Behaviour
	Runner
Message-ID: <20070328021715.884965240B4B@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Custom Behaviour Runner

Initial Comment:
Command line switch for custom behaviour runner.

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

>Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 20:17

Message:
We use rspec mostly for acceptance testing, driving
selenium. Slow, Slow, Slow. It's for a multi-threaded runner.

 -Bob

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-27 17:45

Message:
Interesting feature. Could you elaborate a little on the need for custom runners? I'm not sceptical - just curious. What does *your* custom runner do differently? (I assume you have one)

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

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

From noreply at rubyforge.org  Wed Mar 28 01:11:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 28 Mar 2007 01:11:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9511 ] Clarification to README file
	in spec/
Message-ID: <20070328051119.1710B5240B63@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Clarification to README file in spec/

Initial Comment:

While building rspec I had quite a go of it.  Mainly because the README left out a few things (nothing which the devoted developers on the mailing list couldn't solve, though).  Here is what was left out:


webgen should be at version 0.3.8, not at it's latest version, which (as of March 24, 2007) is 0.4.2.

webgen requires rmagick, which in turn requires either imagemagick or graphicsmagick.

I installed the last packages through darwinports.  I believe that the rb-magick port must also be installed.  In the end, I ended up installing:

port: imagemagick
port: graphicsmagick
port: rb-rmagick
gem: rmagick
gem: webgen -v 0.3.8

All of this needs to be clarified in the documentation somewhere.  The README seems like the natural place, since already most of the info on building rspec is there.  Maybe it would be wise to separate this into another file?



Here is the diff:

Index: README
===================================================================
--- README      (revision 1650)
+++ README      (working copy)
@@ -35,18 +35,25 @@
   gem install pkg/rspec-0.x.x.gem (you may have to sudo)
 
 == Running the specs ==
-In order to run RSpec's full suite of specs (rake pre_commit) you must install the following gems:
+In order to run RSpec's full suite of specs (rake pre_commit) you must have either GraphicsMagick or ImageMagick
+installed.  If you are running MacOS X, these packages can be obtained through DarwinPorts.  Make sure you also
+install the port rb-rmagick.
 
-* rake          # Runs the build script
-* rcov          # Verifies that the code is 100% covered by specs
-* webgen        # Generates the static HTML website
-* RedCloth      # Required by webgen
-* syntax        # Required by our own custom webgen extension to highlight ruby code
-* diff-lcs      # Required if you use the --diff switch
-* win32console  # Required by the --colour switch if you're on Windows
-* meta_project  # Required in order to make releases at RubyForge
-* heckle        # Required if you use the --heckle switch
+The following gems are also required:
 
+* rake              # Runs the build script
+* rcov              # Verifies that the code is 100% covered by specs
+* webgen (v 0.3.8)  # Generates the static HTML website 
+* RedCloth          # Required by webgen
+* rmagick           # Also required by webgen
+* syntax            # Required by our own custom webgen extension to highlight ruby code
+* diff-lcs          # Required if you use the --diff switch
+* win32console      # Required by the --colour switch if you're on Windows
+* meta_project      # Required in order to make releases at RubyForge
+* heckle            # Required if you use the --heckle switch
+
+Make sure you install webgen version 0.3.8; later versions will break the build.        
+
 Note that RSpec itself - once built - doesn't have any dependencies outside the Ruby core 
 and stdlib - with a few exceptions:


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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-28 05:11

Message:
Just to let you know, you should close this because Aslak's
questions were answered.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 23:44

Message:
Aslak was right - neither rmagick, imagemagick,
graphicsmagick, nor the rb-rmagick port was needed, so I"ve
removed them from the documentation.  I've left in the note
about webgen 0.3.8, though. 

Not sure why I thought this was needed - I was pretty sure
that I saw some error message about rmagick needed in the
build.  Maybe this was only for the newer webgen gem.

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

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

Message:
applied to trunk and 0.9-dev (as of rev 1654)

Leaving this open though until Aslak's question gets answered. This is why we need to keep patches separate. Oops.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-24 10:24

Message:
I just uninstalled RMagick and rake webgen still runs fine (on my mac). You must be doing something wrong.

Why do you think it's needed?

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

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

From noreply at rubyforge.org  Wed Mar 28 03:01:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 28 Mar 2007 03:01:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9631 ] Custom Behaviour
	Runner
Message-ID: <20070328070132.E902A5240B6E@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Custom Behaviour Runner

Initial Comment:
Command line switch for custom behaviour runner.

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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-28 03:01

Message:
I'm also at a project where we do that (except we're using Watir). Our suite takes close to half an hour, so I'd be *very* interested in this. Is this something you can/want to share?

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 22:17

Message:
We use rspec mostly for acceptance testing, driving
selenium. Slow, Slow, Slow. It's for a multi-threaded runner.

 -Bob

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-27 19:45

Message:
Interesting feature. Could you elaborate a little on the need for custom runners? I'm not sceptical - just curious. What does *your* custom runner do differently? (I assume you have one)

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

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

From noreply at rubyforge.org  Wed Mar 28 03:05:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 28 Mar 2007 03:05:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9511 ] Clarification to README file
	in spec/
Message-ID: <20070328070533.0DE875240B6E@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Clarification to README file in spec/

Initial Comment:

While building rspec I had quite a go of it.  Mainly because the README left out a few things (nothing which the devoted developers on the mailing list couldn't solve, though).  Here is what was left out:


webgen should be at version 0.3.8, not at it's latest version, which (as of March 24, 2007) is 0.4.2.

webgen requires rmagick, which in turn requires either imagemagick or graphicsmagick.

I installed the last packages through darwinports.  I believe that the rb-magick port must also be installed.  In the end, I ended up installing:

port: imagemagick
port: graphicsmagick
port: rb-rmagick
gem: rmagick
gem: webgen -v 0.3.8

All of this needs to be clarified in the documentation somewhere.  The README seems like the natural place, since already most of the info on building rspec is there.  Maybe it would be wise to separate this into another file?



Here is the diff:

Index: README
===================================================================
--- README      (revision 1650)
+++ README      (working copy)
@@ -35,18 +35,25 @@
   gem install pkg/rspec-0.x.x.gem (you may have to sudo)
 
 == Running the specs ==
-In order to run RSpec's full suite of specs (rake pre_commit) you must install the following gems:
+In order to run RSpec's full suite of specs (rake pre_commit) you must have either GraphicsMagick or ImageMagick
+installed.  If you are running MacOS X, these packages can be obtained through DarwinPorts.  Make sure you also
+install the port rb-rmagick.
 
-* rake          # Runs the build script
-* rcov          # Verifies that the code is 100% covered by specs
-* webgen        # Generates the static HTML website
-* RedCloth      # Required by webgen
-* syntax        # Required by our own custom webgen extension to highlight ruby code
-* diff-lcs      # Required if you use the --diff switch
-* win32console  # Required by the --colour switch if you're on Windows
-* meta_project  # Required in order to make releases at RubyForge
-* heckle        # Required if you use the --heckle switch
+The following gems are also required:
 
+* rake              # Runs the build script
+* rcov              # Verifies that the code is 100% covered by specs
+* webgen (v 0.3.8)  # Generates the static HTML website 
+* RedCloth          # Required by webgen
+* rmagick           # Also required by webgen
+* syntax            # Required by our own custom webgen extension to highlight ruby code
+* diff-lcs          # Required if you use the --diff switch
+* win32console      # Required by the --colour switch if you're on Windows
+* meta_project      # Required in order to make releases at RubyForge
+* heckle            # Required if you use the --heckle switch
+
+Make sure you install webgen version 0.3.8; later versions will break the build.        
+
 Note that RSpec itself - once built - doesn't have any dependencies outside the Ruby core 
 and stdlib - with a few exceptions:


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-28 01:11

Message:
Just to let you know, you should close this because Aslak's
questions were answered.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-24 19:44

Message:
Aslak was right - neither rmagick, imagemagick,
graphicsmagick, nor the rb-rmagick port was needed, so I"ve
removed them from the documentation.  I've left in the note
about webgen 0.3.8, though. 

Not sure why I thought this was needed - I was pretty sure
that I saw some error message about rmagick needed in the
build.  Maybe this was only for the newer webgen gem.

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

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

Message:
applied to trunk and 0.9-dev (as of rev 1654)

Leaving this open though until Aslak's question gets answered. This is why we need to keep patches separate. Oops.

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

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

Message:
I just uninstalled RMagick and rake webgen still runs fine (on my mac). You must be doing something wrong.

Why do you think it's needed?

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

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

From noreply at rubyforge.org  Wed Mar 28 07:11:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 28 Mar 2007 07:11:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9605 ] Patch for ER 9472,
	shared behaviour
Message-ID: <20070328111116.E9702524096F@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Patch for ER 9472, shared behaviour

Initial Comment:
I chose behaves_as, as the inclusion method.
I don't like the use of the global, behavior_runner, in Behavior to find shared behaviors. Putting the collection on Spec::Runner seemed just as bad.

Had to move some methods on module Spec::DSL::BehaviourEval::ModuleMethods from private to protected to faciliate copying things from one EvalModule to another.

There are many combinations of include, setup/teardown, context_setup/context_teardown and inherit that are not covered in the shared_behavior spec. Let me know if you want more. Might be a good place for shared behaviors!

 -Bob

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

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

Message:
I haven't had time to look into this in detail, but it looks interesting. Right now we're trying to get 0.9 out the door, and we're reluctant to add new features before 0.9 is released.

Let's revisit this post 0.9

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 08:12

Message:
Missed the checkbox. Sorry.

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 08:11

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-27 00:16

Message:
File please.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-03-27 00:15

Message:
Hi Bob - I'll take a look at this tomorrow. Thanks.

FYI - the problem you had running pre_commit was due to something we were trying to fix w/ 1.8.6. I reverted the spectask and you can run pre_commit now.

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

Comment By: Bob Cotton (bcotton)
Date: 2007-03-27 00:10

Message:
One more thing, rcov is at 100%, but I can't get pre_commit
to run. It either runs out of memory, or the stack is too deep.

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

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

From noreply at rubyforge.org  Wed Mar 28 15:44:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 28 Mar 2007 15:44:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9649 ] Parital mocks don't work if
	object loaded from fixture, and referenced via association
Message-ID: <20070328194412.BEFC95240B70@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Hoffman (hoffman_c)
Assigned to: Nobody (None)
Summary: Parital mocks don't work if object loaded from fixture, and referenced via association

Initial Comment:
Hello,
  The following code will not function properly:

spec/fixtures/pages.yml
----------
first: 
  id: 1
  type: LockedPage
  name: the first default page

spec/fixtures/questions.yml
----------
first: 
  id: 1
  type: LockedQuestion
  name: the first default question
  container_id: 1
  container_type: LockedPage

spec/models/locked_question_spec.rb
----------
context "LockedQuestion#document_session, being linked to a Page that has a Document Session" do
  fixtures :questions, :pages

  setup do
    @question = questions(:first)
    @page = pages(:first)
    @page.stub!(:document_session).and_return("the document session")
    @question.page.should == @page #=> true
  end

  specify "should return the Page's Document Session" do
    @question.document_session.should == "the document session" #=> fails with 'undefined method'
  end
end

I would kludge something together by just assigning an unlocked page to the question, but the "Locked" that prefaces these models is a subclass that denies any modifications.

Thanks for your help.

-Chris


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

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

From noreply at rubyforge.org  Wed Mar 28 23:26:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 28 Mar 2007 23:26:22 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9659 ] Re: Clarification to Readme -
	reverting to old version
Message-ID: <20070329032623.40E5D5240B8F@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Re: Clarification to Readme - reverting to old version

Initial Comment:
The last patch (Clarification to Readme file in spec/, patch #9511) got rejected, yet applied to trunk.  Here is the patch of how the readme should look.

patch #9511 - http://rubyforge.org/tracker/index.php?func=detail&aid=9511&group_id=797&atid=3151


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

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

From noreply at rubyforge.org  Thu Mar 29 00:04:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 29 Mar 2007 00:04:37 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9659 ] Re: Clarification to Readme -
	reverting to old version
Message-ID: <20070329040437.98B1C5240BA7@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Re: Clarification to Readme - reverting to old version

Initial Comment:
The last patch (Clarification to Readme file in spec/, patch #9511) got rejected, yet applied to trunk.  Here is the patch of how the readme should look.

patch #9511 - http://rubyforge.org/tracker/index.php?func=detail&aid=9511&group_id=797&atid=3151


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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-29 04:04

Message:
Sorry - I forgot to remove rmagick from the listing... use
the newer readme 

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

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

From noreply at rubyforge.org  Thu Mar 29 10:16:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 29 Mar 2007 10:16:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9674 ] spec_translate incorrectly
	handling shoud_match, when regexp in a var, in a block
Message-ID: <20070329141605.50F045240B9A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: spec_translate incorrectly handling shoud_match, when regexp in a var, in a block

Initial Comment:
Attached is a patch to spec_translate.rb

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

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

From noreply at rubyforge.org  Thu Mar 29 11:22:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 29 Mar 2007 11:22:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9678 ] Custom runner command line
	switch, and multi-threaded runner
Message-ID: <20070329152212.6D9F65240BB6@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Custom runner command line switch, and multi-threaded runner

Initial Comment:
Here's a better patch, with the multi-threaded runner in the examples dir

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

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

From noreply at rubyforge.org  Thu Mar 29 11:26:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 29 Mar 2007 11:26:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9674 ] spec_translate incorrectly
	handling shoud_match, when regexp in a var, in a block
Message-ID: <20070329152629.1FBD85240BAF@rubyforge.org>

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

Category: None
Group: None
Status: Open
>Resolution: Accepted
Priority: 3
Submitted By: Bob Cotton (bcotton)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: spec_translate incorrectly handling shoud_match, when regexp in a var, in a block

Initial Comment:
Attached is a patch to spec_translate.rb

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

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

From noreply at rubyforge.org  Thu Mar 29 11:56:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 29 Mar 2007 11:56:33 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9674 ] spec_translate incorrectly
	handling shoud_match, when regexp in a var, in a block
Message-ID: <20070329155633.C9E9D5240B98@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: spec_translate incorrectly handling shoud_match, when regexp in a var, in a block

Initial Comment:
Attached is a patch to spec_translate.rb

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

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

Message:
fixed in /branches/0.9-dev#1665

thanks for the failing spec!

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

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

From noreply at rubyforge.org  Fri Mar 30 01:26:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 30 Mar 2007 01:26:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9607 ] Rails 2.0 render issue
Message-ID: <20070330052601.8D1825240C2E@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Zach Inglis (zachinglis)
Assigned to: Nobody (None)
Summary: Rails 2.0 render issue

Initial Comment:
rspec gives the code:
render 'controller/action' which is not allowed in Rails 2.0 and will give you an error. It should render:
render :controller => "controller", :action => "action"

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

>Comment By: Zach Inglis (zachinglis)
Date: 2007-03-30 00:26

Message:
Anyone?

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

Comment By: Zach Inglis (zachinglis)
Date: 2007-03-27 02:25

Message:
err, actually the substitute code gives me an error.

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

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

From noreply at rubyforge.org  Fri Mar 30 01:31:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 30 Mar 2007 01:31:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9607 ] Rails 2.0 render issue
Message-ID: <20070330053119.411715240C3F@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Zach Inglis (zachinglis)
Assigned to: Nobody (None)
Summary: Rails 2.0 render issue

Initial Comment:
rspec gives the code:
render 'controller/action' which is not allowed in Rails 2.0 and will give you an error. It should render:
render :controller => "controller", :action => "action"

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-30 05:31

Message:
Is this in one of the generators?

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

Comment By: Zach Inglis (zachinglis)
Date: 2007-03-30 05:26

Message:
Anyone?

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

Comment By: Zach Inglis (zachinglis)
Date: 2007-03-27 07:25

Message:
err, actually the substitute code gives me an error.

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

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

From noreply at rubyforge.org  Fri Mar 30 02:01:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 30 Mar 2007 02:01:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-9607 ] Rails 2.0 render issue
Message-ID: <20070330060115.BEFC352409B7@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Zach Inglis (zachinglis)
Assigned to: Nobody (None)
Summary: Rails 2.0 render issue

Initial Comment:
rspec gives the code:
render 'controller/action' which is not allowed in Rails 2.0 and will give you an error. It should render:
render :controller => "controller", :action => "action"

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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-30 02:01

Message:
Is Rails 2.0 the same as http://svn.rubyonrails.org/rails/trunk/ ?

If not, what's the svn URL?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-30 01:31

Message:
Is this in one of the generators?

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

Comment By: Zach Inglis (zachinglis)
Date: 2007-03-30 01:26

Message:
Anyone?

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

Comment By: Zach Inglis (zachinglis)
Date: 2007-03-27 03:25

Message:
err, actually the substitute code gives me an error.

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

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

From mailing_lists at railsnewbie.com  Fri Mar 30 03:23:58 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 30 Mar 2007 03:23:58 -0400
Subject: [rspec-devel] rspec & webgen
Message-ID: <2709EB86-F0AB-4787-9933-A7812F0C6C2F@railsnewbie.com>


Would anyone mind if I updated the docs to use webgen 0.4.2?

By the way, I love that you have Ali G on your site.

Scott


From aslak.hellesoy at gmail.com  Fri Mar 30 04:27:02 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 30 Mar 2007 10:27:02 +0200
Subject: [rspec-devel] rspec & webgen
In-Reply-To: <2709EB86-F0AB-4787-9933-A7812F0C6C2F@railsnewbie.com>
References: <2709EB86-F0AB-4787-9933-A7812F0C6C2F@railsnewbie.com>
Message-ID: <8d961d900703300127r4ffa7c26ga62c3a893c27a1e5@mail.gmail.com>

On 3/30/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> Would anyone mind if I updated the docs to use webgen 0.4.2?
>

That would be great! Please patch against the HEAD of branches/0.9-dev

> By the way, I love that you have Ali G on your site.
>

Respec,
Aslak

> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Fri Mar 30 10:19:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 30 Mar 2007 10:19:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9700 ] Make Spec::DSL::Example#name
	public / Add a --timeout switch
Message-ID: <20070330141919.B79575240C4B@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Make Spec::DSL::Example#name public / Add a --timeout switch

Initial Comment:
(Possibly name it #description)

I need it for a timeout monkey patch we're using at my project:

# Patch RSpec so it fails on specs taking longer than x seconds (some watir specs hang indefinitely)
class Spec::DSL::Example
  alias old_run run
  def run(reporter, setup_block, teardown_block, dry_run, execution_context)
    begin
      timeout($RSPEC_TIMEOUT || 50) do
        old_run(reporter, setup_block, teardown_block, dry_run, execution_context)
      end
    rescue Timeout::Error => e
      reporter.example_finished(name, e, 'timeout') if reporter
    end
  end
end

Speaking of which - perhaps we should add this to core and add a --timeout switch?


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

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

From noreply at rubyforge.org  Sat Mar 31 18:39:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 31 Mar 2007 18:39:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9700 ] Make Spec::DSL::Example#name
	public / Add a --timeout switch
Message-ID: <20070331223910.2A3785240A2D@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Make Spec::DSL::Example#name public / Add a --timeout switch

Initial Comment:
(Possibly name it #description)

I need it for a timeout monkey patch we're using at my project:

# Patch RSpec so it fails on specs taking longer than x seconds (some watir specs hang indefinitely)
class Spec::DSL::Example
  alias old_run run
  def run(reporter, setup_block, teardown_block, dry_run, execution_context)
    begin
      timeout($RSPEC_TIMEOUT || 50) do
        old_run(reporter, setup_block, teardown_block, dry_run, execution_context)
      end
    rescue Timeout::Error => e
      reporter.example_finished(name, e, 'timeout') if reporter
    end
  end
end

Speaking of which - perhaps we should add this to core and add a --timeout switch?


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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-31 18:39

Message:
Added in branches/0.9-dev#1669

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

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

From noreply at rubyforge.org  Sat Mar 31 18:41:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 31 Mar 2007 18:41:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9659 ] Re: Clarification to Readme -
	reverting to old version
Message-ID: <20070331224121.2A87C5240A2D@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Re: Clarification to Readme - reverting to old version

Initial Comment:
The last patch (Clarification to Readme file in spec/, patch #9511) got rejected, yet applied to trunk.  Here is the patch of how the readme should look.

patch #9511 - http://rubyforge.org/tracker/index.php?func=detail&aid=9511&group_id=797&atid=3151


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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-31 18:41

Message:
This was already ok on branches/0.9-dev

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-03-29 00:04

Message:
Sorry - I forgot to remove rmagick from the listing... use
the newer readme 

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

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

From noreply at rubyforge.org  Sat Mar 31 18:41:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 31 Mar 2007 18:41:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-9700 ] Make Spec::DSL::Example#name
	public / Add a --timeout switch
Message-ID: <20070331224135.4E49E5240A2D@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Aslak Helles?y (aslak_hellesoy)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Make Spec::DSL::Example#name public / Add a --timeout switch

Initial Comment:
(Possibly name it #description)

I need it for a timeout monkey patch we're using at my project:

# Patch RSpec so it fails on specs taking longer than x seconds (some watir specs hang indefinitely)
class Spec::DSL::Example
  alias old_run run
  def run(reporter, setup_block, teardown_block, dry_run, execution_context)
    begin
      timeout($RSPEC_TIMEOUT || 50) do
        old_run(reporter, setup_block, teardown_block, dry_run, execution_context)
      end
    rescue Timeout::Error => e
      reporter.example_finished(name, e, 'timeout') if reporter
    end
  end
end

Speaking of which - perhaps we should add this to core and add a --timeout switch?


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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-03-31 18:39

Message:
Added in branches/0.9-dev#1669

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

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

From brian.takita at gmail.com  Sun Mar 25 19:50:56 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 25 Mar 2007 16:50:56 -0700
Subject: [rspec-devel] Code Coverage Failures
In-Reply-To: <8d961d900703251642o5342fcc1v903b90164cb1c115@mail.gmail.com>
References: <1d7ddd110703251512l49194898j8455db8a4289795a@mail.gmail.com>
	<8d961d900703251642o5342fcc1v903b90164cb1c115@mail.gmail.com>
Message-ID: <1d7ddd110703251650x22df1126v24ec201c33d33560@mail.gmail.com>

On 3/25/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
> On 3/26/07, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > I tried running rake for rspec and got a rcov error.
> >
> > Coverage: 89.9% (threshold: 100.0%)
> > rake aborted!
> > Coverage must be at least 100.0% but was 89.9%
> >
>
> If you look at the generated rcov report, what's not covered? Could
> you tar it up and send it to the list for inspection?




> In spectask.rb I am also using system("ruby #{rest_of_cmd)") instead of
> > ruby(cmd) because Rake's ruby command does not seem to print out to
> stderr.
> >
> > Here is my patch. Is anybody else getting this issue? I'm running on
> Ubuntu
> > and Ruby 1.8.6.
> >
>
> Just go ahead and commit it. Make sure you do it on the 0.9-dev
> branch, which acts as trunk for the moment.


I will.

> Thanks,
> > Brian
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070325/a12aacfd/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: coverage.tar.gz
Type: application/x-gzip
Size: 97054 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20070325/a12aacfd/attachment-0001.gz