From noreply at rubyforge.org  Wed Aug  1 07:27:38 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  1 Aug 2007 07:27:38 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12719 ] rspec_on_rails should not
	include pagination helper
Message-ID: <20070801112738.EDA9C5240990@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Matthijs Langenberg (mlangenberg)
>Assigned to: David Chelimsky (dchelimsky)
Summary: rspec_on_rails should not include pagination helper

Initial Comment:
Pagination is being removed from Rails and is no longer being maintained. Therefor rspec_on_rails shouldn't try to include it. Currently it raises a "NameError: uninitialized constant ActionView::Helpers::PaginationHelper".

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-01 11:27

Message:
Applied to trunk r2189.

I modified it so PaginationHelper is only included if it is found (rather than just commenting it), and also modified the spec so it expects PaginationHelper for anything <= 1.2.3.

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

Comment By: Carl Porth (badcarl)
Date: 2007-07-31 19:56

Message:
Why not use the same kind of functionality that ActionView::Base uses to load the helpers?  In rails/actionpack/lib/action_view/base.rb there is the method:

def self.load_helpers #:nodoc:
  Dir.entries("#{File.dirname(__FILE__)}/helpers").sort.each do |file|
    next unless file =~ /^([a-z][a-z_]*_helper).rb$/
    require "action_view/helpers/#{$1}"
    helper_module_name = $1.camelize
    if Helpers.const_defined?(helper_module_name)
      include Helpers.const_get(helper_module_name)
    end
  end
end



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-31 18:08

Message:
Please.

Thanks.

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

Comment By: Matthijs Langenberg (mlangenberg)
Date: 2007-07-31 18:05

Message:
Oops, just overlooked the fact that the RSpec trunk is going
to be used with rails versions other than the current edge.
If you want I'll try to search for a solution, because I
need it to work with edge rails anyway.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-31 16:08

Message:
We'll need it to remain included for Rails 1.2.1-1.2.3.

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

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

From noreply at rubyforge.org  Wed Aug  1 10:15:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  1 Aug 2007 10:15:56 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12719 ] rspec_on_rails should not
	include pagination helper
Message-ID: <20070801141556.3CF125240B2A@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Matthijs Langenberg (mlangenberg)
Assigned to: David Chelimsky (dchelimsky)
Summary: rspec_on_rails should not include pagination helper

Initial Comment:
Pagination is being removed from Rails and is no longer being maintained. Therefor rspec_on_rails shouldn't try to include it. Currently it raises a "NameError: uninitialized constant ActionView::Helpers::PaginationHelper".

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

>Comment By: Matthijs Langenberg (mlangenberg)
Date: 2007-08-01 16:15

Message:
That's just great David, I spent a hour last evening trying
to find a good way to let the examples behave different
based on the Rails version. I was already trying to stub
Rails::VERSION, and trying to check on
File.directory?("#{RAILS_ROOT}/vendor/rails"), but I just
let it go because it didn't make any sense in the end.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-01 13:27

Message:
Applied to trunk r2189.

I modified it so PaginationHelper is only included if it is found (rather than just commenting it), and also modified the spec so it expects PaginationHelper for anything <= 1.2.3.

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

Comment By: Carl Porth (badcarl)
Date: 2007-07-31 21:56

Message:
Why not use the same kind of functionality that ActionView::Base uses to load the helpers?  In rails/actionpack/lib/action_view/base.rb there is the method:

def self.load_helpers #:nodoc:
  Dir.entries("#{File.dirname(__FILE__)}/helpers").sort.each do |file|
    next unless file =~ /^([a-z][a-z_]*_helper).rb$/
    require "action_view/helpers/#{$1}"
    helper_module_name = $1.camelize
    if Helpers.const_defined?(helper_module_name)
      include Helpers.const_get(helper_module_name)
    end
  end
end



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-31 20:08

Message:
Please.

Thanks.

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

Comment By: Matthijs Langenberg (mlangenberg)
Date: 2007-07-31 20:05

Message:
Oops, just overlooked the fact that the RSpec trunk is going
to be used with rails versions other than the current edge.
If you want I'll try to search for a solution, because I
need it to work with edge rails anyway.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-31 18:08

Message:
We'll need it to remain included for Rails 1.2.1-1.2.3.

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

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

From noreply at rubyforge.org  Wed Aug  1 21:29:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  1 Aug 2007 21:29:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12760 ] Autotest regexp no longer
	matches new pretty output
Message-ID: <20070802012909.CFFC25240C9A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: Autotest regexp no longer matches new pretty output

Initial Comment:
Aslak changed lib/spec/matchers/operator_matcher.rb in July to be nice and pretty, but lib/autotest/rspec.rb hasn't been updated to match it, so the output from autotest is now just blank lines when a should == expectation fails.

describe "it" do
  it "doesn't work" do
    1.should == 2
  end
end

Windows XP SP2 under cygwin
ruby 1.8.6 [i386-cygwin]
rspec r2189

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

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

From noreply at rubyforge.org  Thu Aug  2 06:11:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  2 Aug 2007 06:11:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12774 ] Add shebang to bin/spec so
	that Edge may be run for non-Rails projects
Message-ID: <20070802101129.5A79CA97000B@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Klishin (michaelklishin)
Assigned to: Nobody (None)
Summary: Add shebang to bin/spec so that Edge may be run for non-Rails projects

Initial Comment:
I found out that bin/spec bootstrap script is missing shebang so Edge can't be used for pure Ruby projects.

Here is the patch that adds shebang so you only have to link /usr/bin/spec or /opt/local/bin or whatever to your bin/spec in RSpec repository working copy to be running Edge.

We may add this information to documentation section "Living on the edge". What is the best way to submit it? I'm ready to contribute some information on how jump from gem to the edge.

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

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

From noreply at rubyforge.org  Thu Aug  2 06:13:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  2 Aug 2007 06:13:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks
Message-ID: <20070802101358.007B6A97000B@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Anderson (jchris)
Assigned to: Nobody (None)
Summary: :nil_object option for mocks

Initial Comment:
A nil object returns nil (rather than itself) for any methods which aren't stubbed.

This is useful if you are going to send something into views, and don't care how it renders, but don't want errors.

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

Comment By: Michael Klishin (michaelklishin)
Date: 2007-08-02 10:13

Message:
Hey, isn't this one already applied? Should we cleanup patches and bugs a bit?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-30 18:43

Message:
Why don't you go ahead and float this on the lists. I like the idea in general, though there's no syntax for it that is standing out for me at the moment.

Cheers,
David

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

Comment By: Chris Anderson (jchris)
Date: 2007-01-30 17:09

Message:
I've been using nil objects as an implementation in Ruby of the null object 
pattern for a while now. Both approaches have their uses, depending on the 
client code.

You're right, the RSpec API for the nil object could have a more transparent 
usage that reflects its status as a variant on the null object pattern. Maybe as 
an alternative value for :null_object. My first thought would be 

mock('returns nil for all unstubbed methods', :null_object => :returns_nil)

This keeps the surface area of mocks down, and presents the "nil object" as a 
special case of null object.

Thoughts? Should I bring this up on the mailing list? Once we figure out the 
API, I'll be happy to provide a patch.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-30 12:18

Message:
The term "null object" refers to a design pattern (google it).
There is no "nil object" design pattern.

I'm a little concerned that the presence of :null_object and :nil_object may be confusing for users since they sound so similar. One is the implementation of a design pattern, the other is ehm, something else.

Can we come up with a less confusing name?


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

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

From noreply at rubyforge.org  Thu Aug  2 06:49:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  2 Aug 2007 06:49:44 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks
Message-ID: <20070802104944.DC95CA970007@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Chris Anderson (jchris)
Assigned to: Nobody (None)
Summary: :nil_object option for mocks

Initial Comment:
A nil object returns nil (rather than itself) for any methods which aren't stubbed.

This is useful if you are going to send something into views, and don't care how it renders, but don't want errors.

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

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

Message:
This is not implemented. We have :null_object => true, which causes the mock to return itself for any unexpected calls. This request is for a way to get it to return nil.

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

Comment By: Michael Klishin (michaelklishin)
Date: 2007-08-02 10:13

Message:
Hey, isn't this one already applied? Should we cleanup patches and bugs a bit?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-30 18:43

Message:
Why don't you go ahead and float this on the lists. I like the idea in general, though there's no syntax for it that is standing out for me at the moment.

Cheers,
David

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

Comment By: Chris Anderson (jchris)
Date: 2007-01-30 17:09

Message:
I've been using nil objects as an implementation in Ruby of the null object 
pattern for a while now. Both approaches have their uses, depending on the 
client code.

You're right, the RSpec API for the nil object could have a more transparent 
usage that reflects its status as a variant on the null object pattern. Maybe as 
an alternative value for :null_object. My first thought would be 

mock('returns nil for all unstubbed methods', :null_object => :returns_nil)

This keeps the surface area of mocks down, and presents the "nil object" as a 
special case of null object.

Thoughts? Should I bring this up on the mailing list? Once we figure out the 
API, I'll be happy to provide a patch.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-30 12:18

Message:
The term "null object" refers to a design pattern (google it).
There is no "nil object" design pattern.

I'm a little concerned that the presence of :null_object and :nil_object may be confusing for users since they sound so similar. One is the implementation of a design pattern, the other is ehm, something else.

Can we come up with a less confusing name?


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

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

From noreply at rubyforge.org  Thu Aug  2 07:03:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  2 Aug 2007 07:03:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12774 ] Add shebang to bin/spec so
	that Edge may be run for non-Rails projects
Message-ID: <20070802110320.9F3995240B3F@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Michael Klishin (michaelklishin)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Add shebang to bin/spec so that Edge may be run for non-Rails projects

Initial Comment:
I found out that bin/spec bootstrap script is missing shebang so Edge can't be used for pure Ruby projects.

Here is the patch that adds shebang so you only have to link /usr/bin/spec or /opt/local/bin or whatever to your bin/spec in RSpec repository working copy to be running Edge.

We may add this information to documentation section "Living on the edge". What is the best way to submit it? I'm ready to contribute some information on how jump from gem to the edge.

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

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

Message:
First, I don't see a patch.

Second, I don't recall the specific problem, but we originally had the shebang in there and removed it because there was a conflict, I believe, on windows systems. When you install the gem on *nix systems it gets added to the spec command.

So simply sticking it in the file would not be acceptable.

I'm closing this, but if you have an alternative idea as to how to approach this, feel free to reopen it.

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

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

From undees at gmail.com  Thu Aug  2 13:13:12 2007
From: undees at gmail.com (Ian Dees)
Date: Thu, 2 Aug 2007 10:13:12 -0700
Subject: [rspec-devel] merging rbehave into rspec
Message-ID: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>

I'd be interested in helping with the RSpec + RBehave effort, too.
What do I do?

--Ian

From martin.emde at gmail.com  Thu Aug  2 17:43:46 2007
From: martin.emde at gmail.com (Martin Emde)
Date: Thu, 2 Aug 2007 15:43:46 -0600
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
Message-ID: <145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>

I as well.

On 8/2/07, Ian Dees <undees at gmail.com> wrote:
>
> I'd be interested in helping with the RSpec + RBehave effort, too.
> What do I do?
>
> --Ian
> _______________________________________________
> 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/20070802/de427612/attachment.html 

From mailing_lists at railsnewbie.com  Thu Aug  2 17:57:46 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Thu, 2 Aug 2007 17:57:46 -0400
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
Message-ID: <FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>


There seems to be quite a few of us who want to help.  What is the  
state of this project?  Is this being worked on in the Rbehave  
repos?  Maybe the RSpec admins could create a branch in the rspec  
repos to facilitate this merging.

Scott


On Aug 2, 2007, at 5:43 PM, Martin Emde wrote:

> I as well.
>
> On 8/2/07, Ian Dees <undees at gmail.com> wrote: I'd be interested in  
> helping with the RSpec + RBehave effort, too.
> What do I do?
>
> --Ian
> _______________________________________________
> 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 yrashk at gmail.com  Thu Aug  2 17:58:51 2007
From: yrashk at gmail.com (Yurii Rashkovskii)
Date: Fri, 3 Aug 2007 00:58:51 +0300
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
Message-ID: <914754B3-F239-4F8D-A282-FC9FCBD91A40@gmail.com>

I've contacted Dan about a day ago, though got no response. So I'm  
still continuing working on my own way to integrate this stuff.

On Aug 3, 2007, at 12:57 AM, Scott Taylor wrote:

>
> There seems to be quite a few of us who want to help.  What is the
> state of this project?  Is this being worked on in the Rbehave
> repos?  Maybe the RSpec admins could create a branch in the rspec
> repos to facilitate this merging.
>
> Scott
>
>
>

From michael.s.klishin at gmail.com  Thu Aug  2 19:18:11 2007
From: michael.s.klishin at gmail.com (Michael Klishin)
Date: Fri, 3 Aug 2007 03:18:11 +0400
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <914754B3-F239-4F8D-A282-FC9FCBD91A40@gmail.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
	<914754B3-F239-4F8D-A282-FC9FCBD91A40@gmail.com>
Message-ID: <709de1d10708021618w5e38708as72772788eb407703@mail.gmail.com>

I think we should review it to get the idea whether people like you
way or not. Can you make your sources available no matter what's the
state of integration?

It would be cool not to start from scratch.

On 03/08/07, Yurii Rashkovskii <yrashk at gmail.com> wrote:
> I've contacted Dan about a day ago, though got no response. So I'm
> still continuing working on my own way to integrate this stuff.

-- 
MK

From dchelimsky at gmail.com  Thu Aug  2 23:00:36 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 2 Aug 2007 22:00:36 -0500
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
Message-ID: <57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>

On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> There seems to be quite a few of us who want to help.  What is the
> state of this project?  Is this being worked on in the Rbehave
> repos?  Maybe the RSpec admins could create a branch in the rspec
> repos to facilitate this merging.

Thanks to all for your interest. I need to talk to Aslak and Dan about
how we're going to do this, so please hang tight.

Cheers,
David

From mailing_lists at railsnewbie.com  Fri Aug  3 00:41:47 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 3 Aug 2007 00:41:47 -0400
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
	<57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>
Message-ID: <DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>



On Aug 2, 2007, at 11:00 PM, David Chelimsky wrote:

> On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> There seems to be quite a few of us who want to help.  What is the
>> state of this project?  Is this being worked on in the Rbehave
>> repos?  Maybe the RSpec admins could create a branch in the rspec
>> repos to facilitate this merging.
>
> Thanks to all for your interest. I need to talk to Aslak and Dan about
> how we're going to do this, so please hang tight.

Thanks David.  I guess I'm still a little unsure whether the whole  
code base will be merged in to RSpec, or whether it will stay  
separate but the World modules will get mixed into RSpec somehow or  
another.

I guess we will wait a few days to hear the news.

Best,

Scott

>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dan at tastapod.com  Fri Aug  3 07:43:49 2007
From: dan at tastapod.com (Dan North)
Date: Fri, 03 Aug 2007 12:43:49 +0100
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>	<57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>
	<DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>
Message-ID: <46B314F5.7030406@tastapod.com>

Hi folks.

Thought I'd post a quick update due to the level of interest. Thanks for 
all the offers of help. It's very encouraging!

So, to start with, I'm moving the rbehave codebase (as of 0.3.0) into 
rspec into a new module called Spec::Story. The code will largely be 
unchanged apart from repackaging (renaming modules and a few files) and 
migrating my mocha mocks to use rspec's internal mocking framework.

So far, I've got the code and the behaviours in there but the pre_commit 
behaviours are failing all over the place with what looks like a clash 
of mocking frameworks. (It looks like rspec doesn't like to mix mocking 
frameworks in the same run, which makes sense.) I don't want to commit a 
broken build, although I hadn't actually thought of doing this 
integration work on a branch. (I guess I thought it would be a pretty 
trivial exercise.)

If I'm still struggling in a few days, I'll probably commit to a branch, 
but in the meantime I would like to use this list to ask dumb questions 
- mostly about the rspec build :)

/(First dumb question: how do I only run the behaviours for a particular 
file or set of files using rake?)
/
As soon as I have a working build - and David gives me the go-ahead - 
I'll check in and then we can scope out the work to get proper 
story-level Rails integration.

Thanks again for the support,
Dan


Scott Taylor wrote:
> On Aug 2, 2007, at 11:00 PM, David Chelimsky wrote:
>
>   
>> On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>     
>>> There seems to be quite a few of us who want to help.  What is the
>>> state of this project?  Is this being worked on in the Rbehave
>>> repos?  Maybe the RSpec admins could create a branch in the rspec
>>> repos to facilitate this merging.
>>>       
>> Thanks to all for your interest. I need to talk to Aslak and Dan about
>> how we're going to do this, so please hang tight.
>>     
>
> Thanks David.  I guess I'm still a little unsure whether the whole  
> code base will be merged in to RSpec, or whether it will stay  
> separate but the World modules will get mixed into RSpec somehow or  
> another.
>
> I guess we will wait a few days to hear the news.
>
> Best,
>
> Scott
>
>   
>> Cheers,
>> 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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070803/b2d67fc7/attachment.html 

From brian.takita at gmail.com  Fri Aug  3 13:37:02 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 3 Aug 2007 10:37:02 -0700
Subject: [rspec-devel] Behaviour Refactoring under way
Message-ID: <1d7ddd110708031037v53724959yc8d784462f268a6c@mail.gmail.com>

Hello, Just to let you all know, Chad Woolley and I are starting the
Behaviour refactoring.

We made a branch at:
svn+ssh://rubyforge.org/var/svn/rspec/branches/20070803_behaviour_refactoring

From brian.takita at gmail.com  Fri Aug  3 22:18:03 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 3 Aug 2007 19:18:03 -0700
Subject: [rspec-devel] Behaviour Refactoring under way
In-Reply-To: <1d7ddd110708031037v53724959yc8d784462f268a6c@mail.gmail.com>
References: <1d7ddd110708031037v53724959yc8d784462f268a6c@mail.gmail.com>
Message-ID: <1d7ddd110708031918g459c9d92l65a91c1dd31b7cfd@mail.gmail.com>

I messed up and started a new branch.
svn+ssh://rubyforge.org/var/svn/rspec/branches/20070804_behaviour_refactoring

On 8/3/07, Brian Takita <brian.takita at gmail.com> wrote:
> Hello, Just to let you all know, Chad Woolley and I are starting the
> Behaviour refactoring.
>
> We made a branch at:
> svn+ssh://rubyforge.org/var/svn/rspec/branches/20070803_behaviour_refactoring
>

From noreply at rubyforge.org  Sat Aug  4 05:29:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  4 Aug 2007 05:29:31 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12694 ] DrbCommandLine is very slow to
	start the DRb service
Message-ID: <20070804092932.133EEA970003@rubyforge.org>

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

Category: Autotest
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: DrbCommandLine is very slow to start the DRb service

Initial Comment:
If we explicitly put in the port when calling start_service, it becomes MUCH faster.

e.g.
DRb.start_service "druby://localhost:8990"

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

>Comment By: Brian Takita (btakita)
Date: 2007-08-04 02:29

Message:
I fixed this issue by defining 0.0.0.0 in my /etc/hosts file.

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

Comment By: Brian Takita (btakita)
Date: 2007-07-30 13:03

Message:
It seems like it is an issue with creating a socket. I have
this issue with both of my Ubuntu machines, so I believe
that this has to do with the default Ubuntu configuration.

I've seen some problems relating to /etc/hosts, but I have
not figured it out yet.

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

Comment By: Brian Takita (btakita)
Date: 2007-07-30 10:04

Message:
I'm using Ruby 1.8.6 on Ubunutu 7.0.4

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

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

From noreply at rubyforge.org  Sat Aug  4 09:10:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  4 Aug 2007 09:10:17 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12817 ] Cannot include same shared
	behaviour when required with absolute paths.
Message-ID: <20070804131017.C69DEA97000B@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ian Leitch (idl)
Assigned to: Nobody (None)
Summary: Cannot include same shared behaviour when required with absolute paths.

Initial Comment:
When trying to require a file containing a shared behavior with an absolute path different from the first require, RSpec raises an ArgumentError.

Due to the fact that we run 'rake spec' from the base of our Rails apps, all require statements in our specs are prefixed with File.dirname(__FILE__), e.g.:

require File.dirname(__FILE__) + '/../../spec_helper'
require File.dirname(__FILE__) + '/../email_template_view_helper'

Here email_template_view_helper contains a shared helper, yet when included by different specs IN DIFFERENT DIRECTORIES, the ArgumentError is raised.

The attached patch fixes this issue.



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

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

From noreply at rubyforge.org  Sat Aug  4 09:29:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  4 Aug 2007 09:29:07 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12817 ] Cannot include same shared
	behaviour when required with absolute paths.
Message-ID: <20070804132907.2FF27A97000F@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Ian Leitch (idl)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Cannot include same shared behaviour when required with absolute paths.

Initial Comment:
When trying to require a file containing a shared behavior with an absolute path different from the first require, RSpec raises an ArgumentError.

Due to the fact that we run 'rake spec' from the base of our Rails apps, all require statements in our specs are prefixed with File.dirname(__FILE__), e.g.:

require File.dirname(__FILE__) + '/../../spec_helper'
require File.dirname(__FILE__) + '/../email_template_view_helper'

Here email_template_view_helper contains a shared helper, yet when included by different specs IN DIFFERENT DIRECTORIES, the ArgumentError is raised.

The attached patch fixes this issue.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-04 13:29

Message:
Nice - I did modify it a bit because this patch would cause behaviours from different files with the same names to NOT raise an error (which we'd actually want):

/path/to/my/spec.rb
/path/to/another/spec.rb

I added an example expecting an error in that situation and it failed. Using File.expand_path instead of File.basename got it to pass along with the other examples.

Applied to r2240.

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

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

From noreply at rubyforge.org  Sat Aug  4 09:48:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  4 Aug 2007 09:48:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12701 ] Allow checking of content
	captured with content_for in view specs
Message-ID: <20070804134801.50021A97000F@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jens Kr?mer (jkraemer)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Allow checking of content captured with content_for in view specs

Initial Comment:
This patch extends ActionController::TestResponse with an accessor to get any content rendered inside a content_for block so it can easily be checked like the template's main content:

<% content_for :sidebar do %>
  <h2>The sidebar</h2>
<% end %>

it "should render the sidebar" do
  response[:sidebar].should have_tag('h2', 'The sidebar')
end



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-04 13:48

Message:
Nice patch.

Applied to r2242.

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

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

From noreply at rubyforge.org  Sat Aug  4 09:50:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  4 Aug 2007 09:50:43 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12701 ] Allow checking of content
	captured with content_for in view specs
Message-ID: <20070804135044.1F0C0A970006@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Jens Kr?mer (jkraemer)
Assigned to: David Chelimsky (dchelimsky)
Summary: Allow checking of content captured with content_for in view specs

Initial Comment:
This patch extends ActionController::TestResponse with an accessor to get any content rendered inside a content_for block so it can easily be checked like the template's main content:

<% content_for :sidebar do %>
  <h2>The sidebar</h2>
<% end %>

it "should render the sidebar" do
  response[:sidebar].should have_tag('h2', 'The sidebar')
end



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-04 13:50

Message:
Actually - the one thing missing from this is documentation. Wanna take a stab at it Jens?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-04 13:48

Message:
Nice patch.

Applied to r2242.

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

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

From pergesu at gmail.com  Sun Aug  5 03:27:44 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Sun, 5 Aug 2007 00:27:44 -0700
Subject: [rspec-devel] I think I'm missing something that spec:rcov needs
Message-ID: <810a540e0708050027n37949053re49bd0e2c61f8efd@mail.gmail.com>

I just set up a new OS X machine with everything I need to do rspec
and rails development.  However the spec:rcov task won't run.  I get
the following stack trace:

** Invoke spec:rcov (first_time)
** Invoke clobber_spec:rcov (first_time)
** Execute clobber_spec:rcov
rake aborted!
Don't know how to build task 'clobber_rcov'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1472:in `[]'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:369:in
`invoke_prerequisites'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1003:in `each'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1003:in `send'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1003:in `each'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:368:in
`invoke_prerequisites'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:361:in `invoke'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `synchronize'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in `invoke'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `each'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in `top_level'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in
`standard_exception_handling'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in `top_level'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:in `run'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in
`standard_exception_handling'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in `run'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/opt/local/bin/rake:16:in `load'
/opt/local/bin/rake:16

Here are the tasks it knows about:

rake clobber_spec:rcov  # Remove rcov products for spec:rcov
rake spec:clobber_rcov  # Remove rcov products for rcov
rake spec:rcov          # Run all specs with RCov / Run all specs in
spec directory with RCov (excluding plugin specs)

So apparently it's looking for a top-level clobber_spec task that
doesn't exist.  I added this to my rcov.rake as a quick fix:

desc "Clobber rcov"
task :clobber_rcov => [ "spec:clobber_rcov" ] do
end

I'm using rspec 1.0.5 and rcov 0.8.0.2.  Is there a plugin that I need
to install?  Also what's the difference between clobber_spec:rcov and
spec:clobber_rcov?

Pat

From noreply at rubyforge.org  Mon Aug  6 02:13:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 02:13:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070806061315.AD9785240D32@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
Summary: Allow stubs to yield consecutive values

Initial Comment:
Scott Taylor asked,

I have a mock of an instance of a class which descends from Array:

class ArrayDescendent < Array; end

#... in the specs...
@descendent = mock ArrayDescendent

How would I stub out ArrayDescendent#each, which is inherited from
Array, to return multiple values successively?  I could use
and_yield, but that is raising an arity error (the anonymous function/
block should expect only *one value at a time, but and_yield is
yielding both values once).  Should I be using a lambda expression here?




This patch provides the #and_yield_consecutively method for mocks and stubs.

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

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

From mailing_lists at railsnewbie.com  Mon Aug  6 02:16:27 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Mon, 6 Aug 2007 02:16:27 -0400
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
In-Reply-To: <20070806061315.AD9785240D32@rubyforge.org>
References: <20070806061315.AD9785240D32@rubyforge.org>
Message-ID: <54D9E6F5-0AE6-40E7-BC52-70175D260878@railsnewbie.com>


Pat Maddox, your my hero.

Scott


On Aug 6, 2007, at 2:13 AM, <noreply at rubyforge.org>   
<noreply at rubyforge.org> wrote:

> Patches item #12841, was opened at 2007-08-06 00:13
> You can respond by visiting:
> http://rubyforge.org/tracker/? 
> func=detail&atid=3151&aid=12841&group_id=797
>
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 3
> Submitted By: Pat Maddox (pergesu)
> Assigned to: Nobody (None)
> Summary: Allow stubs to yield consecutive values
>
> Initial Comment:
> Scott Taylor asked,
>
> I have a mock of an instance of a class which descends from Array:
>
> class ArrayDescendent < Array; end
>
> #... in the specs...
> @descendent = mock ArrayDescendent
>
> How would I stub out ArrayDescendent#each, which is inherited from
> Array, to return multiple values successively?  I could use
> and_yield, but that is raising an arity error (the anonymous function/
> block should expect only *one value at a time, but and_yield is
> yielding both values once).  Should I be using a lambda expression  
> here?
>
>
>
>
> This patch provides the #and_yield_consecutively method for mocks  
> and stubs.
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> http://rubyforge.org/tracker/? 
> func=detail&atid=3151&aid=12841&group_id=797
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From noreply at rubyforge.org  Mon Aug  6 02:31:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 02:31:31 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070806063132.186045240D32@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
Summary: Allow stubs to yield consecutive values

Initial Comment:
Scott Taylor asked,

I have a mock of an instance of a class which descends from Array:

class ArrayDescendent < Array; end

#... in the specs...
@descendent = mock ArrayDescendent

How would I stub out ArrayDescendent#each, which is inherited from
Array, to return multiple values successively?  I could use
and_yield, but that is raising an arity error (the anonymous function/
block should expect only *one value at a time, but and_yield is
yielding both values once).  Should I be using a lambda expression here?




This patch provides the #and_yield_consecutively method for mocks and stubs.

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

>Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 00:31

Message:
A little bit of multi-arity love.

it "should support yielding consecutive values to a *-arity
block" do
  yielded_values = []
 
@obj.stub!(:method_that_yields).and_yield_consecutively(["biscuits",
"and"], ["gravy", "is"], ["good", "eatin"])
  @obj.method_that_yields {|val1, val2| yielded_values <<
"#{val1} #{val2}" }
  yielded_values.should == [ "biscuits and", "gravy is",
"good eatin"]
  @obj.rspec_verify
end

Each group of yielded values is in an array.

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

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

From noreply at rubyforge.org  Mon Aug  6 02:40:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 02:40:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070806064015.A4DB35240D32@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
Summary: Allow stubs to yield consecutive values

Initial Comment:
Scott Taylor asked,

I have a mock of an instance of a class which descends from Array:

class ArrayDescendent < Array; end

#... in the specs...
@descendent = mock ArrayDescendent

How would I stub out ArrayDescendent#each, which is inherited from
Array, to return multiple values successively?  I could use
and_yield, but that is raising an arity error (the anonymous function/
block should expect only *one value at a time, but and_yield is
yielding both values once).  Should I be using a lambda expression here?




This patch provides the #and_yield_consecutively method for mocks and stubs.

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

>Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 00:40

Message:
I realized I should probably explain why this is necessary.

Yielded values represent the input values to an anonymous
function (block).  Since a function can take more than 1
argument, there's no way of knowing whether multiple values
are supposed to be passed in at once or returned
consecutively.  This gives us both options, without any
magic that might introduce arity errors.

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 00:31

Message:
A little bit of multi-arity love.

it "should support yielding consecutive values to a *-arity
block" do
  yielded_values = []
 
@obj.stub!(:method_that_yields).and_yield_consecutively(["biscuits",
"and"], ["gravy", "is"], ["good", "eatin"])
  @obj.method_that_yields {|val1, val2| yielded_values <<
"#{val1} #{val2}" }
  yielded_values.should == [ "biscuits and", "gravy is",
"good eatin"]
  @obj.rspec_verify
end

Each group of yielded values is in an array.

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

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

From noreply at rubyforge.org  Mon Aug  6 03:06:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 03:06:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070806070605.D09245240D35@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
Summary: Allow stubs to yield consecutive values

Initial Comment:
Scott Taylor asked,

I have a mock of an instance of a class which descends from Array:

class ArrayDescendent < Array; end

#... in the specs...
@descendent = mock ArrayDescendent

How would I stub out ArrayDescendent#each, which is inherited from
Array, to return multiple values successively?  I could use
and_yield, but that is raising an arity error (the anonymous function/
block should expect only *one value at a time, but and_yield is
yielding both values once).  Should I be using a lambda expression here?




This patch provides the #and_yield_consecutively method for mocks and stubs.

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

>Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 01:06

Message:
I'm not sure why I thought all? was the proper method to
use.  Just collect the return values and pass them back.

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 00:40

Message:
I realized I should probably explain why this is necessary.

Yielded values represent the input values to an anonymous
function (block).  Since a function can take more than 1
argument, there's no way of knowing whether multiple values
are supposed to be passed in at once or returned
consecutively.  This gives us both options, without any
magic that might introduce arity errors.

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 00:31

Message:
A little bit of multi-arity love.

it "should support yielding consecutive values to a *-arity
block" do
  yielded_values = []
 
@obj.stub!(:method_that_yields).and_yield_consecutively(["biscuits",
"and"], ["gravy", "is"], ["good", "eatin"])
  @obj.method_that_yields {|val1, val2| yielded_values <<
"#{val1} #{val2}" }
  yielded_values.should == [ "biscuits and", "gravy is",
"good eatin"]
  @obj.rspec_verify
end

Each group of yielded values is in an array.

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

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

From noreply at rubyforge.org  Mon Aug  6 07:04:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 07:04:56 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806110456.7CE685240A2A@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: Nobody (None)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

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

From noreply at rubyforge.org  Mon Aug  6 07:20:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 07:20:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806112029.67BB85240A2A@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: Nobody (None)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:20

Message:
Should this spec raise an error:

describe "NilClass"
  it "should have an instance which is equal to nil" do
    nil.should == nil
  end
end

or how about this (in the case that method_one returns nil):

describe "method_one" do
  it "should return the same value as method_two" do
    method_one.should == method_two
  end
end


It is in an interesting idea, although raising an error probably isn't.  Maybe a warning.  

Luckily for you (and all of us), this is easy enough to do in Ruby:

module Kernel
  alias_method :__old_should, :should

  def should(*args, &blk)
    if self.class == NilClass
      raise RuntimeError, "this is a nil!!"
    else
      __old_should(*args, &blk)
    end
  end
end

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

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

From noreply at rubyforge.org  Mon Aug  6 07:23:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 07:23:03 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806112304.0E0D65240A2A@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: Nobody (None)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:23

Message:
Oh - just to follow up.  Of course that code could go into your spec_helper file, so you wouldn't need to carry around a different version of rspec, or make your production environment dependent on RSpec.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:20

Message:
Should this spec raise an error:

describe "NilClass"
  it "should have an instance which is equal to nil" do
    nil.should == nil
  end
end

or how about this (in the case that method_one returns nil):

describe "method_one" do
  it "should return the same value as method_two" do
    method_one.should == method_two
  end
end


It is in an interesting idea, although raising an error probably isn't.  Maybe a warning.  

Luckily for you (and all of us), this is easy enough to do in Ruby:

module Kernel
  alias_method :__old_should, :should

  def should(*args, &blk)
    if self.class == NilClass
      raise RuntimeError, "this is a nil!!"
    else
      __old_should(*args, &blk)
    end
  end
end

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

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

From noreply at rubyforge.org  Mon Aug  6 07:28:23 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 07:28:23 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806112823.98DB55240A2A@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: Nobody (None)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

>Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 11:28

Message:
Scott - actually it was only :should_receive I was thinking about, not :should in 
general.  I think making :should work differently for nil would be a mistake, but 
I can still see an argument for :should_receive.  See where I'm coming from?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:23

Message:
Oh - just to follow up.  Of course that code could go into your spec_helper file, so you wouldn't need to carry around a different version of rspec, or make your production environment dependent on RSpec.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:20

Message:
Should this spec raise an error:

describe "NilClass"
  it "should have an instance which is equal to nil" do
    nil.should == nil
  end
end

or how about this (in the case that method_one returns nil):

describe "method_one" do
  it "should return the same value as method_two" do
    method_one.should == method_two
  end
end


It is in an interesting idea, although raising an error probably isn't.  Maybe a warning.  

Luckily for you (and all of us), this is easy enough to do in Ruby:

module Kernel
  alias_method :__old_should, :should

  def should(*args, &blk)
    if self.class == NilClass
      raise RuntimeError, "this is a nil!!"
    else
      __old_should(*args, &blk)
    end
  end
end

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

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

From noreply at rubyforge.org  Mon Aug  6 07:45:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 07:45:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806114540.D0A2F5240A2A@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 11:45

Message:
While I can't think of a good reason to set expectations on nil either, I also think that the first guy who does is going to stop using rspec as soon as he sees an error or warning for doing so. I would!

Also, in fairness, the feedback you get right now says "nil expected :dim ...". It does tell you that you're dealing with nil.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 11:28

Message:
Scott - actually it was only :should_receive I was thinking about, not :should in 
general.  I think making :should work differently for nil would be a mistake, but 
I can still see an argument for :should_receive.  See where I'm coming from?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:23

Message:
Oh - just to follow up.  Of course that code could go into your spec_helper file, so you wouldn't need to carry around a different version of rspec, or make your production environment dependent on RSpec.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:20

Message:
Should this spec raise an error:

describe "NilClass"
  it "should have an instance which is equal to nil" do
    nil.should == nil
  end
end

or how about this (in the case that method_one returns nil):

describe "method_one" do
  it "should return the same value as method_two" do
    method_one.should == method_two
  end
end


It is in an interesting idea, although raising an error probably isn't.  Maybe a warning.  

Luckily for you (and all of us), this is easy enough to do in Ruby:

module Kernel
  alias_method :__old_should, :should

  def should(*args, &blk)
    if self.class == NilClass
      raise RuntimeError, "this is a nil!!"
    else
      __old_should(*args, &blk)
    end
  end
end

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

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

From noreply at rubyforge.org  Mon Aug  6 10:41:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 10:41:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806144141.91FECA970003@rubyforge.org>

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

Category: mock module
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: David Chelimsky (dchelimsky)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

>Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 14:41

Message:
I see your point David

Actually I don't get "nil accepted..." I get " accepted..." (using the spec runner 
from TextMate) which is possibly why I thought this was a bigger issue than it 
is...



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 11:45

Message:
While I can't think of a good reason to set expectations on nil either, I also think that the first guy who does is going to stop using rspec as soon as he sees an error or warning for doing so. I would!

Also, in fairness, the feedback you get right now says "nil expected :dim ...". It does tell you that you're dealing with nil.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 11:28

Message:
Scott - actually it was only :should_receive I was thinking about, not :should in 
general.  I think making :should work differently for nil would be a mistake, but 
I can still see an argument for :should_receive.  See where I'm coming from?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:23

Message:
Oh - just to follow up.  Of course that code could go into your spec_helper file, so you wouldn't need to carry around a different version of rspec, or make your production environment dependent on RSpec.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:20

Message:
Should this spec raise an error:

describe "NilClass"
  it "should have an instance which is equal to nil" do
    nil.should == nil
  end
end

or how about this (in the case that method_one returns nil):

describe "method_one" do
  it "should return the same value as method_two" do
    method_one.should == method_two
  end
end


It is in an interesting idea, although raising an error probably isn't.  Maybe a warning.  

Luckily for you (and all of us), this is easy enough to do in Ruby:

module Kernel
  alias_method :__old_should, :should

  def should(*args, &blk)
    if self.class == NilClass
      raise RuntimeError, "this is a nil!!"
    else
      __old_should(*args, &blk)
    end
  end
end

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

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

From noreply at rubyforge.org  Mon Aug  6 10:47:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 10:47:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806144758.4B9715240B9F@rubyforge.org>

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

Category: mock module
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: David Chelimsky (dchelimsky)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 14:47

Message:
Really? I just did this:

@foo.should_receive(:bar)

and got the following in the TextMate results window:

nil expected :bar with (any args) once, but received it 0 times

You're not getting that? Are you on edge? I don't think this is something that changed recently, but it could be

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 14:41

Message:
I see your point David

Actually I don't get "nil accepted..." I get " accepted..." (using the spec runner 
from TextMate) which is possibly why I thought this was a bigger issue than it 
is...



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 11:45

Message:
While I can't think of a good reason to set expectations on nil either, I also think that the first guy who does is going to stop using rspec as soon as he sees an error or warning for doing so. I would!

Also, in fairness, the feedback you get right now says "nil expected :dim ...". It does tell you that you're dealing with nil.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 11:28

Message:
Scott - actually it was only :should_receive I was thinking about, not :should in 
general.  I think making :should work differently for nil would be a mistake, but 
I can still see an argument for :should_receive.  See where I'm coming from?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:23

Message:
Oh - just to follow up.  Of course that code could go into your spec_helper file, so you wouldn't need to carry around a different version of rspec, or make your production environment dependent on RSpec.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:20

Message:
Should this spec raise an error:

describe "NilClass"
  it "should have an instance which is equal to nil" do
    nil.should == nil
  end
end

or how about this (in the case that method_one returns nil):

describe "method_one" do
  it "should return the same value as method_two" do
    method_one.should == method_two
  end
end


It is in an interesting idea, although raising an error probably isn't.  Maybe a warning.  

Luckily for you (and all of us), this is easy enough to do in Ruby:

module Kernel
  alias_method :__old_should, :should

  def should(*args, &blk)
    if self.class == NilClass
      raise RuntimeError, "this is a nil!!"
    else
      __old_should(*args, &blk)
    end
  end
end

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

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

From noreply at rubyforge.org  Mon Aug  6 10:57:23 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 10:57:23 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806145724.0FF4C5240C32@rubyforge.org>

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

Category: mock module
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: David Chelimsky (dchelimsky)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

>Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 14:57

Message:
No I don't get that...

  nil.should_receive(:foo)

produces

  " expected :foo with (any args) once, but received it 0 times"

This is my svn:externals on vendor/plugins:

rspec svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec
rspec_on_rails 
svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 14:47

Message:
Really? I just did this:

@foo.should_receive(:bar)

and got the following in the TextMate results window:

nil expected :bar with (any args) once, but received it 0 times

You're not getting that? Are you on edge? I don't think this is something that changed recently, but it could be

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 14:41

Message:
I see your point David

Actually I don't get "nil accepted..." I get " accepted..." (using the spec runner 
from TextMate) which is possibly why I thought this was a bigger issue than it 
is...



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 11:45

Message:
While I can't think of a good reason to set expectations on nil either, I also think that the first guy who does is going to stop using rspec as soon as he sees an error or warning for doing so. I would!

Also, in fairness, the feedback you get right now says "nil expected :dim ...". It does tell you that you're dealing with nil.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 11:28

Message:
Scott - actually it was only :should_receive I was thinking about, not :should in 
general.  I think making :should work differently for nil would be a mistake, but 
I can still see an argument for :should_receive.  See where I'm coming from?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:23

Message:
Oh - just to follow up.  Of course that code could go into your spec_helper file, so you wouldn't need to carry around a different version of rspec, or make your production environment dependent on RSpec.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:20

Message:
Should this spec raise an error:

describe "NilClass"
  it "should have an instance which is equal to nil" do
    nil.should == nil
  end
end

or how about this (in the case that method_one returns nil):

describe "method_one" do
  it "should return the same value as method_two" do
    method_one.should == method_two
  end
end


It is in an interesting idea, although raising an error probably isn't.  Maybe a warning.  

Luckily for you (and all of us), this is easy enough to do in Ruby:

module Kernel
  alias_method :__old_should, :should

  def should(*args, &blk)
    if self.class == NilClass
      raise RuntimeError, "this is a nil!!"
    else
      __old_should(*args, &blk)
    end
  end
end

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

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

From noreply at rubyforge.org  Mon Aug  6 11:01:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 11:01:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12845 ] Typo when using instance
	variables in specs leads to setting expectations on the nil object
Message-ID: <20070806150140.009215240B26@rubyforge.org>

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

Category: mock module
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Ashley Moran (ashley_moran)
Assigned to: David Chelimsky (dchelimsky)
Summary: Typo when using instance variables in specs leads to setting expectations on the nil object

Initial Comment:
Just spent ages bashing my head against a wall on this, wondering why my spec was failing.  Basically summed up in this example (not the shortest but similar to my code):

class Computer
  attr_reader :power_indicator
  
  def initialize(power_indicator)
    @power_indicator = power_indicator
  end
  
  def turn_off
    power_indicator.dim
  end
end

describe Computer, "created with a PowerIndicator" do
  before(:each) do
    @power_indicator = mock("PowerIndicator")
    @computer = Computer.new(@power_indicator)
  end
  
  it "should dim the power indicator when sent :turn_off" do
    @power_indciator.should_receive(:dim)
    @computer.turn_off
  end
end

Basically I don't see a reason why you would ever set an expectation on "nil", so I wondered, would the following be better behaviour?

describe NilClass do
  it "should raise an exception when sent :should_receive" do
    lambda { nil.should_receive(:some_message) }.should raise_error(StandardError)
  end
end

A bit like the way when you do "nil.id" in ActiveRecord you get the warning about calling nil.id in case you meant nil.object_id.  WDYT?

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 15:01

Message:
CURRENT means the latest release, not trunk. So this must be fixed in trunk. Release coming soon.

At least no you know that " expected :foo ..." means "nil expected :foo ...".

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 14:57

Message:
No I don't get that...

  nil.should_receive(:foo)

produces

  " expected :foo with (any args) once, but received it 0 times"

This is my svn:externals on vendor/plugins:

rspec svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec
rspec_on_rails 
svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 14:47

Message:
Really? I just did this:

@foo.should_receive(:bar)

and got the following in the TextMate results window:

nil expected :bar with (any args) once, but received it 0 times

You're not getting that? Are you on edge? I don't think this is something that changed recently, but it could be

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 14:41

Message:
I see your point David

Actually I don't get "nil accepted..." I get " accepted..." (using the spec runner 
from TextMate) which is possibly why I thought this was a bigger issue than it 
is...



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-06 11:45

Message:
While I can't think of a good reason to set expectations on nil either, I also think that the first guy who does is going to stop using rspec as soon as he sees an error or warning for doing so. I would!

Also, in fairness, the feedback you get right now says "nil expected :dim ...". It does tell you that you're dealing with nil.

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

Comment By: Ashley Moran (ashley_moran)
Date: 2007-08-06 11:28

Message:
Scott - actually it was only :should_receive I was thinking about, not :should in 
general.  I think making :should work differently for nil would be a mistake, but 
I can still see an argument for :should_receive.  See where I'm coming from?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:23

Message:
Oh - just to follow up.  Of course that code could go into your spec_helper file, so you wouldn't need to carry around a different version of rspec, or make your production environment dependent on RSpec.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-06 11:20

Message:
Should this spec raise an error:

describe "NilClass"
  it "should have an instance which is equal to nil" do
    nil.should == nil
  end
end

or how about this (in the case that method_one returns nil):

describe "method_one" do
  it "should return the same value as method_two" do
    method_one.should == method_two
  end
end


It is in an interesting idea, although raising an error probably isn't.  Maybe a warning.  

Luckily for you (and all of us), this is easy enough to do in Ruby:

module Kernel
  alias_method :__old_should, :should

  def should(*args, &blk)
    if self.class == NilClass
      raise RuntimeError, "this is a nil!!"
    else
      __old_should(*args, &blk)
    end
  end
end

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

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

From dan at tastapod.com  Mon Aug  6 18:43:17 2007
From: dan at tastapod.com (Dan North)
Date: Mon, 06 Aug 2007 23:43:17 +0100
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>	<57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>
	<DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>
Message-ID: <46B7A405.1060100@tastapod.com>

Hi folks.

The merge is a bit more involved than I thought, mostly due to my poor 
understanding of rspec mocks, so I've created a branch at 
http://rspec.rubyforge.org/svn/branches/rbehave-import if anyone wants 
to monitor progress or get involved.

Quick update: all classes and modules in the RBehave namespace have been 
moved into Spec::Story verbatim (along with their examples of course). 
This means that, for instance, there are currently two PendingException 
classes - rbehave's and rspec's.

I still have 2 examples failing (same problem in two places) that seem 
to be about how I'm using rspec's mocking framework. If anyone can spot 
the deliberate error I'd be very grateful. The line is:

    Runner.stub!(:dry_run).and_return(true)

which is giving me the error:

    can't convert Spec::Story::Runner::Options into Hash

Once these are working, the next step is to ensure the rcov coverage is 
up to 100% and get the pre-commit rake target passing.

Cheers,
Dan


Scott Taylor wrote:
> On Aug 2, 2007, at 11:00 PM, David Chelimsky wrote:
>
>   
>> On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>     
>>> There seems to be quite a few of us who want to help.  What is the
>>> state of this project?  Is this being worked on in the Rbehave
>>> repos?  Maybe the RSpec admins could create a branch in the rspec
>>> repos to facilitate this merging.
>>>       
>> Thanks to all for your interest. I need to talk to Aslak and Dan about
>> how we're going to do this, so please hang tight.
>>     
>
> Thanks David.  I guess I'm still a little unsure whether the whole  
> code base will be merged in to RSpec, or whether it will stay  
> separate but the World modules will get mixed into RSpec somehow or  
> another.
>
> I guess we will wait a few days to hear the news.
>
> Best,
>
> Scott
>
>   
>> Cheers,
>> 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
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070806/9cc0f088/attachment.html 

From james.deville at gmail.com  Mon Aug  6 18:58:11 2007
From: james.deville at gmail.com (James Deville)
Date: Mon, 6 Aug 2007 15:58:11 -0700
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <46B7A405.1060100@tastapod.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
	<57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>
	<DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>
	<46B7A405.1060100@tastapod.com>
Message-ID: <c9b75f80708061558k70640c50sb059669f2fa6c8dc@mail.gmail.com>

Dan,

In response to your question about specific files/behaviors, I will be
sending a patch this eventing that will expose the -e option through rake
spec:e. Hope it helps.

Jim Deville

On 8/6/07, Dan North <dan at tastapod.com> wrote:
>
>  Hi folks.
>
> The merge is a bit more involved than I thought, mostly due to my poor
> understanding of rspec mocks, so I've created a branch at
> http://rspec.rubyforge.org/svn/branches/rbehave-import if anyone wants to
> monitor progress or get involved.
>
> Quick update: all classes and modules in the RBehave namespace have been
> moved into Spec::Story verbatim (along with their examples of course). This
> means that, for instance, there are currently two PendingException classes -
> rbehave's and rspec's.
>
> I still have 2 examples failing (same problem in two places) that seem to
> be about how I'm using rspec's mocking framework. If anyone can spot the
> deliberate error I'd be very grateful. The line is:
>
>     Runner.stub!(:dry_run).and_return(true)
>
> which is giving me the error:
>
>     can't convert Spec::Story::Runner::Options into Hash
>
> Once these are working, the next step is to ensure the rcov coverage is up
> to 100% and get the pre-commit rake target passing.
>
> Cheers,
> Dan
>
>
> Scott Taylor wrote:
>
> On Aug 2, 2007, at 11:00 PM, David Chelimsky wrote:
>
>    On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> <mailing_lists at railsnewbie.com> wrote:
>
>  There seems to be quite a few of us who want to help.  What is the
> state of this project?  Is this being worked on in the Rbehave
> repos?  Maybe the RSpec admins could create a branch in the rspec
> repos to facilitate this merging.
>
>  Thanks to all for your interest. I need to talk to Aslak and Dan about
> how we're going to do this, so please hang tight.
>
>  Thanks David.  I guess I'm still a little unsure whether the whole
> code base will be merged in to RSpec, or whether it will stay
> separate but the World modules will get mixed into RSpec somehow or
> another.
>
> I guess we will wait a few days to hear the news.
>
> Best,
>
> Scott
>
>    Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-devel
>
>  _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.orghttp://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/20070806/ad1f4d1b/attachment.html 

From mailing_lists at railsnewbie.com  Mon Aug  6 19:03:26 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Mon, 6 Aug 2007 19:03:26 -0400
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <c9b75f80708061558k70640c50sb059669f2fa6c8dc@mail.gmail.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
	<57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>
	<DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>
	<46B7A405.1060100@tastapod.com>
	<c9b75f80708061558k70640c50sb059669f2fa6c8dc@mail.gmail.com>
Message-ID: <121B2C64-F61A-40EC-8A15-ACB02C7EA550@railsnewbie.com>


What is the protocol for submitting patches?  Should we be submitting  
them through RSpec's tracker?

Scott


On Aug 6, 2007, at 6:58 PM, James Deville wrote:

> Dan,
>
> In response to your question about specific files/behaviors, I will  
> be sending a patch this eventing that will expose the -e option  
> through rake spec:e. Hope it helps.
>
> Jim Deville
>
> On 8/6/07, Dan North <dan at tastapod.com> wrote:
> Hi folks.
>
> The merge is a bit more involved than I thought, mostly due to my  
> poor understanding of rspec mocks, so I've created a branch at  
> http://rspec.rubyforge.org/svn/branches/rbehave-import if anyone  
> wants to monitor progress or get involved.
>
> Quick update: all classes and modules in the RBehave namespace have  
> been moved into Spec::Story verbatim (along with their examples of  
> course). This means that, for instance, there are currently two  
> PendingException classes - rbehave's and rspec's.
>
> I still have 2 examples failing (same problem in two places) that  
> seem to be about how I'm using rspec's mocking framework. If anyone  
> can spot the deliberate error I'd be very grateful. The line is:
>
>     Runner.stub!(:dry_run).and_return(true)
>
> which is giving me the error:
>
>     can't convert Spec::Story::Runner::Options into Hash
>
> Once these are working, the next step is to ensure the rcov  
> coverage is up to 100% and get the pre-commit rake target passing.
>
> Cheers,
> Dan
>
>
>
> Scott Taylor wrote:
>> On Aug 2, 2007, at 11:00 PM, David Chelimsky wrote:
>>
>>> On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>> There seems to be quite a few of us who want to help. What is the
>>>> state of this project? Is this being worked on in the Rbehave
>>>> repos? Maybe the RSpec admins could create a branch in the rspec
>>>> repos to facilitate this merging.
>>> Thanks to all for your interest. I need to talk to Aslak and Dan  
>>> about
>>> how we're going to do this, so please hang tight.
>> Thanks David. I guess I'm still a little unsure whether the whole
>> code base will be merged in to RSpec, or whether it will stay
>> separate but the World modules will get mixed into RSpec somehow or
>> another.
>>
>> I guess we will wait a few days to hear the news.
>>
>> Best,
>>
>> Scott
>>
>>> Cheers,
>>> 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
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Mon Aug  6 20:37:58 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 6 Aug 2007 19:37:58 -0500
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <121B2C64-F61A-40EC-8A15-ACB02C7EA550@railsnewbie.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
	<57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>
	<DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>
	<46B7A405.1060100@tastapod.com>
	<c9b75f80708061558k70640c50sb059669f2fa6c8dc@mail.gmail.com>
	<121B2C64-F61A-40EC-8A15-ACB02C7EA550@railsnewbie.com>
Message-ID: <57c63afe0708061737n39b85dfdpa4e76f5755c8b2bc@mail.gmail.com>

On 8/6/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> What is the protocol for submitting patches?  Should we be submitting
> them through RSpec's tracker?

Now that there is a branch, yes please. Please reference the branch in
the ticket, along w/ the revision number you are patching (as there
will likely be some activity in the next few days).

Thanks,
David

>
> Scott
>
>
> On Aug 6, 2007, at 6:58 PM, James Deville wrote:
>
> > Dan,
> >
> > In response to your question about specific files/behaviors, I will
> > be sending a patch this eventing that will expose the -e option
> > through rake spec:e. Hope it helps.
> >
> > Jim Deville
> >
> > On 8/6/07, Dan North <dan at tastapod.com> wrote:
> > Hi folks.
> >
> > The merge is a bit more involved than I thought, mostly due to my
> > poor understanding of rspec mocks, so I've created a branch at
> > http://rspec.rubyforge.org/svn/branches/rbehave-import if anyone
> > wants to monitor progress or get involved.
> >
> > Quick update: all classes and modules in the RBehave namespace have
> > been moved into Spec::Story verbatim (along with their examples of
> > course). This means that, for instance, there are currently two
> > PendingException classes - rbehave's and rspec's.
> >
> > I still have 2 examples failing (same problem in two places) that
> > seem to be about how I'm using rspec's mocking framework. If anyone
> > can spot the deliberate error I'd be very grateful. The line is:
> >
> >     Runner.stub!(:dry_run).and_return(true)
> >
> > which is giving me the error:
> >
> >     can't convert Spec::Story::Runner::Options into Hash
> >
> > Once these are working, the next step is to ensure the rcov
> > coverage is up to 100% and get the pre-commit rake target passing.
> >
> > Cheers,
> > Dan
> >
> >
> >
> > Scott Taylor wrote:
> >> On Aug 2, 2007, at 11:00 PM, David Chelimsky wrote:
> >>
> >>> On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >>>> There seems to be quite a few of us who want to help. What is the
> >>>> state of this project? Is this being worked on in the Rbehave
> >>>> repos? Maybe the RSpec admins could create a branch in the rspec
> >>>> repos to facilitate this merging.
> >>> Thanks to all for your interest. I need to talk to Aslak and Dan
> >>> about
> >>> how we're going to do this, so please hang tight.
> >> Thanks David. I guess I'm still a little unsure whether the whole
> >> code base will be merged in to RSpec, or whether it will stay
> >> separate but the World modules will get mixed into RSpec somehow or
> >> another.
> >>
> >> I guess we will wait a few days to hear the news.
> >>
> >> Best,
> >>
> >> Scott
> >>
> >>> Cheers,
> >>> 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
> >
> > _______________________________________________
> > 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  Mon Aug  6 23:37:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 23:37:25 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12865 ] Partial mock error when object
	has an @options instance var
Message-ID: <20070807033725.F11D5A970003@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: Partial mock error when object has an @options instance var

Initial Comment:
The following fails:

describe "partial mock" do
  it "should not conflict with @options in the object" do
    @object = Object.new
    @object.instance_eval { @options = Object.new }
    @object.should_receive(:blah)
    @object.blah
  end
end

... with this error:

can't convert Object into Hash.

The problem is in spec/mocks/methods in __mock_proxy:

  def __mock_proxy
    @mock_proxy ||= Proxy.new(self, @name, @options)
  end

The @options argument is meaningful in an instance of Spec::Mocks::Mock, but not in an any other object.



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

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

From noreply at rubyforge.org  Mon Aug  6 23:45:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  6 Aug 2007 23:45:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12865 ] Partial mock error when object
	has an @options instance var
Message-ID: <20070807034518.C50D85240E1D@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: David Chelimsky (dchelimsky)
Summary: Partial mock error when object has an @options instance var

Initial Comment:
The following fails:

describe "partial mock" do
  it "should not conflict with @options in the object" do
    @object = Object.new
    @object.instance_eval { @options = Object.new }
    @object.should_receive(:blah)
    @object.blah
  end
end

... with this error:

can't convert Object into Hash.

The problem is in spec/mocks/methods in __mock_proxy:

  def __mock_proxy
    @mock_proxy ||= Proxy.new(self, @name, @options)
  end

The @options argument is meaningful in an instance of Spec::Mocks::Mock, but not in an any other object.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-07 03:45

Message:
Fixed in r2307

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

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

From dchelimsky at gmail.com  Tue Aug  7 01:08:20 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 7 Aug 2007 00:08:20 -0500
Subject: [rspec-devel] closing in on rspec story runner (rbehave)
Message-ID: <57c63afe0708062208s398c4f59w1089ef51f02518b6@mail.gmail.com>

I resolved the two failures Dan spoke of in another thread and am
close to getting to 100% coverage. If someone wants to look at that it
would be helpful. It involves objects that are generated while
bootstrapping the runner, so it'll probably need to be refactored a
bit in order to get access to those elements in specs.

Getting close.

Cheers,
David

From noreply at rubyforge.org  Tue Aug  7 01:17:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  7 Aug 2007 01:17:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12866 ] rails integration
	stories
Message-ID: <20070807051705.8690D5240E0C@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: rails integration stories

Initial Comment:
Now that we're close to getting rbehave's story runner merged into rspec, we need to start looking at wrapping rails integration tests in Rspec Stories.


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

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

From noreply at rubyforge.org  Tue Aug  7 01:17:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  7 Aug 2007 01:17:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-9381 ] rails integration
	spec'ing
Message-ID: <20070807051754.5024DA970003@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: Closed
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


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-07 05:17

Message:
obsolesced by http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12866&group_id=797

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

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

From mailing_lists at railsnewbie.com  Tue Aug  7 10:51:15 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Tue, 7 Aug 2007 10:51:15 -0400
Subject: [rspec-devel] closing in on rspec story runner (rbehave)
In-Reply-To: <57c63afe0708062208s398c4f59w1089ef51f02518b6@mail.gmail.com>
References: <57c63afe0708062208s398c4f59w1089ef51f02518b6@mail.gmail.com>
Message-ID: <E4B591BC-F550-493F-A3E4-F51ACC47D297@railsnewbie.com>


On Aug 7, 2007, at 1:08 AM, David Chelimsky wrote:

Which branch are you working on?

It didn't look like you had resolved it, as of a few hours ago.

On another note: how do you use autotest with rspec's development?   
Autotest always wants to use the gem, not the rspec in the local  
rspec/rspec/bin dir.  If you don't use autotest, then how do you use  
the --failures and --examples?  The default rake spec task doesn't  
seem to use the --failures

Scott


> I resolved the two failures Dan spoke of in another thread and am
> close to getting to 100% coverage. If someone wants to look at that it
> would be helpful. It involves objects that are generated while
> bootstrapping the runner, so it'll probably need to be refactored a
> bit in order to get access to those elements in specs.
>
> Getting close.
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Tue Aug  7 12:52:57 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 7 Aug 2007 11:52:57 -0500
Subject: [rspec-devel] closing in on rspec story runner (rbehave)
In-Reply-To: <E4B591BC-F550-493F-A3E4-F51ACC47D297@railsnewbie.com>
References: <57c63afe0708062208s398c4f59w1089ef51f02518b6@mail.gmail.com>
	<E4B591BC-F550-493F-A3E4-F51ACC47D297@railsnewbie.com>
Message-ID: <57c63afe0708070952j5e8a9b6fwba4430d8f720338b@mail.gmail.com>

On 8/7/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> On Aug 7, 2007, at 1:08 AM, David Chelimsky wrote:
>
> Which branch are you working on?

rbehave-import

> It didn't look like you had resolved it, as of a few hours ago.

cd branches/rbehave-import/rspec
rake

That gives me all passing specs w/ 99.6% coverage.

> On another note: how do you use autotest with rspec's development?

Sadly, I don't. Haven't solved that problem yet.

> Autotest always wants to use the gem, not the rspec in the local
> rspec/rspec/bin dir.  If you don't use autotest, then how do you use
> the --failures and --examples?  The default rake spec task doesn't
> seem to use the --failures
>
> Scott
>
>
> > I resolved the two failures Dan spoke of in another thread and am
> > close to getting to 100% coverage. If someone wants to look at that it
> > would be helpful. It involves objects that are generated while
> > bootstrapping the runner, so it'll probably need to be refactored a
> > bit in order to get access to those elements in specs.
> >
> > Getting close.
> >
> > Cheers,
> > 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 dan at tastapod.com  Tue Aug  7 15:36:20 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 07 Aug 2007 20:36:20 +0100
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <57c63afe0708061737n39b85dfdpa4e76f5755c8b2bc@mail.gmail.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>	<57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>	<DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>	<46B7A405.1060100@tastapod.com>	<c9b75f80708061558k70640c50sb059669f2fa6c8dc@mail.gmail.com>	<121B2C64-F61A-40EC-8A15-ACB02C7EA550@railsnewbie.com>
	<57c63afe0708061737n39b85dfdpa4e76f5755c8b2bc@mail.gmail.com>
Message-ID: <46B8C9B4.4090703@tastapod.com>

I solved the @options thing by renaming my property to @run_options. 
Although the correct fix would be to have all the mock properties and 
methods prepended with something like @__rspec_options to keep the 
method namespace clear for mocked objects.

I really appreciate you guys fixing the underlying issues as they come 
up (like mock.options). I'll just focus on getting rbehave integrated 
into rspec, changing rbehave to work with the current rspec cut where 
they clash.

I haven't got 100% coverage yet, although I was quite pleased with 96%+ 
at first go :)

I'll get that working, plus I've imported the Game of Life example into 
rspec/examples/story/game-of-life. Then I'll wait for David's blessing 
to merge into trunk.

Cheers,
Dan

David Chelimsky wrote:
> On 8/6/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>   
>> What is the protocol for submitting patches?  Should we be submitting
>> them through RSpec's tracker?
>>     
>
> Now that there is a branch, yes please. Please reference the branch in
> the ticket, along w/ the revision number you are patching (as there
> will likely be some activity in the next few days).
>
> Thanks,
> David
>
>   
>> Scott
>>
>>
>> On Aug 6, 2007, at 6:58 PM, James Deville wrote:
>>
>>     
>>> Dan,
>>>
>>> In response to your question about specific files/behaviors, I will
>>> be sending a patch this eventing that will expose the -e option
>>> through rake spec:e. Hope it helps.
>>>
>>> Jim Deville
>>>
>>> On 8/6/07, Dan North <dan at tastapod.com> wrote:
>>> Hi folks.
>>>
>>> The merge is a bit more involved than I thought, mostly due to my
>>> poor understanding of rspec mocks, so I've created a branch at
>>> http://rspec.rubyforge.org/svn/branches/rbehave-import if anyone
>>> wants to monitor progress or get involved.
>>>
>>> Quick update: all classes and modules in the RBehave namespace have
>>> been moved into Spec::Story verbatim (along with their examples of
>>> course). This means that, for instance, there are currently two
>>> PendingException classes - rbehave's and rspec's.
>>>
>>> I still have 2 examples failing (same problem in two places) that
>>> seem to be about how I'm using rspec's mocking framework. If anyone
>>> can spot the deliberate error I'd be very grateful. The line is:
>>>
>>>     Runner.stub!(:dry_run).and_return(true)
>>>
>>> which is giving me the error:
>>>
>>>     can't convert Spec::Story::Runner::Options into Hash
>>>
>>> Once these are working, the next step is to ensure the rcov
>>> coverage is up to 100% and get the pre-commit rake target passing.
>>>
>>> Cheers,
>>> Dan
>>>
>>>
>>>
>>> Scott Taylor wrote:
>>>       
>>>> On Aug 2, 2007, at 11:00 PM, David Chelimsky wrote:
>>>>
>>>>         
>>>>> On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>>>           
>>>>>> There seems to be quite a few of us who want to help. What is the
>>>>>> state of this project? Is this being worked on in the Rbehave
>>>>>> repos? Maybe the RSpec admins could create a branch in the rspec
>>>>>> repos to facilitate this merging.
>>>>>>             
>>>>> Thanks to all for your interest. I need to talk to Aslak and Dan
>>>>> about
>>>>> how we're going to do this, so please hang tight.
>>>>>           
>>>> Thanks David. I guess I'm still a little unsure whether the whole
>>>> code base will be merged in to RSpec, or whether it will stay
>>>> separate but the World modules will get mixed into RSpec somehow or
>>>> another.
>>>>
>>>> I guess we will wait a few days to hear the news.
>>>>
>>>> Best,
>>>>
>>>> Scott
>>>>
>>>>         
>>>>> Cheers,
>>>>> 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
>>>
>>> _______________________________________________
>>> 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/20070807/a545f572/attachment.html 

From dchelimsky at gmail.com  Tue Aug  7 16:02:20 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 7 Aug 2007 15:02:20 -0500
Subject: [rspec-devel] merging rbehave into rspec
In-Reply-To: <46B8C9B4.4090703@tastapod.com>
References: <ad4f9af90708021013t2072f61el418f0f648e4cae54@mail.gmail.com>
	<145359ad0708021443s385f34a2h6d6e977f985b1b9@mail.gmail.com>
	<FED5F33F-CD6A-4AC0-B273-A4B1FACBE429@railsnewbie.com>
	<57c63afe0708022000g4c29de7cnb746a480675a6930@mail.gmail.com>
	<DFED2298-144C-424E-9EB2-495D1D06876E@railsnewbie.com>
	<46B7A405.1060100@tastapod.com>
	<c9b75f80708061558k70640c50sb059669f2fa6c8dc@mail.gmail.com>
	<121B2C64-F61A-40EC-8A15-ACB02C7EA550@railsnewbie.com>
	<57c63afe0708061737n39b85dfdpa4e76f5755c8b2bc@mail.gmail.com>
	<46B8C9B4.4090703@tastapod.com>
Message-ID: <57c63afe0708071302xebdd639t3719e23b29c848c4@mail.gmail.com>

On 8/7/07, Dan North <dan at tastapod.com> wrote:
>
>  I solved the @options thing by renaming my property to @run_options.
> Although the correct fix would be to have all the mock properties and
> methods prepended with something like @__rspec_options to keep the method
> namespace clear for mocked objects.

I think we overlapped a bit here - I already fixed the @options
problem directly in rspec and merged in the change to the
rbehave-import branch. I didn't rename @options as you suggest, but I
made it so that if the object itself is a Mock, it uses @options,
otherwise it does not. That solved the failures in spec/story.

FYI - I'm open to changing @options to @__rspec_options - if you want
to do that (Dan) go ahead.

>  I really appreciate you guys fixing the underlying issues as they come up
> (like mock.options). I'll just focus on getting rbehave integrated into
> rspec, changing rbehave to work with the current rspec cut where they clash.
>
>  I haven't got 100% coverage yet, although I was quite pleased with 96%+ at
> first go :)

Per my previous email - the remaining problems are going to probably
require some refactoring in order to get them covered without having
some gnarly specs.

>
>  I'll get that working, plus I've imported the Game of Life example into
> rspec/examples/story/game-of-life. Then I'll wait for
> David's blessing to merge into trunk.

I want to get 1.0.6 released before we merge this in. For that I'm
waiting on Aslak to tie up a couple of loose ends related to the new
Spec::Distributed.

We've also got Brian's work on simplifying the whole object runner
object model (say that 10 times fast) so we'll need to coordinate on
merging efforts. Ideally, I'd like to see both branches merged in
after 1.0.6 and then we'd be working towards a 1.1.0 release.

Cheers,
David

>
>  Cheers,
>  Dan
>
>
>  David Chelimsky wrote:
>  On 8/6/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
>
>  What is the protocol for submitting patches? Should we be submitting
> them through RSpec's tracker?
>
>  Now that there is a branch, yes please. Please reference the branch in
> the ticket, along w/ the revision number you are patching (as there
> will likely be some activity in the next few days).
>
> Thanks,
> David
>
>
>
>  Scott
>
>
> On Aug 6, 2007, at 6:58 PM, James Deville wrote:
>
>
>
>  Dan,
>
> In response to your question about specific files/behaviors, I will
> be sending a patch this eventing that will expose the -e option
> through rake spec:e. Hope it helps.
>
> Jim Deville
>
> On 8/6/07, Dan North <dan at tastapod.com> wrote:
> Hi folks.
>
> The merge is a bit more involved than I thought, mostly due to my
> poor understanding of rspec mocks, so I've created a branch at
> http://rspec.rubyforge.org/svn/branches/rbehave-import if
> anyone
> wants to monitor progress or get involved.
>
> Quick update: all classes and modules in the RBehave namespace have
> been moved into Spec::Story verbatim (along with their examples of
> course). This means that, for instance, there are currently two
> PendingException classes - rbehave's and rspec's.
>
> I still have 2 examples failing (same problem in two places) that
> seem to be about how I'm using rspec's mocking framework. If anyone
> can spot the deliberate error I'd be very grateful. The line is:
>
>  Runner.stub!(:dry_run).and_return(true)
>
> which is giving me the error:
>
>  can't convert Spec::Story::Runner::Options into Hash
>
> Once these are working, the next step is to ensure the rcov
> coverage is up to 100% and get the pre-commit rake target passing.
>
> Cheers,
> Dan
>
>
>
> Scott Taylor wrote:
>
>
>  On Aug 2, 2007, at 11:00 PM, David Chelimsky wrote:
>
>
>
>  On 8/2/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
>
>  There seems to be quite a few of us who want to help. What is the
> state of this project? Is this being worked on in the Rbehave
> repos? Maybe the RSpec admins could create a branch in the rspec
> repos to facilitate this merging.
>
>  Thanks to all for your interest. I need to talk to Aslak and Dan
> about
> how we're going to do this, so please hang tight.
>
>  Thanks David. I guess I'm still a little unsure whether the whole
> code base will be merged in to RSpec, or whether it will stay
> separate but the World modules will get mixed into RSpec somehow or
> another.
>
> I guess we will wait a few days to hear the news.
>
> Best,
>
> Scott
>
>
>
>  Cheers,
> 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
>
> _______________________________________________
> 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  Tue Aug  7 20:37:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  7 Aug 2007 20:37:51 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12893 ] RSpec's Autotest
	should work with rspec's trunk
Message-ID: <20070808003751.376805240C13@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: RSpec's Autotest should work with rspec's trunk

Initial Comment:
Autotest seems to run whatever rspec is installed in the gems dir.  This does not allow one to make Behaviour driven changes to rspec with autotest.

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

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

From noreply at rubyforge.org  Tue Aug  7 20:42:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  7 Aug 2007 20:42:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12894 ] Stubs should be able
	to both return and yield a value
Message-ID: <20070808004209.61B635240C13@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Stubs should be able to both return and yield a value

Initial Comment:

Stubs can return values:

obj.stub!(:example_method).and_return "val"

or they could yield to values:

obj.stub!(:example_method).and_yield "val"

What if they could do both?

obj.stub!(:example_method).yield("val").and_return "val"

Better syntax is welcome.

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

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

From noreply at rubyforge.org  Tue Aug  7 20:51:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  7 Aug 2007 20:51:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12895 ] mocks with inline
	stubs
Message-ID: <20070808005101.3BCD6A970008@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: mocks with inline stubs

Initial Comment:

Oftentimes I find myself with a setup like this:

@mock = mock Object
Object.stub!(:new).and_return @mock
@mock.stub!(:method_one).and_return "foo"
@mock.stub!(:method_two).and_return "bar"

After several mock objects + their stubs in one setup/before block, this can get quite hard to read.  This code could be abstracted into a helper method, but I find that generally does not help the readability of the situation.

Would the following solve the problem:

obj = mock Object do |o|
  Object.stub!(:new).and_return o
  o.stub!(:method_one).and_return "foo"
  o.stub!(:method_two).and_return "bar"
end

or with an implicit receiver:

obj = mock Object do
  stub!(:method_one).and_return "foo"
  stub!(:method_two).and_return "bar"
end

I think this would go along way to making before/setup blocks easier to read, if, for no other reason, then the convention of pretty prettying.  WDYT?

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

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

From noreply at rubyforge.org  Tue Aug  7 21:24:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  7 Aug 2007 21:24:08 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12898 ] render should support :inline
Message-ID: <20070808012409.13FE95240C13@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: render should support :inline

Initial Comment:
The version of render in rspec_on_rails/lib/rails/dsl/behaviour/view.rb supports only rendering a template, a partial, or a file.  The ability to render :inline would be useful for such things as testing custom FormBuilders, e.g.:

describe LabelledBuilder do

  it "should let me create a text field" do
    object = mock(object)
    object.stub!(:attribute).and_return("Test String")

     render :inline =>
      "<% form_for(@object, :builder => LabelledBuilder) do |f| -%>
        <%= f.text_field :attribute %>
       <% end %>"

     response.should have_tag("label")
  end
end

results in:

Unhandled render type in view spec.



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

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

From noreply at rubyforge.org  Tue Aug  7 23:46:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  7 Aug 2007 23:46:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12893 ] RSpec's Autotest
	should work with rspec's trunk
Message-ID: <20070808034628.5F43C5240D4B@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: RSpec's Autotest should work with rspec's trunk

Initial Comment:
Autotest seems to run whatever rspec is installed in the gems dir.  This does not allow one to make Behaviour driven changes to rspec with autotest.

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

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

Message:
Fixed in r2314

The spec command will be "bin/spec" if it finds that file (which implies that you're in the rspec project), or just "spec" if not (which assumes that you have the spec command installed).

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

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

From noreply at rubyforge.org  Tue Aug  7 23:56:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  7 Aug 2007 23:56:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12895 ] mocks with inline
	stubs
Message-ID: <20070808035632.D3C85A970008@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: mocks with inline stubs

Initial Comment:

Oftentimes I find myself with a setup like this:

@mock = mock Object
Object.stub!(:new).and_return @mock
@mock.stub!(:method_one).and_return "foo"
@mock.stub!(:method_two).and_return "bar"

After several mock objects + their stubs in one setup/before block, this can get quite hard to read.  This code could be abstracted into a helper method, but I find that generally does not help the readability of the situation.

Would the following solve the problem:

obj = mock Object do |o|
  Object.stub!(:new).and_return o
  o.stub!(:method_one).and_return "foo"
  o.stub!(:method_two).and_return "bar"
end

or with an implicit receiver:

obj = mock Obje