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 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?

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

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

Message:
There's already a shorthand for this:

Object.stub!(:new).and_return(
  stub(
    "object",
    :method_one => "foo",
    :method_two => "bar
  )
)

To be honest, I find the example you gave at the beginning much easier to grok what's going on than the alternatives you suggest. Although, perhaps the first one would be a bit cleaner like this:

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

You might be interested in Brian Takita's new framework called RR. I'm pretty sure it let's you this:

obj = mock(Object) do |o|
  o.method_one { "foo" }
  o.method_two { "bar" }
end

Brian - if you read this please confirm or deny.

I'm inclined to close this, but I'll leave it open for others to comment.

Comments?

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

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

From noreply at rubyforge.org  Wed Aug  8 00:55:55 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  8 Aug 2007 00:55:55 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-11818 ] Have mode for Rails
	Error Handling
Message-ID: <20070808045555.8D09A5240C3A@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Have mode for Rails Error Handling

Initial Comment:
Currently we default to raise an error as it happens.

There should be a way to use Rail's default error handling. This is needed to verify that error specific behaviour is occurring, such as exception notification.

To start things off, I added ActionController::Rescue#use_rails_error_handling! and ActionController::Rescue#use_rails_error_handling? to do this (Rev 2128).

Thoughts?

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

>Comment By: Brian Takita (btakita)
Date: 2007-08-07 21:55

Message:
That looks good to me.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-24 23:22

Message:
Well - maybe the exclamation point doesn't make sense except when the method is being called directly on ActionController::Rescue. But I think we should either always have the exclamation point or never. Otherwise it'll just get confusing.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-06-24 23:20

Message:
Seems reasonable. I think that same method should then be made available via config:

Spec::Runner.configure do |config|
  config.use_rails_error_handling!
end

or directly in a given behaviour:

describe SomeController do
  use_rails_error_handling!
  ...
end

WDYT?

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

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

From noreply at rubyforge.org  Wed Aug  8 00:56:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  8 Aug 2007 00:56:52 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12710 ] Error messages on
	multiple lines
Message-ID: <20070808045652.642655240C3A@rubyforge.org>

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

Category: expectation module
Group: None
>Status: Closed
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Error messages on multiple lines

Initial Comment:
Currently its:

expected <SomeLongObject .... > got <AnotherLongObject ... >

This makes it very difficult to see the differences once the textual length of the objects are longer than the length of the console.

It would be MUCH easier to read if the output were formatted on multiple lines:

expected
<SomeLongObject ... >
got
<AnotherLongObject ... >

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

>Comment By: Brian Takita (btakita)
Date: 2007-08-07 21:56

Message:
Great, Ill close this.

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

Comment By: Kyle Hargraves (philodespotos)
Date: 2007-07-30 20:10

Message:
This is actually already in trunk:

'Foo should == #<Foo:really long description>'
expected: #<Foo:same really long description>
     got: #<Foo:another really long description>

In a -users thread (maybe last month?), someone mentioned it'd also be nice to have semi-intelligent use of pretty printing if the inspect string for the object were obscenely long.

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

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

From noreply at rubyforge.org  Wed Aug  8 01:25:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  8 Aug 2007 01:25:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12895 ] mocks with inline
	stubs
Message-ID: <20070808052540.E02915240D56@rubyforge.org>

Feature Requests item #12895, was opened at 2007-08-07 17: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?

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

>Comment By: Brian Takita (btakita)
Date: 2007-08-07 22:25

Message:
Yes RR does support that type of syntax. I've been meaning
to make a blog post that has a tutorial.

Lets say you want to stub User.new. In RR, you can say:

# This mocks each instance of User with the expectations
that method_one and method_two will be called once and
return "foo" and "bar".
mock.instance_of(User) do |o|
  o.method_one {"foo"}
  o.method_two {"bar"}
end

or alternatively:

# This allows the real call to User.new and intercepts the
return value
stub.probe(User).new do |user|
  mock(user).method_one {"foo"}
  mock(user).method_two {"bar"}
  user
end

Of course, literally stubbing Object.new will cause a stack
error on any of Ruby's mock frameworks.

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

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

Message:
There's already a shorthand for this:

Object.stub!(:new).and_return(
  stub(
    "object",
    :method_one => "foo",
    :method_two => "bar
  )
)

To be honest, I find the example you gave at the beginning much easier to grok what's going on than the alternatives you suggest. Although, perhaps the first one would be a bit cleaner like this:

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

You might be interested in Brian Takita's new framework called RR. I'm pretty sure it let's you this:

obj = mock(Object) do |o|
  o.method_one { "foo" }
  o.method_two { "bar" }
end

Brian - if you read this please confirm or deny.

I'm inclined to close this, but I'll leave it open for others to comment.

Comments?

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

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

From noreply at rubyforge.org  Thu Aug  9 09:16:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  9 Aug 2007 09:16:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12935 ] Remove requirement that mocha
	must be installed as a gem when used as mocking framework
Message-ID: <20070809131635.5863B5240A56@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ryan Kinderman (ryankinderman)
Assigned to: Nobody (None)
Summary: Remove requirement that mocha must be installed as a gem when used as mocking framework

Initial Comment:
Rationale:
I often localize/freeze the libraries that are required to run the tests in my projects specifically to simplify the setup time required to get up and running with development. By requiring that mocha be installed as a gem, one of the core utilities used in my tests is prevented from being frozen.

Solution:
Remove the "require 'rubygems'" and "gem 'mocha'" commands from the mock_frameworks/mocha.rb. This puts the onus of making that library available on the developer who is using the library. They should know best how to do this for their project's purposes anyways.

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

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

From noreply at rubyforge.org  Thu Aug  9 11:06:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  9 Aug 2007 11:06:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12935 ] Remove requirement that mocha
	must be installed as a gem when used as mocking framework
Message-ID: <20070809150629.126315240AB3@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Ryan Kinderman (ryankinderman)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Remove requirement that mocha must be installed as a gem when used as mocking framework

Initial Comment:
Rationale:
I often localize/freeze the libraries that are required to run the tests in my projects specifically to simplify the setup time required to get up and running with development. By requiring that mocha be installed as a gem, one of the core utilities used in my tests is prevented from being frozen.

Solution:
Remove the "require 'rubygems'" and "gem 'mocha'" commands from the mock_frameworks/mocha.rb. This puts the onus of making that library available on the developer who is using the library. They should know best how to do this for their project's purposes anyways.

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

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

Message:
Applied in r2325. I also modified the other mock framework plugins accordingly.

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

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

From mailing_lists at railsnewbie.com  Fri Aug 10 06:06:21 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 10 Aug 2007 06:06:21 -0400
Subject: [rspec-devel] Autotest + Rails + HEAD/trunk Rspec
Message-ID: <8D604EAC-D544-47C4-9087-3C1007C35184@railsnewbie.com>


David,

I believe you authored the plugin for autotest integration (unless it  
was Aslak - my apologies then).  Could you give me a hint on how  
Autotest ends up using the spec command in script/spec instead of the  
one installed in gems?  Or is this a current bug?

I now have 100% code coverage w/ rspec's autotest, and will submit a  
patch soon.

Scott


From dchelimsky at gmail.com  Fri Aug 10 07:58:47 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 10 Aug 2007 06:58:47 -0500
Subject: [rspec-devel] Autotest + Rails + HEAD/trunk Rspec
In-Reply-To: <8D604EAC-D544-47C4-9087-3C1007C35184@railsnewbie.com>
References: <8D604EAC-D544-47C4-9087-3C1007C35184@railsnewbie.com>
Message-ID: <57c63afe0708100458s790faa6ek9d640fca365d0e73@mail.gmail.com>

On 8/10/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> David,
>
> I believe you authored the plugin for autotest integration (unless it
> was Aslak - my apologies then).  Could you give me a hint on how
> Autotest ends up using the spec command in script/spec instead of the
> one installed in gems?  Or is this a current bug?

When autotest starts it looks on the path for any file named
autotest/discover.rb. The one in rspec core tells autotest that if it
can find a spec directory that it must be rspec. It already knows that
if it finds config/environment that it must be rails (that's the
assumption made directly by autotest). It then adds words to a list:
rspec, rails, camping, etc - depending on what it learns from the
autotest/discover files and what it discovers.

So in the case of an rspec project, it then looks for a file named
autotest/rspec.rb, which it finds in rspec core. In the case of an
rspec/rails project it looks for a file named autotest/rails_rspec.rb,
which it finds in the rspec_on_rails plugin. These two different files
define two different spec commands. In fact, the one in trunk in core
now generates "ruby bin/spec" if it finds "bin/spec", otherwise it
generates "ruby spec" - that supports using autotest to work on rspec
directly.

That all make sense?

>
> I now have 100% code coverage w/ rspec's autotest, and will submit a
> patch soon.
>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Fri Aug 10 10:01:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 10 Aug 2007 10:01:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12963 ] RESTfully generated
	(polymorphic) helpers require arguments in rspec but not in rails
Message-ID: <20070810140116.502275240C4B@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Lance Carlson (lancelot)
Assigned to: Nobody (None)
Summary: RESTfully generated (polymorphic) helpers require arguments in rspec but not in rails

Initial Comment:
My view tests fail when I try to use the polymorphic helpers in rails and report back an error like this:

ActionView::TemplateError in 'Edit Artist Page should render the edit
artist form'
label_artist_url failed to generate from {:controller=>"artists",
:action=>"show"} - you may have ambiguous routes, or you may need to
supply additional parameters for this route.  content_url has the
following required parameters: ["labels", :label_id, "artists", :id] -
are they all satisfied?
On line #3 of app/views/artists/edit.rhtml

   1: <h1>Editing artist</h1>
   2:
   3: <% form_tag label_artist_path, :method => :put do %>
   4:   <%= render :partial => 'form' %>
   5:   <%= submit_tag 'Save' %>
   6: <% end %>

I could stub out the method, but then I wouldn't be testing the view in its entirety. I could provide the arguments that it asks for and the tests passes. Forcing me to add the arguments adds unnecessary noise to the code and should not be a requirement to get tests to pass in rspec. I will try this without nested routes and see if the same problem arises and will also try to see if I can make a patch for this. 

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

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

From mailing_lists at railsnewbie.com  Fri Aug 10 15:14:22 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Fri, 10 Aug 2007 15:14:22 -0400
Subject: [rspec-devel] Autotest + Rails + HEAD/trunk Rspec
In-Reply-To: <57c63afe0708100458s790faa6ek9d640fca365d0e73@mail.gmail.com>
References: <8D604EAC-D544-47C4-9087-3C1007C35184@railsnewbie.com>
	<57c63afe0708100458s790faa6ek9d640fca365d0e73@mail.gmail.com>
Message-ID: <312887D0-375C-4AD0-8449-95A248968F3E@railsnewbie.com>


On Aug 10, 2007, at 7:58 AM, David Chelimsky wrote:

> On 8/10/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> David,
>>
>> I believe you authored the plugin for autotest integration (unless it
>> was Aslak - my apologies then).  Could you give me a hint on how
>> Autotest ends up using the spec command in script/spec instead of the
>> one installed in gems?  Or is this a current bug?
>
> When autotest starts it looks on the path for any file named
> autotest/discover.rb. The one in rspec core tells autotest that if it
> can find a spec directory that it must be rspec. It already knows that
> if it finds config/environment that it must be rails (that's the
> assumption made directly by autotest). It then adds words to a list:
> rspec, rails, camping, etc - depending on what it learns from the
> autotest/discover files and what it discovers.
>
> So in the case of an rspec project, it then looks for a file named
> autotest/rspec.rb, which it finds in rspec core. In the case of an
> rspec/rails project it looks for a file named autotest/rails_rspec.rb,
> which it finds in the rspec_on_rails plugin. These two different files
> define two different spec commands. In fact, the one in trunk in core
> now generates "ruby bin/spec" if it finds "bin/spec", otherwise it
> generates "ruby spec" - that supports using autotest to work on rspec
> directly.
>

Oops.  I should have looked over that part of the autotest class  
again before I sent an email.  I hadn't seen this line:

$:.push(*Dir["vendor/plugins/*/lib"])

I also didn't think that the main part of the Autotest class would  
search vendor/plugins.  I guess rails is considered "the only Ruby app".

Scott





From noreply at rubyforge.org  Fri Aug 10 19:25:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 10 Aug 2007 19:25:30 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12985 ]
	with_block_which_returns(val)
Message-ID: <20070810232530.958F25240C0E@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: with_block_which_returns(val)

Initial Comment:

>From the mailing list:

(me):
Maybe a better example would be in place.  Consider the following
from the Autotest plugin:

Autotest.add_discovery do
   "rspec" if File.exist?('spec')
end

How would you go about testing this?

It's easy enough to test that Autotest receives the method
add_discovery.  But how would you deal with the block?



(David:)
OK - now I'm starting to see. Concrete examples are always helpful.

I guess there's no mocking framework right now that would solve that
for you. What spec do you *wish* you could write?

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

Maybe something like this:

describe Autotest::Rspec "discovery" do
  it "should take a block returns 'rspec' if the file exists" do
    File.stub!(:exists?).and_return true
    Autotest.should_receive(:add_discovery).with_block_which_returns "rspec"
  end
  
  it "should take a block which returns nil if the file does not exist" do
    File.stub!(:exists?).and_return false
    Autotest.should_receive(:add_discovery).with_block_which_returns nil
  end
end


or maybe something like this:

Autotest.should_receive(:add_discovery).with(:val1, :val2).and_block_which_returns "rspec"

I'm open to a less verbose/more terse syntax.


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

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

From noreply at rubyforge.org  Fri Aug 10 20:05:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 10 Aug 2007 20:05:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070811000557.6D97A5240C46@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

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

From noreply at rubyforge.org  Fri Aug 10 23:11:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 10 Aug 2007 23:11:56 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070811031156.554BE5240C5C@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 10:14:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 10:14:51 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13015 ] autotest gives failure in
	'spec_command' after upgrade 1.0.5 to 1.0.6
Message-ID: <20070812141452.181A15240AAE@rubyforge.org>

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

Category: Autotest
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Salgado (digitalronin)
Assigned to: Nobody (None)
Summary: autotest gives failure in 'spec_command' after upgrade 1.0.5 to 1.0.6

Initial Comment:
After upgrading to 1.0.6, installed as a plugin with rails 1.2.2 (frozen into vendor/rails), the 'autotest' command results in the following error

loading autotest/rails_rspec
./vendor/plugins/rspec/lib/autotest/rspec.rb:80:in `spec_command': No spec command could be found! (RspecCommandError)
        from ./vendor/plugins/rspec/lib/autotest/rspec.rb:10:in `initialize'
        from ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:31:in `initialize'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `new'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `run'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/bin/autotest:48
        from /opt/local/bin/autotest:16:in `load'
        from /opt/local/bin/autotest:16

I can make this error go away by doing the following in my rails project;

$ mkdir bin
$ touch bin/spec

After that, everything works fine.

Thank you for releasing rspec, BTW - I love it!

David


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

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

From noreply at rubyforge.org  Sun Aug 12 10:17:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 10:17:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13015 ] autotest gives failure in
	'spec_command' after upgrade 1.0.5 to 1.0.6
Message-ID: <20070812141741.7EBF95240AC2@rubyforge.org>

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

Category: Autotest
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Salgado (digitalronin)
Assigned to: Nobody (None)
Summary: autotest gives failure in 'spec_command' after upgrade 1.0.5 to 1.0.6

Initial Comment:
After upgrading to 1.0.6, installed as a plugin with rails 1.2.2 (frozen into vendor/rails), the 'autotest' command results in the following error

loading autotest/rails_rspec
./vendor/plugins/rspec/lib/autotest/rspec.rb:80:in `spec_command': No spec command could be found! (RspecCommandError)
        from ./vendor/plugins/rspec/lib/autotest/rspec.rb:10:in `initialize'
        from ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:31:in `initialize'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `new'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `run'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/bin/autotest:48
        from /opt/local/bin/autotest:16:in `load'
        from /opt/local/bin/autotest:16

I can make this error go away by doing the following in my rails project;

$ mkdir bin
$ touch bin/spec

After that, everything works fine.

Thank you for releasing rspec, BTW - I love it!

David


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

>Comment By: David Salgado (digitalronin)
Date: 2007-08-12 14:17

Message:
Sorry, forgot to mention, this behaviour occurs on both OSX
10.4.10 and Ubuntu 7.0.4

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

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

From noreply at rubyforge.org  Sun Aug 12 10:52:23 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 10:52:23 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13015 ] autotest gives failure in
	'spec_command' after upgrade 1.0.5 to 1.0.6
Message-ID: <20070812145223.8EF485240AAE@rubyforge.org>

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

Category: Autotest
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Salgado (digitalronin)
>Assigned to: David Chelimsky (dchelimsky)
Summary: autotest gives failure in 'spec_command' after upgrade 1.0.5 to 1.0.6

Initial Comment:
After upgrading to 1.0.6, installed as a plugin with rails 1.2.2 (frozen into vendor/rails), the 'autotest' command results in the following error

loading autotest/rails_rspec
./vendor/plugins/rspec/lib/autotest/rspec.rb:80:in `spec_command': No spec command could be found! (RspecCommandError)
        from ./vendor/plugins/rspec/lib/autotest/rspec.rb:10:in `initialize'
        from ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:31:in `initialize'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `new'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `run'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/bin/autotest:48
        from /opt/local/bin/autotest:16:in `load'
        from /opt/local/bin/autotest:16

I can make this error go away by doing the following in my rails project;

$ mkdir bin
$ touch bin/spec

After that, everything works fine.

Thank you for releasing rspec, BTW - I love it!

David


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 14:52

Message:
Bummer. It works fine as long as you also have an rspec gem installed, but that should not be a requirement.

I'm working on the fix now and will push 1.0.7 shortly.

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

Comment By: David Salgado (digitalronin)
Date: 2007-08-12 14:17

Message:
Sorry, forgot to mention, this behaviour occurs on both OSX
10.4.10 and Ubuntu 7.0.4

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

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

From dchelimsky at gmail.com  Sun Aug 12 11:03:41 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 12 Aug 2007 11:03:41 -0400
Subject: [rspec-devel] 1.0.6 gotcha
Message-ID: <57c63afe0708120803w46fa1761ibf28b6ca3b2d3c2c@mail.gmail.com>

Hi All - I released 1.0.6 this morning, but there is apparently a bug
related to rspec and autotest. I'll be fixing this today (but not
until tonight) so you have two options:

Wait until 1.0.7 (tonight)

Upgrade now to 1.0.6 but make sure you install the rspec gem.

Thanks,
David

From noreply at rubyforge.org  Sun Aug 12 11:05:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 11:05:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070812150540.DCE135240AAE@rubyforge.org>

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

Category: None
Group: None
>Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 12:12:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 12:12:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12701 ] Allow checking of content
	captured with content_for in view specs
Message-ID: <20070812161248.886535240B68@rubyforge.org>

Patches item #12701, was opened at 2007-07-30 23: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: Jens Kr?mer (jkraemer)
Date: 2007-08-12 18:12

Message:
here we go.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-04 15: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 15: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  Sun Aug 12 17:22:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 17:22:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13016 ] [DOC] Point out that view
	specs render, well, a view
Message-ID: <20070812212212.EABD05240B77@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: [DOC] Point out that view specs render, well, a view

Initial Comment:
In retrospect, it's obvious that "render 'people/show'" in a view spec will render the view app/views/people/show.html.erb.  I mean, it would have to.  It couldn't be any other way.  There's no way it can look at the 'show' action for people_controller and divine what template is being rendered, because views are specified independently of controllers.  "render 'people/show'" has nothing to do with the people controller or the show action.  That's a file path, there, is what I'm saying.  Obviously.

Nonetheless, I spent two hours rediscovering this obvious fact, and hence, this patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 17:43:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 17:43:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13017 ] Patch Coming.
Message-ID: <20070812214336.749245240C7F@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Patch Coming.

Initial Comment:
I've already fixed this.  I'll be submitting a patch in a few minutes.

Scott

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

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

From noreply at rubyforge.org  Sun Aug 12 17:44:00 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 17:44:00 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13017 ] Patch Coming.
Message-ID: <20070812214400.49F575240C7F@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Patch Coming.

Initial Comment:
I've already fixed this.  I'll be submitting a patch in a few minutes.

Scott

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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 21:44

Message:
Oops, I posted on the wrong thread.  Close this one.

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

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

From noreply at rubyforge.org  Sun Aug 12 18:00:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 18:00:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070812220009.899975240C7F@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 22:00

Message:

Yes, it does break down, and it is for the following reason:

When the command line Autotest is run, it adds
vendor/plugins/**/lib unto the load path, as well as the
various gems, and then searches the loadpath for
autotest/discover.rb.  

So if RSpec 1.0.6 isn't installed, Autotest will not run at
all in rspec/.

Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins.

I don't think this warrants an emergency 1.0.7 release.


A solution:
I've added a vendor/plugins/rspec symbolic link which links
back to rspec/.  Autotest runs just fine now without the
rspec gem.  

Unfortunately a cleaner solution doesn't seem available or
apparent to me without modifying autotest itself. (I'll look
into doing this in the future)


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 18:31:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 18:31:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070812223118.F30F15240DB0@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:31

Message:
"Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins."

Actually - it also means that rspec/rails users can't use rspec/rails/autotest together without installing the rspec gem. So this is a regression.

I've got a fix in the works and will commit shortly.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 22:00

Message:

Yes, it does break down, and it is for the following reason:

When the command line Autotest is run, it adds
vendor/plugins/**/lib unto the load path, as well as the
various gems, and then searches the loadpath for
autotest/discover.rb.  

So if RSpec 1.0.6 isn't installed, Autotest will not run at
all in rspec/.

Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins.

I don't think this warrants an emergency 1.0.7 release.


A solution:
I've added a vendor/plugins/rspec symbolic link which links
back to rspec/.  Autotest runs just fine now without the
rspec gem.  

Unfortunately a cleaner solution doesn't seem available or
apparent to me without modifying autotest itself. (I'll look
into doing this in the future)


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 18:39:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 18:39:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070812223958.3A0885240DAE@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:39

Message:
Fixed in r2331. 1.0.7 coming soon.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:31

Message:
"Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins."

Actually - it also means that rspec/rails users can't use rspec/rails/autotest together without installing the rspec gem. So this is a regression.

I've got a fix in the works and will commit shortly.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 22:00

Message:

Yes, it does break down, and it is for the following reason:

When the command line Autotest is run, it adds
vendor/plugins/**/lib unto the load path, as well as the
various gems, and then searches the loadpath for
autotest/discover.rb.  

So if RSpec 1.0.6 isn't installed, Autotest will not run at
all in rspec/.

Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins.

I don't think this warrants an emergency 1.0.7 release.


A solution:
I've added a vendor/plugins/rspec symbolic link which links
back to rspec/.  Autotest runs just fine now without the
rspec gem.  

Unfortunately a cleaner solution doesn't seem available or
apparent to me without modifying autotest itself. (I'll look
into doing this in the future)


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 18:48:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 18:48:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070812224826.8FE8E5240DB6@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 06: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: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 07: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 06: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 06: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  Sun Aug 12 18:59:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 18:59:03 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13017 ] Patch Coming.
Message-ID: <20070812225903.51FF75240DB0@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Patch Coming.

Initial Comment:
I've already fixed this.  I'll be submitting a patch in a few minutes.

Scott

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:59

Message:
Closing per Scott's request - wrong thread.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 21:44

Message:
Oops, I posted on the wrong thread.  Close this one.

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

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

From noreply at rubyforge.org  Sun Aug 12 19:00:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 19:00:53 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13016 ] [DOC] Point out that view
	specs render, well, a view
Message-ID: <20070812230053.7FF835240DB6@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: [DOC] Point out that view specs render, well, a view

Initial Comment:
In retrospect, it's obvious that "render 'people/show'" in a view spec will render the view app/views/people/show.html.erb.  I mean, it would have to.  It couldn't be any other way.  There's no way it can look at the 'show' action for people_controller and divine what template is being rendered, because views are specified independently of controllers.  "render 'people/show'" has nothing to do with the people controller or the show action.  That's a file path, there, is what I'm saying.  Obviously.

Nonetheless, I spent two hours rediscovering this obvious fact, and hence, this patch.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 23:00

Message:
Patch please (I see no file attachments)

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

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

From noreply at rubyforge.org  Sun Aug 12 19:05:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 19:05:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070812230539.323F55240DB0@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 23:05

Message:
Two bugs here.  Don't release 1.0.7 yet.  I'll post another
bug fix in a few moments.



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:39

Message:
Fixed in r2331. 1.0.7 coming soon.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:31

Message:
"Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins."

Actually - it also means that rspec/rails users can't use rspec/rails/autotest together without installing the rspec gem. So this is a regression.

I've got a fix in the works and will commit shortly.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 22:00

Message:

Yes, it does break down, and it is for the following reason:

When the command line Autotest is run, it adds
vendor/plugins/**/lib unto the load path, as well as the
various gems, and then searches the loadpath for
autotest/discover.rb.  

So if RSpec 1.0.6 isn't installed, Autotest will not run at
all in rspec/.

Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins.

I don't think this warrants an emergency 1.0.7 release.


A solution:
I've added a vendor/plugins/rspec symbolic link which links
back to rspec/.  Autotest runs just fine now without the
rspec gem.  

Unfortunately a cleaner solution doesn't seem available or
apparent to me without modifying autotest itself. (I'll look
into doing this in the future)


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 19:08:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 19:08:11 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070812230812.153DCA970008@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 23:08

Message:
Too late - already released 1.0.7.

What's the other bug?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 23:05

Message:
Two bugs here.  Don't release 1.0.7 yet.  I'll post another
bug fix in a few moments.



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:39

Message:
Fixed in r2331. 1.0.7 coming soon.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:31

Message:
"Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins."

Actually - it also means that rspec/rails users can't use rspec/rails/autotest together without installing the rspec gem. So this is a regression.

I've got a fix in the works and will commit shortly.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 22:00

Message:

Yes, it does break down, and it is for the following reason:

When the command line Autotest is run, it adds
vendor/plugins/**/lib unto the load path, as well as the
various gems, and then searches the loadpath for
autotest/discover.rb.  

So if RSpec 1.0.6 isn't installed, Autotest will not run at
all in rspec/.

Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins.

I don't think this warrants an emergency 1.0.7 release.


A solution:
I've added a vendor/plugins/rspec symbolic link which links
back to rspec/.  Autotest runs just fine now without the
rspec gem.  

Unfortunately a cleaner solution doesn't seem available or
apparent to me without modifying autotest itself. (I'll look
into doing this in the future)


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 19:13:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 19:13:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070812231358.105E95240DDE@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 02: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: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-12 19:13

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 18:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 03: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 02: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 02: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  Sun Aug 12 19:27:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 19:27:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070812232736.D54535240DBC@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 06: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: David Chelimsky (dchelimsky)
Date: 2007-08-12 23:27

Message:
So how would that work with arity > 1?

obj.should_receive(:msg).and_yield([a,b],[c,d])

Does that mean:
- yield two arrays on the first call
- yield one array each for the first two calls
- yield two args each for the first two calls

This problem doesn't apply to and_return.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-12 23:13

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 07: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 06: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 06: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  Sun Aug 12 20:05:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 20:05:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070813000510.057E45240E24@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 02: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: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-12 20:05

Message:
IMO:

obj.should_receive(:msg).and_yield([a,b],[c,d])

obj.msg # => [a,b]
obj.msg # => [c,d]
obj.msg # => [c,d] # When/if we reach the end, just yield the last one.

Wouldn't that work?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 19:27

Message:
So how would that work with arity > 1?

obj.should_receive(:msg).and_yield([a,b],[c,d])

Does that mean:
- yield two arrays on the first call
- yield one array each for the first two calls
- yield two args each for the first two calls

This problem doesn't apply to and_return.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-12 19:13

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 18:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 03: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 02: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 02: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  Sun Aug 12 20:32:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 20:32:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070813003211.427CB5240E29@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-13 00:32

Message:
So - two bugs:

1. The first documented before.  The fix actually doesn't
work, for two reasons:

a) It should work under Unix/POSIX, but it doesn't look like
applying the patch worked.  The symbolic link which points
vendor/plugins/rspec => rspec isn't there when I check out
trunk (actually no vendor dir is checked out at all)

b) Symbolic links won't work on Windows w/ subversion (see:
http://subversion.tigris.org/)

2. The second bug is the *IMPORTANT* one.  It is the one
which effects end users of Rspec, not developers of Rspec. 
That bug was reported in #13015.  

(I believe) the second bug occurs with the following setup:  

* No rspec gem installed
* a rails project (or other project) with rspec checked out
into vendor/plugins.  When autotest is run, it searches for
spec commands in bin/spec as well as the gem dirs.  Neither
is found (since bin/spec doesn't exist, and rspec's gem
isn't installed).  It then raises an error.  This bug fix
should be as easy as adding script/spec to the list of spec
commands in Autotest::Rspec#spec_commands.



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

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

Message:
Too late - already released 1.0.7.

What's the other bug?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 23:05

Message:
Two bugs here.  Don't release 1.0.7 yet.  I'll post another
bug fix in a few moments.



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:39

Message:
Fixed in r2331. 1.0.7 coming soon.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:31

Message:
"Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins."

Actually - it also means that rspec/rails users can't use rspec/rails/autotest together without installing the rspec gem. So this is a regression.

I've got a fix in the works and will commit shortly.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 22:00

Message:

Yes, it does break down, and it is for the following reason:

When the command line Autotest is run, it adds
vendor/plugins/**/lib unto the load path, as well as the
various gems, and then searches the loadpath for
autotest/discover.rb.  

So if RSpec 1.0.6 isn't installed, Autotest will not run at
all in rspec/.

Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins.

I don't think this warrants an emergency 1.0.7 release.


A solution:
I've added a vendor/plugins/rspec symbolic link which links
back to rspec/.  Autotest runs just fine now without the
rspec gem.  

Unfortunately a cleaner solution doesn't seem available or
apparent to me without modifying autotest itself. (I'll look
into doing this in the future)


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Sun Aug 12 22:39:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 12 Aug 2007 22:39:47 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13020 ]
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	should not be included in helper specs?
Message-ID: <20070813023947.E3E375240E38@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike Vincent (agile)
Assigned to: Nobody (None)
Summary: ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods should not be included in helper specs?

Initial Comment:
1.0.6+ includes additional modules into the helper specs. 

including ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods

causes conflicts in helpers as it redefines several methods, such as << 

def simple_example(name)
  markup = ''
  markup << content_tag(:h1, "hello #{name}")
  markup
end

simple_example('foo').should have_tag('h1', 'foo')


will throw a confusing method missing error from nil about the << method.








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

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

From noreply at rubyforge.org  Mon Aug 13 01:01:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Aug 2007 01:01:42 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070813050142.7B710A970004@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-13 05:01

Message:
Okay - I'm attaching a patch for the second, more important bug.


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-13 00:32

Message:
So - two bugs:

1. The first documented before.  The fix actually doesn't
work, for two reasons:

a) It should work under Unix/POSIX, but it doesn't look like
applying the patch worked.  The symbolic link which points
vendor/plugins/rspec => rspec isn't there when I check out
trunk (actually no vendor dir is checked out at all)

b) Symbolic links won't work on Windows w/ subversion (see:
http://subversion.tigris.org/)

2. The second bug is the *IMPORTANT* one.  It is the one
which effects end users of Rspec, not developers of Rspec. 
That bug was reported in #13015.  

(I believe) the second bug occurs with the following setup:  

* No rspec gem installed
* a rails project (or other project) with rspec checked out
into vendor/plugins.  When autotest is run, it searches for
spec commands in bin/spec as well as the gem dirs.  Neither
is found (since bin/spec doesn't exist, and rspec's gem
isn't installed).  It then raises an error.  This bug fix
should be as easy as adding script/spec to the list of spec
commands in Autotest::Rspec#spec_commands.



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

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

Message:
Too late - already released 1.0.7.

What's the other bug?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 23:05

Message:
Two bugs here.  Don't release 1.0.7 yet.  I'll post another
bug fix in a few moments.



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:39

Message:
Fixed in r2331. 1.0.7 coming soon.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:31

Message:
"Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins."

Actually - it also means that rspec/rails users can't use rspec/rails/autotest together without installing the rspec gem. So this is a regression.

I've got a fix in the works and will commit shortly.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 22:00

Message:

Yes, it does break down, and it is for the following reason:

When the command line Autotest is run, it adds
vendor/plugins/**/lib unto the load path, as well as the
various gems, and then searches the loadpath for
autotest/discover.rb.  

So if RSpec 1.0.6 isn't installed, Autotest will not run at
all in rspec/.

Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins.

I don't think this warrants an emergency 1.0.7 release.


A solution:
I've added a vendor/plugins/rspec symbolic link which links
back to rspec/.  Autotest runs just fine now without the
rspec gem.  

Unfortunately a cleaner solution doesn't seem available or
apparent to me without modifying autotest itself. (I'll look
into doing this in the future)


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From noreply at rubyforge.org  Mon Aug 13 01:16:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Aug 2007 01:16:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12986 ] Autotest Specs + Refactoring
Message-ID: <20070813051617.4BFBC5240E68@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: David Chelimsky (dchelimsky)
Summary: Autotest Specs + Refactoring

Initial Comment:

David,

I've finally finished the Autotest specs.  I had to do some refactoring to spec it out.


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-13 05:16

Message:
Hey Scott - I already fixed this bug in r2331 (see http://rubyforge.org/tracker/?func=detail&group_id=797&aid=13015&atid=3149). "script/spec" is specific to rspec_on_rails, so it gets handled in rails_rspec.rb (in the rspec_on_rails plugin) rather than core.

The only open issue is related to the original issue, which is that if there is no rspec gem installed, you can't run autotest against a non-rails project (including rspec itself).

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-13 05:01

Message:
Okay - I'm attaching a patch for the second, more important bug.


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-13 00:32

Message:
So - two bugs:

1. The first documented before.  The fix actually doesn't
work, for two reasons:

a) It should work under Unix/POSIX, but it doesn't look like
applying the patch worked.  The symbolic link which points
vendor/plugins/rspec => rspec isn't there when I check out
trunk (actually no vendor dir is checked out at all)

b) Symbolic links won't work on Windows w/ subversion (see:
http://subversion.tigris.org/)

2. The second bug is the *IMPORTANT* one.  It is the one
which effects end users of Rspec, not developers of Rspec. 
That bug was reported in #13015.  

(I believe) the second bug occurs with the following setup:  

* No rspec gem installed
* a rails project (or other project) with rspec checked out
into vendor/plugins.  When autotest is run, it searches for
spec commands in bin/spec as well as the gem dirs.  Neither
is found (since bin/spec doesn't exist, and rspec's gem
isn't installed).  It then raises an error.  This bug fix
should be as easy as adding script/spec to the list of spec
commands in Autotest::Rspec#spec_commands.



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

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

Message:
Too late - already released 1.0.7.

What's the other bug?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 23:05

Message:
Two bugs here.  Don't release 1.0.7 yet.  I'll post another
bug fix in a few moments.



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:39

Message:
Fixed in r2331. 1.0.7 coming soon.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 22:31

Message:
"Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins."

Actually - it also means that rspec/rails users can't use rspec/rails/autotest together without installing the rspec gem. So this is a regression.

I've got a fix in the works and will commit shortly.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-12 22:00

Message:

Yes, it does break down, and it is for the following reason:

When the command line Autotest is run, it adds
vendor/plugins/**/lib unto the load path, as well as the
various gems, and then searches the loadpath for
autotest/discover.rb.  

So if RSpec 1.0.6 isn't installed, Autotest will not run at
all in rspec/.

Luckily, this is only a bug which affects development of
RSpec itself, with the addition stipulation that the rspec
gem isn't installed.  Any other project will either assume
rspec is installed, or it will have rspec on externals in
vendor/plugins.

I don't think this warrants an emergency 1.0.7 release.


A solution:
I've added a vendor/plugins/rspec symbolic link which links
back to rspec/.  Autotest runs just fine now without the
rspec gem.  

Unfortunately a cleaner solution doesn't seem available or
apparent to me without modifying autotest itself. (I'll look
into doing this in the future)


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 15:05

Message:
Scott - unfortunately, this breaks down if you don't have the rspec gem installed.

I have to head out for the day so I can't fix this until tonight. If you happen to see this and have time today, it would rock if you would uninstall your rspec gem and get this to work and submit a new patch (against the current trunk).

If you can do that I'll apply tonight. If not, I'll fix it myself. Unfortunately, I released this and need to do a follow up release that works as soon as possible.

Thanks,
David

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

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

Message:
Applied to r2326.

Excellent patch.

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

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

From dchelimsky at gmail.com  Mon Aug 13 01:58:42 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 13 Aug 2007 01:58:42 -0400
Subject: [rspec-devel] [ANN] RSpec-1.0.8
Message-ID: <57c63afe0708122258r6ae4494cld9353dc135c00c94@mail.gmail.com>

The RSpec Development Team is pleased to announce the release of RSpec-1.0.8.

RSpec 1.0.6 is the "holy cow, batman, it's been a long time since we
released and there are a ton of bug fixes, patches and even new
features" release. RSpec 1.0.7 and 1.0.8 deal with a regression
introduced in 1.0.6 and a hiccup in releasing 1.0.7, respectively.

== RSpec

RSpec is a Behaviour Driven Development framework which plays the same
role that a unit testing framework would play in Test Driven
Development, but does so using words and structures that better
support BDD.

http://rspec.rubyforge.org

== rspec_on_rails

rspec_on_rails is a Ruby on Rails plugin that supports a BDD approach
to developing the various layers of objects within a Rails
application.

See http://rspec.rubyforge.org/documentation/rails/index.html

== Installation

http://rspec.rubyforge.org/download.html
http://rspec.rubyforge.org/documentation/rails/install.html

From noreply at rubyforge.org  Mon Aug 13 11:17:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Aug 2007 11:17:42 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13016 ] [DOC] Point out that view
	specs render, well, a view
Message-ID: <20070813151743.0BF545240B0B@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: [DOC] Point out that view specs render, well, a view

Initial Comment:
In retrospect, it's obvious that "render 'people/show'" in a view spec will render the view app/views/people/show.html.erb.  I mean, it would have to.  It couldn't be any other way.  There's no way it can look at the 'show' action for people_controller and divine what template is being rendered, because views are specified independently of controllers.  "render 'people/show'" has nothing to do with the people controller or the show action.  That's a file path, there, is what I'm saying.  Obviously.

Nonetheless, I spent two hours rediscovering this obvious fact, and hence, this patch.

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

>Comment By: Jay Levitt (jaylev)
Date: 2007-08-13 11:17

Message:
Oops.  Missed that little checkmark.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 19:00

Message:
Patch please (I see no file attachments)

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

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

From noreply at rubyforge.org  Mon Aug 13 16:47:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Aug 2007 16:47:50 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13015 ] autotest gives failure in
	'spec_command' after upgrade 1.0.5 to 1.0.6
Message-ID: <20070813204750.E2FFF5240C6E@rubyforge.org>

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

Category: Autotest
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Salgado (digitalronin)
Assigned to: David Chelimsky (dchelimsky)
Summary: autotest gives failure in 'spec_command' after upgrade 1.0.5 to 1.0.6

Initial Comment:
After upgrading to 1.0.6, installed as a plugin with rails 1.2.2 (frozen into vendor/rails), the 'autotest' command results in the following error

loading autotest/rails_rspec
./vendor/plugins/rspec/lib/autotest/rspec.rb:80:in `spec_command': No spec command could be found! (RspecCommandError)
        from ./vendor/plugins/rspec/lib/autotest/rspec.rb:10:in `initialize'
        from ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:31:in `initialize'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `new'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `run'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/bin/autotest:48
        from /opt/local/bin/autotest:16:in `load'
        from /opt/local/bin/autotest:16

I can make this error go away by doing the following in my rails project;

$ mkdir bin
$ touch bin/spec

After that, everything works fine.

Thank you for releasing rspec, BTW - I love it!

David


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-13 20:47

Message:
Looks like you can close this one, david.  Thanks for the bug fixes.

Scott


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 14:52

Message:
Bummer. It works fine as long as you also have an rspec gem installed, but that should not be a requirement.

I'm working on the fix now and will push 1.0.7 shortly.

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

Comment By: David Salgado (digitalronin)
Date: 2007-08-12 14:17

Message:
Sorry, forgot to mention, this behaviour occurs on both OSX
10.4.10 and Ubuntu 7.0.4

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

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

From noreply at rubyforge.org  Mon Aug 13 17:56:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Aug 2007 17:56:53 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13015 ] autotest gives failure in
	'spec_command' after upgrade 1.0.5 to 1.0.6
Message-ID: <20070813215653.950D65240C25@rubyforge.org>

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

Category: Autotest
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: David Salgado (digitalronin)
Assigned to: David Chelimsky (dchelimsky)
Summary: autotest gives failure in 'spec_command' after upgrade 1.0.5 to 1.0.6

Initial Comment:
After upgrading to 1.0.6, installed as a plugin with rails 1.2.2 (frozen into vendor/rails), the 'autotest' command results in the following error

loading autotest/rails_rspec
./vendor/plugins/rspec/lib/autotest/rspec.rb:80:in `spec_command': No spec command could be found! (RspecCommandError)
        from ./vendor/plugins/rspec/lib/autotest/rspec.rb:10:in `initialize'
        from ./vendor/plugins/rspec_on_rails/lib/autotest/rails_rspec.rb:31:in `initialize'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `new'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/lib/autotest.rb:123:in `run'
        from /opt/local/lib/ruby/gems/1.8/gems/ZenTest-3.6.1/bin/autotest:48
        from /opt/local/bin/autotest:16:in `load'
        from /opt/local/bin/autotest:16

I can make this error go away by doing the following in my rails project;

$ mkdir bin
$ touch bin/spec

After that, everything works fine.

Thank you for releasing rspec, BTW - I love it!

David


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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-13 20:47

Message:
Looks like you can close this one, david.  Thanks for the bug fixes.

Scott


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 14:52

Message:
Bummer. It works fine as long as you also have an rspec gem installed, but that should not be a requirement.

I'm working on the fix now and will push 1.0.7 shortly.

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

Comment By: David Salgado (digitalronin)
Date: 2007-08-12 14:17

Message:
Sorry, forgot to mention, this behaviour occurs on both OSX
10.4.10 and Ubuntu 7.0.4

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

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

From noreply at rubyforge.org  Mon Aug 13 21:32:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Aug 2007 21:32:24 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13039 ] exceptions in views give a noisy
	stack trace
Message-ID: <20070814013224.E58C55240CB8@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: exceptions in views give a noisy stack trace

Initial Comment:
# spec/views/bad_spec.rb
require File.dirname(__FILE__) + '/../../spec_helper'

describe "test" do
  it "test" do
    m = mock("test")
    assigns[:m] = m
    render '/users/test'
  end
end

# app/views/user/test.html.erb
<% @m.blah %>

Result: The stack trace isn't cleaned by backtrace_tweaker, because instead of e.backtrace being an array of strings, each with one line, it's an array with one element - all the lines of the backtrace concatenated with "\n" separators.

I cannot figure out where this is happening.  The exception as re-raised by ActionView::Base#render_file still has a proper array, but by the time it gets to Spec::DSL::Example#run_example, it's a single-element array.  I don't know enough about exceptions to know how to find every rescue/re-raise of the exception...



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

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

From noreply at rubyforge.org  Mon Aug 13 22:06:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 13 Aug 2007 22:06:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13039 ] exceptions in views give a noisy
	stack trace
Message-ID: <20070814020604.BD6A05240C27@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: exceptions in views give a noisy stack trace

Initial Comment:
# spec/views/bad_spec.rb
require File.dirname(__FILE__) + '/../../spec_helper'

describe "test" do
  it "test" do
    m = mock("test")
    assigns[:m] = m
    render '/users/test'
  end
end

# app/views/user/test.html.erb
<% @m.blah %>

Result: The stack trace isn't cleaned by backtrace_tweaker, because instead of e.backtrace being an array of strings, each with one line, it's an array with one element - all the lines of the backtrace concatenated with "\n" separators.

I cannot figure out where this is happening.  The exception as re-raised by ActionView::Base#render_file still has a proper array, but by the time it gets to Spec::DSL::Example#run_example, it's a single-element array.  I don't know enough about exceptions to know how to find every rescue/re-raise of the exception...



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

>Comment By: Jay Levitt (jaylev)
Date: 2007-08-13 22:06

Message:
OK, a little set_trace_func and now I get it.  When
ActionView::Base#render_file reraises the exception, it's
actually setting the backtrace to template_source, which I
guess must come from ERB, and which is newline-separated. 
However, it changes the exception type to TemplateError, and
stashes the original exception in e.original_exception.

So we could do a few things:

1. Parse the newlines out if this is a TemplateError.
2. Look at e.original_exception.backtrace instead of
e.backtrace if this is a TemplateError.
3. Some combination of the two.  That'd only be necessary if
the two backtraces could ever differ; I have no idea if that
could happen or not.

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

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

From noreply at rubyforge.org  Tue Aug 14 14:12:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 14:12:07 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070814181207.EF9B95240B17@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

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

From noreply at rubyforge.org  Tue Aug 14 14:28:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 14:28:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070814182821.39FB55240A1B@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 14:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Tue Aug 14 14:45:02 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 14:45:02 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070814184502.5B1725240B53@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

>Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 18:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Tue Aug 14 14:47:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 14:47:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070814184748.7CA965240A1B@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

>Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 18:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Tue Aug 14 14:55:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 14:55:52 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070814185552.770965240A9F@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

>Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:55

Message:
Here is a diff. It may not have included the route. If not, add   "map.connect 
'custom_route', :controller => 'custom_route_spec', :action => 'custom_route'" 
to the example_rails_app routes.rb file. I don't know if I can figure out where the 
error is, any help would be appreciated, but I will try.

JD



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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 18:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Tue Aug 14 15:42:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 15:42:56 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070814194256.53D0E5240B17@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

>Comment By: James Deville (parcelbrat)
Date: 2007-08-14 19:42

Message:
ActionController::Routing::Routes.named_rotes.install(self.class) inside of a ruby 
debug instance (thus inside of an Example) appears to fix this. I'm looking where 
to put that now.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:55

Message:
Here is a diff. It may not have included the route. If not, add   "map.connect 
'custom_route', :controller => 'custom_route_spec', :action => 'custom_route'" 
to the example_rails_app routes.rb file. I don't know if I can figure out where the 
error is, any help would be appreciated, but I will try.

JD



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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 18:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Tue Aug 14 16:15:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 16:15:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070814201520.AD28F5240B3E@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

>Comment By: James Deville (parcelbrat)
Date: 2007-08-14 20:15

Message:
Adding 'ActionController::Routing::Routes.named_routes.install(self.class) to line 
64 of rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb fixes this issue in 
my project, but not in the test I added. I'm unsure why they are differing.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 19:42

Message:
ActionController::Routing::Routes.named_rotes.install(self.class) inside of a ruby 
debug instance (thus inside of an Example) appears to fix this. I'm looking where 
to put that now.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:55

Message:
Here is a diff. It may not have included the route. If not, add   "map.connect 
'custom_route', :controller => 'custom_route_spec', :action => 'custom_route'" 
to the example_rails_app routes.rb file. I don't know if I can figure out where the 
error is, any help would be appreciated, but I will try.

JD



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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 18:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Tue Aug 14 16:30:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 16:30:31 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070814203031.8A3D05240BC5@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

>Comment By: James Deville (parcelbrat)
Date: 2007-08-14 20:30

Message:
Never mind that. The svn revert going on in pre_commit was making my tests 
fail, because it removed my named_route.

 I'm attaching a diff that will fix it, but to make the tests work you need to 
add   map.named '/named_route', :controller => 'people', :action => 'index' 
to config/routes.rb. This needs to be added to the route.rb, which is getting 
reverted via a svn revert. I get a pass on the first time and a fail on the other 
times.


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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 20:15

Message:
Adding 'ActionController::Routing::Routes.named_routes.install(self.class) to line 
64 of rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb fixes this issue in 
my project, but not in the test I added. I'm unsure why they are differing.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 19:42

Message:
ActionController::Routing::Routes.named_rotes.install(self.class) inside of a ruby 
debug instance (thus inside of an Example) appears to fix this. I'm looking where 
to put that now.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:55

Message:
Here is a diff. It may not have included the route. If not, add   "map.connect 
'custom_route', :controller => 'custom_route_spec', :action => 'custom_route'" 
to the example_rails_app routes.rb file. I don't know if I can figure out where the 
error is, any help would be appreciated, but I will try.

JD



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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 18:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Tue Aug 14 19:43:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 14 Aug 2007 19:43:50 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13078 ] Develop rspec with autotest
	[TINY]
Message-ID: <20070814234351.1A1855240D7E@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Develop rspec with autotest [TINY]

Initial Comment:
David,

Ok - here is the solution to developing rspec w/ autotest.  2 lines of code.

Scott


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

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

From noreply at rubyforge.org  Wed Aug 15 00:34:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 15 Aug 2007 00:34:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070815043428.18E905240DD2@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: James Deville (parcelbrat)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-15 04:34

Message:
Fixed in 2348 - I received two patches that both do essentially the same fix - one here from you and one from Mike Mangino so I added you both in the contributors list.

Thanks for getting this to work - a lot of people have been looking for this.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 20:30

Message:
Never mind that. The svn revert going on in pre_commit was making my tests 
fail, because it removed my named_route.

 I'm attaching a diff that will fix it, but to make the tests work you need to 
add   map.named '/named_route', :controller => 'people', :action => 'index' 
to config/routes.rb. This needs to be added to the route.rb, which is getting 
reverted via a svn revert. I get a pass on the first time and a fail on the other 
times.


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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 20:15

Message:
Adding 'ActionController::Routing::Routes.named_routes.install(self.class) to line 
64 of rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb fixes this issue in 
my project, but not in the test I added. I'm unsure why they are differing.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 19:42

Message:
ActionController::Routing::Routes.named_rotes.install(self.class) inside of a ruby 
debug instance (thus inside of an Example) appears to fix this. I'm looking where 
to put that now.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:55

Message:
Here is a diff. It may not have included the route. If not, add   "map.connect 
'custom_route', :controller => 'custom_route_spec', :action => 'custom_route'" 
to the example_rails_app routes.rb file. I don't know if I can figure out where the 
error is, any help would be appreciated, but I will try.

JD



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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 18:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Wed Aug 15 00:51:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 15 Aug 2007 00:51:07 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13078 ] Develop rspec with autotest
	[TINY]
Message-ID: <20070815045107.6E3515240DD9@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Develop rspec with autotest [TINY]

Initial Comment:
David,

Ok - here is the solution to developing rspec w/ autotest.  2 lines of code.

Scott


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-15 04:51

Message:
Applied to r2349.

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

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

From noreply at rubyforge.org  Wed Aug 15 00:54:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 15 Aug 2007 00:54:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13016 ] [DOC] Point out that view
	specs render, well, a view
Message-ID: <20070815045448.2CC365240DD9@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jay Levitt (jaylev)
>Assigned to: David Chelimsky (dchelimsky)
Summary: [DOC] Point out that view specs render, well, a view

Initial Comment:
In retrospect, it's obvious that "render 'people/show'" in a view spec will render the view app/views/people/show.html.erb.  I mean, it would have to.  It couldn't be any other way.  There's no way it can look at the 'show' action for people_controller and divine what template is being rendered, because views are specified independently of controllers.  "render 'people/show'" has nothing to do with the people controller or the show action.  That's a file path, there, is what I'm saying.  Obviously.

Nonetheless, I spent two hours rediscovering this obvious fact, and hence, this patch.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-15 04:54

Message:
Applied to r2350

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

Comment By: Jay Levitt (jaylev)
Date: 2007-08-13 15:17

Message:
Oops.  Missed that little checkmark.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 23:00

Message:
Patch please (I see no file attachments)

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

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

From srinivas.aki at gmail.com  Wed Aug 15 01:01:46 2007
From: srinivas.aki at gmail.com (Srinivas Aki)
Date: Tue, 14 Aug 2007 22:01:46 -0700
Subject: [rspec-devel] [ rspec-Patches-13016 ] [DOC] Point out that view
	specs render, well, a view
In-Reply-To: <20070815045448.2CC365240DD9@rubyforge.org>
References: <20070815045448.2CC365240DD9@rubyforge.org>
Message-ID: <8D173942-AC63-436C-A88A-65FF0E7A2E50@gmail.com>

ippudu busy aa

On Aug 14, 2007, at 9:54 PM, <noreply at rubyforge.org>  wrote:

> Patches item #13016, was opened at 2007-08-12 21:22
> You can respond by visiting:
> http://rubyforge.org/tracker/? 
> func=detail&atid=3151&aid=13016&group_id=797
>
> Category: rails plugin
> Group: None
>> Status: Closed
>> Resolution: Accepted
> Priority: 3
> Submitted By: Jay Levitt (jaylev)
>> Assigned to: David Chelimsky (dchelimsky)
> Summary: [DOC] Point out that view specs render, well, a view
>
> Initial Comment:
> In retrospect, it's obvious that "render 'people/show'" in a view  
> spec will render the view app/views/people/show.html.erb.  I mean,  
> it would have to.  It couldn't be any other way.  There's no way it  
> can look at the 'show' action for people_controller and divine what  
> template is being rendered, because views are specified  
> independently of controllers.  "render 'people/show'" has nothing  
> to do with the people controller or the show action.  That's a file  
> path, there, is what I'm saying.  Obviously.
>
> Nonetheless, I spent two hours rediscovering this obvious fact, and  
> hence, this patch.
>
> ----------------------------------------------------------------------
>
>> Comment By: David Chelimsky (dchelimsky)
> Date: 2007-08-15 04:54
>
> Message:
> Applied to r2350
>
> ----------------------------------------------------------------------
>
> Comment By: Jay Levitt (jaylev)
> Date: 2007-08-13 15:17
>
> Message:
> Oops.  Missed that little checkmark.
>
> ----------------------------------------------------------------------
>
> Comment By: David Chelimsky (dchelimsky)
> Date: 2007-08-12 23:00
>
> Message:
> Patch please (I see no file attachments)
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> http://rubyforge.org/tracker/? 
> func=detail&atid=3151&aid=13016&group_id=797
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From noreply at rubyforge.org  Wed Aug 15 06:36:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 15 Aug 2007 06:36:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-10645 ] removal of --examples when
	appropriate
Message-ID: <20070815103620.2B1DD5240964@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: removal of --examples when appropriate

Initial Comment:

See ticket: #10545	

"Removal of --options when appropriate"

http://rubyforge.org/tracker/index.php?func=detail&aid=10545&group_id=797&atid=3151


David/Aslak: I added a an attribute reader for @where in the base text formatter, and called the method output.  Feel free to change this as you wish.  It is only referenced in the Options class, under the method I've added: remove_extraneous_examples!



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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-15 10:36

Message:
Admins: 

Please reject this one - I no longer need it, and I don't
think anyone else cares. 

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-18 15:22

Message:
Here is the simple solution you were looking for, Aslak. 
I've attached it as patch3.diff

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-05-27 04:55

Message:
Feel free to close this one.  The last patch doesn't do what
I thought it did (Obviously I should have included specs).

I don't know a good way to get around the problem except by
implementing some logic similar to what I have done in the
first patch.  It can be cleaned up a bit, but otherwise I
don't see a way to do it simply & cleanly.  Let me know if
you have any other ideas.  Otherwise, reject it.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-05-11 22:31

Message:
Well, now that I look at it, it appears as though it isn't
that simple, because if you want the example switch to touch
the file, it *needs to know* that it is a file, and not a
simple example (this is why there was the complicated logic
in my patch).

On the other hand, the --formatter switch does touch the file.  

So the bug looks like it only occurs when you specify
--examples before --formatter, because ::OptionParser parses
options sequentially, as they are given on the command line.

I've opted for a low-tech solution (in this version of the
patch), so that --help will specify that --examples should
come after the corresponding formatter.

Another low-tech solution exists, of course, and that would
be to have an --example switch which only processes named
examples, and an --example-file switch which would process a
 formatted file.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-05-10 20:01

Message:
I agree, Aslak.  Although I don't think touch would be the
appropriate thing to use here, because it modifies the
mtimes, and that would be a problem for autotest.  

I'll rework the code.

btw: thanks for applying the other patch

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-05-10 13:41

Message:
I'm not so keen on applying this. It seems like a complicated solution to a simple problem. An easier solution is this:

$ touch previous_failures.txt

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

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

From noreply at rubyforge.org  Wed Aug 15 06:50:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 15 Aug 2007 06:50:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-10645 ] removal of --examples when
	appropriate
Message-ID: <20070815105021.B84BF5240A25@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: removal of --examples when appropriate

Initial Comment:

See ticket: #10545	

"Removal of --options when appropriate"

http://rubyforge.org/tracker/index.php?func=detail&aid=10545&group_id=797&atid=3151


David/Aslak: I added a an attribute reader for @where in the base text formatter, and called the method output.  Feel free to change this as you wish.  It is only referenced in the Options class, under the method I've added: remove_extraneous_examples!



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-15 10:50

Message:
Closing per poster.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-15 10:36

Message:
Admins: 

Please reject this one - I no longer need it, and I don't
think anyone else cares. 

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-18 15:22

Message:
Here is the simple solution you were looking for, Aslak. 
I've attached it as patch3.diff

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-05-27 04:55

Message:
Feel free to close this one.  The last patch doesn't do what
I thought it did (Obviously I should have included specs).

I don't know a good way to get around the problem except by
implementing some logic similar to what I have done in the
first patch.  It can be cleaned up a bit, but otherwise I
don't see a way to do it simply & cleanly.  Let me know if
you have any other ideas.  Otherwise, reject it.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-05-11 22:31

Message:
Well, now that I look at it, it appears as though it isn't
that simple, because if you want the example switch to touch
the file, it *needs to know* that it is a file, and not a
simple example (this is why there was the complicated logic
in my patch).

On the other hand, the --formatter switch does touch the file.  

So the bug looks like it only occurs when you specify
--examples before --formatter, because ::OptionParser parses
options sequentially, as they are given on the command line.

I've opted for a low-tech solution (in this version of the
patch), so that --help will specify that --examples should
come after the corresponding formatter.

Another low-tech solution exists, of course, and that would
be to have an --example switch which only processes named
examples, and an --example-file switch which would process a
 formatted file.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-05-10 20:01

Message:
I agree, Aslak.  Although I don't think touch would be the
appropriate thing to use here, because it modifies the
mtimes, and that would be a problem for autotest.  

I'll rework the code.

btw: thanks for applying the other patch

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-05-10 13:41

Message:
I'm not so keen on applying this. It seems like a complicated solution to a simple problem. An easier solution is this:

$ touch previous_failures.txt

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

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

From noreply at rubyforge.org  Wed Aug 15 11:05:00 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 15 Aug 2007 11:05:00 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13098 ] Error running
	"script/spec_server" after upgrading from 1.0.5 to 1.0.8
Message-ID: <20070815150500.9D4EF5240A63@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike Breen (hardbap)
Assigned to: Nobody (None)
Summary: Error running "script/spec_server" after upgrading from 1.0.5 to 1.0.8

Initial Comment:
RSpec version 1.0.8
Rails version 1.2.3
ruby 1.8.5

Windows XP SP 2
I do not have TextMate installed but I am using the Windows clone eText version 1.1.135beta

After upgrading to rspec version 1.0.8 I get this error when I attempt to start the spec_server at the command line with "ruby script/spec_server":

script/spec_server:9: undefined method '+' for nil:NilClass (NoMethodError)


The code from script/spec_server causing the issue can be found on lines 9-13:

...

specmate = ENV['HOME'] + "/Library/Application\Support/TextMate/Bundles/RSpec.tmbundle/Support/lib"
if File.directory?(specmate)
  $LOAD_PATH.unshift(specmate) 
  require 'text_mate_formatter'
end

...

Please note: script/spec_server will start normally after removing this code.

I understand that this is a Windows environment issue but I thought the team would like to be aware of it anyway.

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

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

From dan at tastapod.com  Wed Aug 15 15:36:16 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 15 Aug 2007 20:36:16 +0100
Subject: [rspec-devel] confusion with rspec mocks
Message-ID: <46C355B0.4000905@tastapod.com>

Hi folks.

I'm nearly there with the initial cut of Spec::Story. I have one example 
failing with an odd error from the rspec mock framework.

I moved #with from MessageExpectation into BaseExpectation so I could 
stub!(:something).with(args). I have:

  
story_runner.stub!(:add_listener).with(an_instance_of(Reporter::PlainTextReporter))
  ...
  
story_runner.should_receive(:add_listener).with(an_instance_of(Documenter::PlainTextDocumenter))

The example fails with:

Mock 'scenario runner' expected :add_listener with (no args) but 
received it with (#<Spec::Story::Reporter::PlainTextReporter:0xb777a83c 
@pending=[], @succeeded=0, @failed=[], @out=#<IO:0xb77823c0>>)
./spec/spec/story/runner_spec.rb:61:

If I change the stub!(...) to should_receive(...) it fails with:

Mock 'story runner' expected :add_listener with (no args) once, but 
received it 0 times
./spec/spec/story/runner_spec.rb:57:

In both cases it seems the args checking is being lost somewhere.

Can anyone shed any light?

Thanks,
Dan


From dchelimsky at gmail.com  Wed Aug 15 16:41:36 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 15 Aug 2007 16:41:36 -0400
Subject: [rspec-devel] confusion with rspec mocks
In-Reply-To: <46C355B0.4000905@tastapod.com>
References: <46C355B0.4000905@tastapod.com>
Message-ID: <57c63afe0708151341i5e62c7a6s10e6e3731dba9dbc@mail.gmail.com>

On 8/15/07, Dan North <dan at tastapod.com> wrote:
> Hi folks.
>
> I'm nearly there with the initial cut of Spec::Story. I have one example
> failing with an odd error from the rspec mock framework.
>
> I moved #with from MessageExpectation into BaseExpectation so I could
> stub!(:something).with(args).

That was a deliberate design choice - I don't believe stubs should
care about args - if you care about args, then you want should_receive
(because it's an expectation).

> I have:
>
>
> story_runner.stub!(:add_listener).with(an_instance_of(Reporter::PlainTextReporter))
>   ...
>
> story_runner.should_receive(:add_listener).with(an_instance_of(Documenter::PlainTextDocumenter))
>
> The example fails with:
>
> Mock 'scenario runner' expected :add_listener with (no args) but
> received it with (#<Spec::Story::Reporter::PlainTextReporter:0xb777a83c
> @pending=[], @succeeded=0, @failed=[], @out=#<IO:0xb77823c0>>)
> ./spec/spec/story/runner_spec.rb:61:
>
> If I change the stub!(...) to should_receive(...) it fails with:
>
> Mock 'story runner' expected :add_listener with (no args) once, but
> received it 0 times
> ./spec/spec/story/runner_spec.rb:57:
>
> In both cases it seems the args checking is being lost somewhere.

I can't explain this off-hand, but if you move :with back, does it
work w/ should_receive?

>
> Can anyone shed any light?
>
> Thanks,
> Dan
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dan at tastapod.com  Wed Aug 15 18:11:08 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 15 Aug 2007 23:11:08 +0100
Subject: [rspec-devel] confusion with rspec mocks
In-Reply-To: <57c63afe0708151341i5e62c7a6s10e6e3731dba9dbc@mail.gmail.com>
References: <46C355B0.4000905@tastapod.com>
	<57c63afe0708151341i5e62c7a6s10e6e3731dba9dbc@mail.gmail.com>
Message-ID: <46C379FC.2040204@tastapod.com>

David Chelimsky wrote:
> On 8/15/07, Dan North <dan at tastapod.com> wrote:
>   
>> Hi folks.
>>
>> I'm nearly there with the initial cut of Spec::Story. I have one example
>> failing with an odd error from the rspec mock framework.
>>
>> I moved #with from MessageExpectation into BaseExpectation so I could
>> stub!(:something).with(args).
>>     
>
> That was a deliberate design choice - I don't believe stubs should
> care about args - if you care about args, then you want should_receive
> (because it's an expectation).
>   
It's useful for when I want to say I care about the mock receiving 
eat("cheese") and I'm aware that it will also receive eat("pickle") but 
I don't care (i.e. that's not the intent of the example). But I /want/ 
the example to fail if suddenly the object starts to eat("wood") because 
I might need to think about how it affects the behaviour.

I suppose you could just stub!(:eat) and then 
should_receive(:eat).with("cheese"), but sometimes I want to be more 
explicit than that.

Also, the #with method doesn't feel right alongside all the counter 
methods (once, twice, never, etc). I guess I've become used to having 
matchable args on stubs because jmock and mocha both support this.
>   
>> In both cases it seems the args checking is being lost somewhere.
>>     
>
> I can't explain this off-hand, but if you move :with back, does it
> work w/ should_receive?
>   
No, it wasn't working with stub!(:add_listener), which is when I 
discovered that I couldn't filter on the args in the stub and I moved 
the with() method.

I just reverted the #with change to revive the original error and got this:

    Mock 'story runner' expected :add_listener with (no args) once, but
    received it 0 times
    ./spec/spec/story/runner_spec.rb:57:


(I checked in the reverted version.)

Thanks for getting back so quickly, David.

Cheers,
Dan

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

From noreply at rubyforge.org  Wed Aug 15 23:05:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 15 Aug 2007 23:05:37 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13118 ] Rinda support for
	Spec::Distributed
Message-ID: <20070816030539.5D84E5240CA8@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Rinda support for Spec::Distributed

Initial Comment:
Auto discovery and tuplespace partitioning. Added a few specs.

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

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

From dchelimsky at gmail.com  Wed Aug 15 23:38:09 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 15 Aug 2007 23:38:09 -0400
Subject: [rspec-devel] confusion with rspec mocks
In-Reply-To: <46C379FC.2040204@tastapod.com>
References: <46C355B0.4000905@tastapod.com>
	<57c63afe0708151341i5e62c7a6s10e6e3731dba9dbc@mail.gmail.com>
	<46C379FC.2040204@tastapod.com>
Message-ID: <57c63afe0708152038r67dca83ajc29904491aebd538@mail.gmail.com>

On 8/15/07, Dan North <dan at tastapod.com> wrote:
>
>  David Chelimsky wrote:
>  On 8/15/07, Dan North <dan at tastapod.com> wrote:
>
>  Hi folks.
>
> I'm nearly there with the initial cut of Spec::Story. I have one example
> failing with an odd error from the rspec mock framework.
>
> I moved #with from MessageExpectation into BaseExpectation so I could
> stub!(:something).with(args).
>
>  That was a deliberate design choice - I don't believe stubs should
> care about args - if you care about args, then you want should_receive
> (because it's an expectation).
>
>  It's useful for when I want to say I care about the mock receiving
> eat("cheese") and I'm aware that it will also receive eat("pickle") but I
> don't care (i.e. that's not the intent of the example). But I want the
> example to fail if suddenly the object starts to eat("wood") because I might
> need to think about how it affects the behaviour.
>
>  I suppose you could just stub!(:eat) and then
> should_receive(:eat).with("cheese"), but sometimes I want
> to be more explicit than that.
>
>  Also, the #with method doesn't feel right alongside all the counter methods
> (once, twice, never, etc). I guess I've become used to having matchable args
> on stubs because jmock and mocha both support this.
>
>  In both cases it seems the args checking is being lost somewhere.
>
>  I can't explain this off-hand, but if you move :with back, does it
> work w/ should_receive?
>
>  No, it wasn't working with stub!(:add_listener), which is when I discovered
> that I couldn't filter on the args in the stub and I moved the with()
> method.
>
>  I just reverted the #with change to revive the original error and got this:
>
> Mock 'story runner' expected :add_listener with (no args) once, but received
> it 0 times
>  ./spec/spec/story/runner_spec.rb:57:
>
>  (I checked in the reverted version.)
>
>  Thanks for getting back so quickly, David.

I've fixed the problem that was causing that spec to fail - it had
nothing to do w/ the mocks, though there is obviously a failure in
feedback they are producing which I will look into.

But they were actually failing correctly because another part of the
spec was not doing what it appeared to be doing.

This is now resolved, with the import-rbehave branch passing the
pre_commit tasks with 100% coverage, etc, etc, etc. We'll be merging
this into trunk soon.

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

From noreply at rubyforge.org  Thu Aug 16 04:35:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 04:35:43 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13126 ] move rspec/spec.opts
	to rspec/spec/spec.opts
Message-ID: <20070816083544.2E24652409CB@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: move rspec/spec.opts to rspec/spec/spec.opts

Initial Comment:

Not really a feature request, per se, but I think it would be nice to have rspec/spec.opts moved to rspec/spec/spec.opts for autotest compatibility when developing rspec.



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

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

From noreply at rubyforge.org  Thu Aug 16 05:40:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 05:40:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13118 ] Rinda support for
	Spec::Distributed
Message-ID: <20070816094041.45B685240ACF@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Rinda support for Spec::Distributed

Initial Comment:
Auto discovery and tuplespace partitioning. Added a few specs.

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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-16 05:40

Message:
Bob, this stuff is fantastic. I can't wait to try this out! I do get some spec failures though: (spec spec)


....FFFF

1)
'Spec::Distributed::TupleArgs should create the default tuplespace when no args are given' FAILED
expected: [:rspec_slave, nil, nil],
     got: [:rspec_slave, :RindaSlaveRunner, nil] (using ==)
./spec/spec/distributed/tuple_args_spec.rb:17:

2)
'Spec::Distributed::TupleArgs should add one element to the tuple when one argument is given' FAILED
expected: [:rspec_slave, nil, nil, "One"],
     got: [:rspec_slave, :RindaSlaveRunner, nil, "One"] (using ==)
./spec/spec/distributed/tuple_args_spec.rb:21:

3)
'Spec::Distributed::TupleArgs should add two elements to the tuple when two arguments are given' FAILED
expected: [:rspec_slave, nil, nil, "One", "Two"],
     got: [:rspec_slave, :RindaSlaveRunner, nil, "One", "Two"] (using ==)
./spec/spec/distributed/tuple_args_spec.rb:25:

4)
'Spec::Distributed::TupleArgs should turn wildcards to 'nil' in the tuplespace' FAILED
expected: [:rspec_slave, nil, nil, nil],
     got: [:rspec_slave, :RindaSlaveRunner, nil, nil] (using ==)
./spec/spec/distributed/tuple_args_spec.rb:29:

Finished in 0.071833 seconds

8 examples, 4 failures



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

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

From noreply at rubyforge.org  Thu Aug 16 07:32:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 07:32:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13129 ] Fix failing specs in
	spec_distributed
Message-ID: <20070816113226.7C5035240B2A@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Fix failing specs in spec_distributed

Initial Comment:
That'll teach me not to run with autotest.

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

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

From noreply at rubyforge.org  Thu Aug 16 15:58:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 15:58:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13140 ] Make it easier to
	use the runner objects
Message-ID: <20070816195806.C561D5240CCD@rubyforge.org>

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

Category: runner / command line
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Make it easier to use the runner objects

Initial Comment:
There are issues with invoking the runner directly because the first time Kernel#behaviour_runner is called, an at_exit block is created.

It would be useful get rid of this behaviour because this makes is difficult to work with the runner object model.

Currently to get around this, I need to assign the $behaviour_runner global variable before the first call to Kernel#behaviour_runner.

Also as of 1.0.8, I need to call Options#configure or a reporter will not be assigned.
options = ::Spec::Runner::OptionParser.new.parse(ARGV.dup, STDERR, STDOUT, false)
options.configure 
$behaviour_runner = options.create_behaviour_runner

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

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

From noreply at rubyforge.org  Thu Aug 16 16:40:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 16:40:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13129 ] Fix failing specs in
	spec_distributed
Message-ID: <20070816204059.595FDA970002@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Fix failing specs in spec_distributed

Initial Comment:
That'll teach me not to run with autotest.

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

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-16 16:40

Message:
Applied in r2359

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

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

From noreply at rubyforge.org  Thu Aug 16 17:15:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 17:15:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20070816211504.25D62A970002@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


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

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

From noreply at rubyforge.org  Thu Aug 16 17:45:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 17:45:17 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13143 ]
	ActionView::Helpers::RecordIdentificationHelper should be
	included if present
Message-ID: <20070816214517.A4CDF5240CCC@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: ActionView::Helpers::RecordIdentificationHelper should be included if present

Initial Comment:
as summary.  This was added in edge r6633.

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

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

From noreply at rubyforge.org  Thu Aug 16 17:51:37 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 17:51:37 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070816215137.648F75240CCC@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 07: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: Rupert Voelcker (rupert)
Date: 2007-08-16 22:51

Message:
I like the look of the chained and_yield's myself, as it's pretty clear what's happening and avoids arity probs.  An alternative is to have something along the lines of

obj.should_receive(:msg).and_yield(....stuff to yield....).with_arity(2)

then if the number of args is a multiple of the arity then yield consecutively the multiple number of times.  If the number of args isn't a multiple of the arity then raise an arity error.

Does this seem like a good idea, or would it be confusing?

Anyway, I've made up a patch for handling the chained yields (I presume it'll allow me to upload after I hit submit - not used a tracker before)

No tests as I can't work out how to run the tests on rspec and if the arity approach is better the patch is junk anyway.

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

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

Message:
IMO:

obj.should_receive(:msg).and_yield([a,b],[c,d])

obj.msg # => [a,b]
obj.msg # => [c,d]
obj.msg # => [c,d] # When/if we reach the end, just yield the last one.

Wouldn't that work?

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

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

Message:
So how would that work with arity > 1?

obj.should_receive(:msg).and_yield([a,b],[c,d])

Does that mean:
- yield two arrays on the first call
- yield one array each for the first two calls
- yield two args each for the first two calls

This problem doesn't apply to and_return.

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

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

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 23:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 08: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 07: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 07: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  Thu Aug 16 17:56:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 16 Aug 2007 17:56:07 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070816215607.BA9BF5240D9E@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 07: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: Rupert Voelcker (rupert)
Date: 2007-08-16 22:56

Message:
no idea how to add the patch file, so it's at:

http://pastie.textmate.org/88416

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 22:51

Message:
I like the look of the chained and_yield's myself, as it's pretty clear what's happening and avoids arity probs.  An alternative is to have something along the lines of

obj.should_receive(:msg).and_yield(....stuff to yield....).with_arity(2)

then if the number of args is a multiple of the arity then yield consecutively the multiple number of times.  If the number of args isn't a multiple of the arity then raise an arity error.

Does this seem like a good idea, or would it be confusing?

Anyway, I've made up a patch for handling the chained yields (I presume it'll allow me to upload after I hit submit - not used a tracker before)

No tests as I can't work out how to run the tests on rspec and if the arity approach is better the patch is junk anyway.

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

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

Message:
IMO:

obj.should_receive(:msg).and_yield([a,b],[c,d])

obj.msg # => [a,b]
obj.msg # => [c,d]
obj.msg # => [c,d] # When/if we reach the end, just yield the last one.

Wouldn't that work?

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

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

Message:
So how would that work with arity > 1?

obj.should_receive(:msg).and_yield([a,b],[c,d])

Does that mean:
- yield two arrays on the first call
- yield one array each for the first two calls
- yield two args each for the first two calls

This problem doesn't apply to and_return.

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

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

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 23:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 08: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 07: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 07: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 rupert_apsc at rupespad.com  Fri Aug 17 05:40:40 2007
From: rupert_apsc at rupespad.com (rupert)
Date: Fri, 17 Aug 2007 10:40:40 +0100
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to
	yield	consecutive values
Message-ID: <AFA4CC01-358D-4D0E-A53D-0C7E27A9C631@rupespad.com>

I've hit the same need for this functionality and just discovered the  
patch.  I've made an alternative version that uses the chained  
and_yield syntax suggested by David Apologies for my newness to these  
things but I couldn't work out how to add the file into tracker so  
it's on pastie instead and I couldn't work out how to run rspec's  
tests so there are no tests with it either.

Another alternative approach to this could be to use syntax of the form:

obj.should_receive(:msg).and_yield(....stuff to yield....).with_arity(2)

where if the with_arity is not given it behaves as things currently  
do.  If it is given it checks that the number of arguments to  
and_yield is a multiple of the with_arity number and fails if it  
isn't.  If all is OKay, then the number of times to yield (and what  
to yield each time) can be determined from the arity and the number  
of arguments.

Not sure if this is better than the other approaches though?   
Anyways, I've added all this to the tracker:

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

Cheers

Rupert

From noreply at rubyforge.org  Fri Aug 17 06:19:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 17 Aug 2007 06:19:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070817101916.1DA08A970006@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 02: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: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-17 06:19

Message:
Rupert: There is a form at the bottom of this page for patches. Just remember to check the checkbox.

I still haven't heard a good argument for doing this differently from #and_return. What arity problems do you mean?

I don't like the chained #and_yield form - it's overly verbose and it introduces a new idiom for something that should be similar to the cousin #and_return.

Dave, you suggested that #and_yield is a different beast than #and_return. How so?

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 17:56

Message:
no idea how to add the patch file, so it's at:

http://pastie.textmate.org/88416

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 17:51

Message:
I like the look of the chained and_yield's myself, as it's pretty clear what's happening and avoids arity probs.  An alternative is to have something along the lines of

obj.should_receive(:msg).and_yield(....stuff to yield....).with_arity(2)

then if the number of args is a multiple of the arity then yield consecutively the multiple number of times.  If the number of args isn't a multiple of the arity then raise an arity error.

Does this seem like a good idea, or would it be confusing?

Anyway, I've made up a patch for handling the chained yields (I presume it'll allow me to upload after I hit submit - not used a tracker before)

No tests as I can't work out how to run the tests on rspec and if the arity approach is better the patch is junk anyway.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-12 20:05

Message:
IMO:

obj.should_receive(:msg).and_yield([a,b],[c,d])

obj.msg # => [a,b]
obj.msg # => [c,d]
obj.msg # => [c,d] # When/if we reach the end, just yield the last one.

Wouldn't that work?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 19:27

Message:
So how would that work with arity > 1?

obj.should_receive(:msg).and_yield([a,b],[c,d])

Does that mean:
- yield two arrays on the first call
- yield one array each for the first two calls
- yield two args each for the first two calls

This problem doesn't apply to and_return.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-12 19:13

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 18:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 03: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 02: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 02: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  Fri Aug 17 06:23:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 17 Aug 2007 06:23:33 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070817102333.80911A970005@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 02: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: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-17 06:23

Message:
Doh, I just understood the arity problem. I'm an idiot.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-17 06:19

Message:
Rupert: There is a form at the bottom of this page for patches. Just remember to check the checkbox.

I still haven't heard a good argument for doing this differently from #and_return. What arity problems do you mean?

I don't like the chained #and_yield form - it's overly verbose and it introduces a new idiom for something that should be similar to the cousin #and_return.

Dave, you suggested that #and_yield is a different beast than #and_return. How so?

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 17:56

Message:
no idea how to add the patch file, so it's at:

http://pastie.textmate.org/88416

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 17:51

Message:
I like the look of the chained and_yield's myself, as it's pretty clear what's happening and avoids arity probs.  An alternative is to have something along the lines of

obj.should_receive(:msg).and_yield(....stuff to yield....).with_arity(2)

then if the number of args is a multiple of the arity then yield consecutively the multiple number of times.  If the number of args isn't a multiple of the arity then raise an arity error.

Does this seem like a good idea, or would it be confusing?

Anyway, I've made up a patch for handling the chained yields (I presume it'll allow me to upload after I hit submit - not used a tracker before)

No tests as I can't work out how to run the tests on rspec and if the arity approach is better the patch is junk anyway.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-12 20:05

Message:
IMO:

obj.should_receive(:msg).and_yield([a,b],[c,d])

obj.msg # => [a,b]
obj.msg # => [c,d]
obj.msg # => [c,d] # When/if we reach the end, just yield the last one.

Wouldn't that work?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 19:27

Message:
So how would that work with arity > 1?

obj.should_receive(:msg).and_yield([a,b],[c,d])

Does that mean:
- yield two arrays on the first call
- yield one array each for the first two calls
- yield two args each for the first two calls

This problem doesn't apply to and_return.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-12 19:13

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 18:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 03: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 02: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 02: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  Fri Aug 17 06:45:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 17 Aug 2007 06:45:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070817104548.B7343A97000A@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 07: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: Rupert Voelcker (rupert)
Date: 2007-08-17 11:45

Message:
Aslak - the arity issue (to me) is if you have:

obj.should_receive(:msg).and_yield([a,b],[c,d])

and you assume that this is a consecutive yield, you can use it to spec yilelder1 in the following class:

class MyClass

  def yielder1
    yield([1,2])
    yield([3,4])
  end

  def yielder2
    yield([1,2], [3,4])
  end
end

However, you couldn't then spec yielder2.

This problem is potentially there for and_return too (I think), as as far as I know you can return multiple values (although being quite new to ruby I've not used this feature yet so don't actually know).

Not sure what the differences are that Dave had in mind, but to me the difference is that and_return (as currently handled in rspec) can only return one value per message call. and_yield can return multiple values many times per message call.

P.S. still can't see where to submit a file - there's just a list of attached files and download links at the bottom and a list of changes :(  Not that this is particularly imporatant!

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-17 11:23

Message:
Doh, I just understood the arity problem. I'm an idiot.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-17 11:19

Message:
Rupert: There is a form at the bottom of this page for patches. Just remember to check the checkbox.

I still haven't heard a good argument for doing this differently from #and_return. What arity problems do you mean?

I don't like the chained #and_yield form - it's overly verbose and it introduces a new idiom for something that should be similar to the cousin #and_return.

Dave, you suggested that #and_yield is a different beast than #and_return. How so?

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 22:56

Message:
no idea how to add the patch file, so it's at:

http://pastie.textmate.org/88416

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 22:51

Message:
I like the look of the chained and_yield's myself, as it's pretty clear what's happening and avoids arity probs.  An alternative is to have something along the lines of

obj.should_receive(:msg).and_yield(....stuff to yield....).with_arity(2)

then if the number of args is a multiple of the arity then yield consecutively the multiple number of times.  If the number of args isn't a multiple of the arity then raise an arity error.

Does this seem like a good idea, or would it be confusing?

Anyway, I've made up a patch for handling the chained yields (I presume it'll allow me to upload after I hit submit - not used a tracker before)

No tests as I can't work out how to run the tests on rspec and if the arity approach is better the patch is junk anyway.

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

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

Message:
IMO:

obj.should_receive(:msg).and_yield([a,b],[c,d])

obj.msg # => [a,b]
obj.msg # => [c,d]
obj.msg # => [c,d] # When/if we reach the end, just yield the last one.

Wouldn't that work?

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

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

Message:
So how would that work with arity > 1?

obj.should_receive(:msg).and_yield([a,b],[c,d])

Does that mean:
- yield two arrays on the first call
- yield one array each for the first two calls
- yield two args each for the first two calls

This problem doesn't apply to and_return.

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

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

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 23:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 08: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 07: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 07: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  Fri Aug 17 06:47:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 17 Aug 2007 06:47:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12841 ] Allow stubs to yield
	consecutive values
Message-ID: <20070817104712.45710A970009@rubyforge.org>

Patches item #12841, was opened at 2007-08-06 07: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: Rupert Voelcker (rupert)
Date: 2007-08-17 11:47

Message:
ah - cool!

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-17 11:45

Message:
Aslak - the arity issue (to me) is if you have:

obj.should_receive(:msg).and_yield([a,b],[c,d])

and you assume that this is a consecutive yield, you can use it to spec yilelder1 in the following class:

class MyClass

  def yielder1
    yield([1,2])
    yield([3,4])
  end

  def yielder2
    yield([1,2], [3,4])
  end
end

However, you couldn't then spec yielder2.

This problem is potentially there for and_return too (I think), as as far as I know you can return multiple values (although being quite new to ruby I've not used this feature yet so don't actually know).

Not sure what the differences are that Dave had in mind, but to me the difference is that and_return (as currently handled in rspec) can only return one value per message call. and_yield can return multiple values many times per message call.

P.S. still can't see where to submit a file - there's just a list of attached files and download links at the bottom and a list of changes :(  Not that this is particularly imporatant!

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-17 11:23

Message:
Doh, I just understood the arity problem. I'm an idiot.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-17 11:19

Message:
Rupert: There is a form at the bottom of this page for patches. Just remember to check the checkbox.

I still haven't heard a good argument for doing this differently from #and_return. What arity problems do you mean?

I don't like the chained #and_yield form - it's overly verbose and it introduces a new idiom for something that should be similar to the cousin #and_return.

Dave, you suggested that #and_yield is a different beast than #and_return. How so?

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 22:56

Message:
no idea how to add the patch file, so it's at:

http://pastie.textmate.org/88416

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

Comment By: Rupert Voelcker (rupert)
Date: 2007-08-16 22:51

Message:
I like the look of the chained and_yield's myself, as it's pretty clear what's happening and avoids arity probs.  An alternative is to have something along the lines of

obj.should_receive(:msg).and_yield(....stuff to yield....).with_arity(2)

then if the number of args is a multiple of the arity then yield consecutively the multiple number of times.  If the number of args isn't a multiple of the arity then raise an arity error.

Does this seem like a good idea, or would it be confusing?

Anyway, I've made up a patch for handling the chained yields (I presume it'll allow me to upload after I hit submit - not used a tracker before)

No tests as I can't work out how to run the tests on rspec and if the arity approach is better the patch is junk anyway.

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

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

Message:
IMO:

obj.should_receive(:msg).and_yield([a,b],[c,d])

obj.msg # => [a,b]
obj.msg # => [c,d]
obj.msg # => [c,d] # When/if we reach the end, just yield the last one.

Wouldn't that work?

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

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

Message:
So how would that work with arity > 1?

obj.should_receive(:msg).and_yield([a,b],[c,d])

Does that mean:
- yield two arrays on the first call
- yield one array each for the first two calls
- yield two args each for the first two calls

This problem doesn't apply to and_return.

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

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

Message:
This should be done in the same way as and_return(*consecutive_values)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-12 23:48

Message:
Right now you can do this to get consecutive yield values:

obj.should_receive(:msg).and_yield(value1)
obj.should_receive(:msg).and_yield(value2)

The problem with putting all the values to be yielded in one statement is that rspec would have no way of knowing definitively what is a single array argument vs an array of consecutive arguments.

Conceivably, we could so something like:

obj.should_receive(:msg)
  .and_yield(value1)
  .and_yield(value2)
  .and_yield(value3)
  .and_yield(value4)

But is that really that much of an advantage?

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

Comment By: Pat Maddox (pergesu)
Date: 2007-08-06 08: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 07: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 07: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  Sat Aug 18 14:25:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 18 Aug 2007 14:25:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13186 ] Fix for
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	and url helpers
Message-ID: <20070818182519.09C235240CBF@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Timothy Bennett (lanaer)
Assigned to: Nobody (None)
Summary: Fix for ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods and url helpers

Initial Comment:
This fixes a nil.<< exception raised when the Rails REST url helpers are invoked from within a HelperEvalContext.

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

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

From brian.takita at gmail.com  Sat Aug 18 20:36:32 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Sat, 18 Aug 2007 17:36:32 -0700
Subject: [rspec-devel] Translated Specs?
Message-ID: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>

Can somebody explain what the translated specs are? To me they look
exactly the same as the regular example suite.
Is the translated specs rake task dead code?

Thanks,
Brian

From mailing_lists at railsnewbie.com  Sat Aug 18 21:53:22 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Sat, 18 Aug 2007 21:53:22 -0400
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
Message-ID: <F604CD96-6610-4049-864B-AD3C249A6317@railsnewbie.com>


Are you talking about the spec_translator in rspec/bin ?

Scott


On Aug 18, 2007, at 8:36 PM, Brian Takita wrote:

> Can somebody explain what the translated specs are? To me they look
> exactly the same as the regular example suite.
> Is the translated specs rake task dead code?
>
> Thanks,
> Brian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Sat Aug 18 23:17:01 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 18 Aug 2007 23:17:01 -0400
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
Message-ID: <57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>

On 8/18/07, Brian Takita <brian.takita at gmail.com> wrote:
> Can somebody explain what the translated specs are?

Funny - that was added when we were preparing for 1.0 as a test for
the translator. The translator is still necessary, but the translated
specs are obsolete at this point (as there is nothing to actually
translate).

Aslak - can you weigh in on this? Unless you think otherwise, I'd like
to kill that part of the pre_commit process.

> To me they look
> exactly the same as the regular example suite.
> Is the translated specs rake task dead code?
>
> Thanks,
> Brian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Sat Aug 18 23:20:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 18 Aug 2007 23:20:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13186 ] Fix for
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	and url helpers
Message-ID: <20070819032018.631465240E94@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Timothy Bennett (lanaer)
Assigned to: Nobody (None)
Summary: Fix for ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods and url helpers

Initial Comment:
This fixes a nil.<< exception raised when the Rails REST url helpers are invoked from within a HelperEvalContext.

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

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

Message:
Would you please resubmit with a failing spec?

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

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

From noreply at rubyforge.org  Sat Aug 18 23:23:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 18 Aug 2007 23:23:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070819032316.2888E5240E8D@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: David Chelimsky (dchelimsky)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

Comment By: Tim  Dysinger (dysinger)
Date: 2007-08-18 17:23

Message:
I am seeing this problem too after upgrading to rspec 1.0.8 + rails plugin.

I am on rails edge 7116

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

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

Message:
Fixed in 2348 - I received two patches that both do essentially the same fix - one here from you and one from Mike Mangino so I added you both in the contributors list.

Thanks for getting this to work - a lot of people have been looking for this.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 10:30

Message:
Never mind that. The svn revert going on in pre_commit was making my tests 
fail, because it removed my named_route.

 I'm attaching a diff that will fix it, but to make the tests work you need to 
add   map.named '/named_route', :controller => 'people', :action => 'index' 
to config/routes.rb. This needs to be added to the route.rb, which is getting 
reverted via a svn revert. I get a pass on the first time and a fail on the other 
times.


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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 10:15

Message:
Adding 'ActionController::Routing::Routes.named_routes.install(self.class) to line 
64 of rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb fixes this issue in 
my project, but not in the test I added. I'm unsure why they are differing.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 09:42

Message:
ActionController::Routing::Routes.named_rotes.install(self.class) inside of a ruby 
debug instance (thus inside of an Example) appears to fix this. I'm looking where 
to put that now.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 08:55

Message:
Here is a diff. It may not have included the route. If not, add   "map.connect 
'custom_route', :controller => 'custom_route_spec', :action => 'custom_route'" 
to the example_rails_app routes.rb file. I don't know if I can figure out where the 
error is, any help would be appreciated, but I will try.

JD



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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 08:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 08:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 08:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Sat Aug 18 23:24:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 18 Aug 2007 23:24:24 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070819032424.A94115240E8D@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: David Chelimsky (dchelimsky)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

Comment By: Tim  Dysinger (dysinger)
Date: 2007-08-18 17:24

Message:
I am on 7116 rails edge and this problem appears on upgrade to REL_1_0_8

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

Comment By: Tim  Dysinger (dysinger)
Date: 2007-08-18 17:23

Message:
I am seeing this problem too after upgrading to rspec 1.0.8 + rails plugin.

I am on rails edge 7116

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

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

Message:
Fixed in 2348 - I received two patches that both do essentially the same fix - one here from you and one from Mike Mangino so I added you both in the contributors list.

Thanks for getting this to work - a lot of people have been looking for this.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 10:30

Message:
Never mind that. The svn revert going on in pre_commit was making my tests 
fail, because it removed my named_route.

 I'm attaching a diff that will fix it, but to make the tests work you need to 
add   map.named '/named_route', :controller => 'people', :action => 'index' 
to config/routes.rb. This needs to be added to the route.rb, which is getting 
reverted via a svn revert. I get a pass on the first time and a fail on the other 
times.


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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 10:15

Message:
Adding 'ActionController::Routing::Routes.named_routes.install(self.class) to line 
64 of rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb fixes this issue in 
my project, but not in the test I added. I'm unsure why they are differing.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 09:42

Message:
ActionController::Routing::Routes.named_rotes.install(self.class) inside of a ruby 
debug instance (thus inside of an Example) appears to fix this. I'm looking where 
to put that now.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 08:55

Message:
Here is a diff. It may not have included the route. If not, add   "map.connect 
'custom_route', :controller => 'custom_route_spec', :action => 'custom_route'" 
to the example_rails_app routes.rb file. I don't know if I can figure out where the 
error is, any help would be appreciated, but I will try.

JD



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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 08:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 08:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 08:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From noreply at rubyforge.org  Sat Aug 18 23:50:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 18 Aug 2007 23:50:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13065 ] Named routes throw a
	NoMethodError in Helper specs
Message-ID: <20070819035049.021FAA970005@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: David Chelimsky (dchelimsky)
Summary: Named routes throw a NoMethodError in Helper specs

Initial Comment:
Using named routes in RSpec 1.0.8 inside of Helper specs throws a NoMethodError. 

Looking into the code some, the use of a named route like root_path is getting into the method_missing in lib/spec/matchers.rb on line 157. From there it is going to the super which is calling PrototypeHelper.method_missing in rails/actionpack/lib/action_view/helpers/prototype_helper.rb line 658, which calls a new JavaScriptProxy

That seems to be the issue. I'm going to look into why method_missing jumps straight to the JS stuff, not the named routes and such.

I'll add some patches for tests and try to fix it.



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

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

Message:
This was fixed in 2348, which is after the 1.0.8 release. You'll have to use trunk or wait for the next release.

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

Comment By: Tim  Dysinger (dysinger)
Date: 2007-08-19 03:24

Message:
I am on 7116 rails edge and this problem appears on upgrade to REL_1_0_8

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

Comment By: Tim  Dysinger (dysinger)
Date: 2007-08-19 03:23

Message:
I am seeing this problem too after upgrading to rspec 1.0.8 + rails plugin.

I am on rails edge 7116

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-15 04:34

Message:
Fixed in 2348 - I received two patches that both do essentially the same fix - one here from you and one from Mike Mangino so I added you both in the contributors list.

Thanks for getting this to work - a lot of people have been looking for this.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 20:30

Message:
Never mind that. The svn revert going on in pre_commit was making my tests 
fail, because it removed my named_route.

 I'm attaching a diff that will fix it, but to make the tests work you need to 
add   map.named '/named_route', :controller => 'people', :action => 'index' 
to config/routes.rb. This needs to be added to the route.rb, which is getting 
reverted via a svn revert. I get a pass on the first time and a fail on the other 
times.


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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 20:15

Message:
Adding 'ActionController::Routing::Routes.named_routes.install(self.class) to line 
64 of rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb fixes this issue in 
my project, but not in the test I added. I'm unsure why they are differing.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 19:42

Message:
ActionController::Routing::Routes.named_rotes.install(self.class) inside of a ruby 
debug instance (thus inside of an Example) appears to fix this. I'm looking where 
to put that now.

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:55

Message:
Here is a diff. It may not have included the route. If not, add   "map.connect 
'custom_route', :controller => 'custom_route_spec', :action => 'custom_route'" 
to the example_rails_app routes.rb file. I don't know if I can figure out where the 
error is, any help would be appreciated, but I will try.

JD



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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:47

Message:
This may be related to bug#13020

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

Comment By: James Deville (parcelbrat)
Date: 2007-08-14 18:45

Message:
I'm running edge right now. REV: 7192. I'm working on getting a spec for it, but 
having trouble getting a named route set up to test against.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-14 18:28

Message:
Can you please mention what Rails version(s)/revision(s) you have seen this in?

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

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

From aslak.hellesoy at gmail.com  Sun Aug 19 10:10:05 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 19 Aug 2007 16:10:05 +0200
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
	<57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>
Message-ID: <8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>

On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/18/07, Brian Takita <brian.takita at gmail.com> wrote:
> > Can somebody explain what the translated specs are?
>
> Funny - that was added when we were preparing for 1.0 as a test for
> the translator. The translator is still necessary, but the translated
> specs are obsolete at this point (as there is nothing to actually
> translate).
>
> Aslak - can you weigh in on this? Unless you think otherwise, I'd like
> to kill that part of the pre_commit process.
>

The translator translates deprecated code (which we still have - the matchers).
As long as we keep deprecated code around and want a translator that
can translate it we should keep this part of the build around. It
verifies that translated code still passes.

Aslak

> > To me they look
> > exactly the same as the regular example suite.
> > Is the translated specs rake task dead code?
> >
> > Thanks,
> > Brian
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sun Aug 19 10:28:55 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 19 Aug 2007 10:28:55 -0400
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
	<57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>
	<8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>
Message-ID: <57c63afe0708190728q6501c64p3b64e979dfe9d4c7@mail.gmail.com>

On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/18/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > Can somebody explain what the translated specs are?
> >
> > Funny - that was added when we were preparing for 1.0 as a test for
> > the translator. The translator is still necessary, but the translated
> > specs are obsolete at this point (as there is nothing to actually
> > translate).
> >
> > Aslak - can you weigh in on this? Unless you think otherwise, I'd like
> > to kill that part of the pre_commit process.
> >
>
> The translator translates deprecated code (which we still have - the matchers).

Do you mean the mock argument constraints that are expressed as Symbols?

> As long as we keep deprecated code around and want a translator that
> can translate it we should keep this part of the build around. It
> verifies that translated code still passes.
>
> Aslak
>
> > > To me they look
> > > exactly the same as the regular example suite.
> > > Is the translated specs rake task dead code?
> > >
> > > Thanks,
> > > Brian
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Sun Aug 19 10:40:22 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 19 Aug 2007 16:40:22 +0200
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <57c63afe0708190728q6501c64p3b64e979dfe9d4c7@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
	<57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>
	<8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>
	<57c63afe0708190728q6501c64p3b64e979dfe9d4c7@mail.gmail.com>
Message-ID: <8d961d900708190740h62b8d8b4qaeee9eab0fbf07d3@mail.gmail.com>

On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 8/18/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > > Can somebody explain what the translated specs are?
> > >
> > > Funny - that was added when we were preparing for 1.0 as a test for
> > > the translator. The translator is still necessary, but the translated
> > > specs are obsolete at this point (as there is nothing to actually
> > > translate).
> > >
> > > Aslak - can you weigh in on this? Unless you think otherwise, I'd like
> > > to kill that part of the pre_commit process.
> > >
> >
> > The translator translates deprecated code (which we still have - the matchers).
>
> Do you mean the mock argument constraints that are expressed as Symbols?
>

Yes

> > As long as we keep deprecated code around and want a translator that
> > can translate it we should keep this part of the build around. It
> > verifies that translated code still passes.
> >
> > Aslak
> >
> > > > To me they look
> > > > exactly the same as the regular example suite.
> > > > Is the translated specs rake task dead code?
> > > >
> > > > Thanks,
> > > > Brian
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sun Aug 19 10:44:10 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 19 Aug 2007 10:44:10 -0400
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <8d961d900708190740h62b8d8b4qaeee9eab0fbf07d3@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
	<57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>
	<8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>
	<57c63afe0708190728q6501c64p3b64e979dfe9d4c7@mail.gmail.com>
	<8d961d900708190740h62b8d8b4qaeee9eab0fbf07d3@mail.gmail.com>
Message-ID: <57c63afe0708190744k68f50ea9g33b2336cea0ed1de@mail.gmail.com>

On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > On 8/18/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > > > Can somebody explain what the translated specs are?
> > > >
> > > > Funny - that was added when we were preparing for 1.0 as a test for
> > > > the translator. The translator is still necessary, but the translated
> > > > specs are obsolete at this point (as there is nothing to actually
> > > > translate).
> > > >
> > > > Aslak - can you weigh in on this? Unless you think otherwise, I'd like
> > > > to kill that part of the pre_commit process.
> > > >
> > >
> > > The translator translates deprecated code (which we still have - the matchers).
> >
> > Do you mean the mock argument constraints that are expressed as Symbols?
> >
>
> Yes

OK - so when we release 1.1, we should yank the deprecated code and
the translated specs, agree?

>
> > > As long as we keep deprecated code around and want a translator that
> > > can translate it we should keep this part of the build around. It
> > > verifies that translated code still passes.
> > >
> > > Aslak
> > >
> > > > > To me they look
> > > > > exactly the same as the regular example suite.
> > > > > Is the translated specs rake task dead code?
> > > > >
> > > > > Thanks,
> > > > > Brian
> > > > > _______________________________________________
> > > > > rspec-devel mailing list
> > > > > rspec-devel at rubyforge.org
> > > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > > >
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Sun Aug 19 17:22:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 19 Aug 2007 17:22:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13206 ] Individual Spec's
	Runtimes in Specdoc formatter
Message-ID: <20070819212229.C9FA15240BB8@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Individual Spec's Runtimes in Specdoc formatter

Initial Comment:

(ajturner, in #rspec, suggested this):

The specdoc formatter to report the time each individual spec takes to run. The output would look something like this:
     
User
- should have many subscriptions (0.014 sec)
- should be a ruby developer (0.012 sec)



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

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

From noreply at rubyforge.org  Sun Aug 19 17:26:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 19 Aug 2007 17:26:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13208 ] Specdoc outputs wrong spec names
	with drbserver
Message-ID: <20070819212619.3AA415240BB9@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Specdoc outputs wrong spec names with drbserver

Initial Comment:

In a rails project (trunk, rev. 7345, ruby 1.8.6, Mac OS X, Rspec & rspec on rails frozen in /vendor/plugins at current release, 1.0.8), with the following spec.opts:

--colour

--loadby mtime
--reverse
--drb
--format specdoc

The output looks as follows:

ptolemy# rake spec
(in /Users/smt/src/web/urbis/branches/rails_2.0_integration)

      *******************************************************************
      * config.breakpoint_server has been deprecated and has no effect. *
      *******************************************************************
      

#<DRb::DRbUnknown:0x14e7298>
- should have the unit name
- should have the keyword
- should ensure that each unit_name is unique

#<DRb::DRbUnknown:0x14b4604>
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is equal to the item's category (PENDING: Not Yet Implemented)
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is nil (PENDING: Not Yet Implemented)


Obviously the class names/description blocks are not being displayed properly.




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

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

From brian.takita at gmail.com  Mon Aug 20 02:26:21 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 19 Aug 2007 23:26:21 -0700
Subject: [rspec-devel] Refactoring ready to be merged
Message-ID: <1d7ddd110708192326r51d95988re0ee8bff6d23dd4b@mail.gmail.com>

Hello, I think the behaviour refactoring branch I created is ready to
me merged into trunk.

svn+ssh://rubyforge.org/var/svn/rspec/branches/20070804_behaviour_refactoring

There have been some major changes to the internals.

Here are some of the changes in Rspec core:
* BehaviourEval is gone
* Behaviour is a subclass of Module, which allows it to take the place
of BehaviourEval
* Behaviour#inherit is removed
* ExampleSpace replaces BehaviourEval#execution_context_class

Here are some of the changes in Rspec on rails:
* Each Behaviour subclass is stripped down
* Each Behaviour subclass has a ExampleSpace subclass, with
functionality moved from the Behaviour subclasses to the ExampleSpace
subclasses

Here are some of the changes to pre_commit:
* If the rspec_on_rails pre_commit fails, the generated files are left
behind to specs can be run individually in example_rails_app
* General refactorings

There is still some refactoring that needs to be done. For example, I
think that there are some domain name mismatches in Example.

I'm thinking that Example should be ExampleDefinition and ExampleSpace
should be Example.

There may also be an opportunity to further consolidate Example and
Behaviour, but I'm not sure yet.

I believe that now is the right time to merge the branch into trunk
because the pre_commit passes and there are already alot of changes.
Further refactorings involve changing the domain language around
Example, which would be very difficult to merge.

How does this sound?

Thanks,
Brian

From noreply at rubyforge.org  Mon Aug 20 04:43:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 20 Aug 2007 04:43:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13208 ] Specdoc outputs wrong spec names
	with drbserver
Message-ID: <20070820084329.52AF2524096F@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Specdoc outputs wrong spec names with drbserver

Initial Comment:

In a rails project (trunk, rev. 7345, ruby 1.8.6, Mac OS X, Rspec & rspec on rails frozen in /vendor/plugins at current release, 1.0.8), with the following spec.opts:

--colour

--loadby mtime
--reverse
--drb
--format specdoc

The output looks as follows:

ptolemy# rake spec
(in /Users/smt/src/web/urbis/branches/rails_2.0_integration)

      *******************************************************************
      * config.breakpoint_server has been deprecated and has no effect. *
      *******************************************************************
      

#<DRb::DRbUnknown:0x14e7298>
- should have the unit name
- should have the keyword
- should ensure that each unit_name is unique

#<DRb::DRbUnknown:0x14b4604>
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is equal to the item's category (PENDING: Not Yet Implemented)
- should add the error 'Wrong category for this item' on validation of the attempt if the goal's category is nil (PENDING: Not Yet Implemented)


Obviously the class names/description blocks are not being displayed properly.




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

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

Message:
This is happening because Behaviour is not serializable. I'll look into this one.

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

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

From dan at tastapod.com  Mon Aug 20 16:11:11 2007
From: dan at tastapod.com (Dan North)
Date: Mon, 20 Aug 2007 21:11:11 +0100
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <57c63afe0708190744k68f50ea9g33b2336cea0ed1de@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>	<57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>	<8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>	<57c63afe0708190728q6501c64p3b64e979dfe9d4c7@mail.gmail.com>	<8d961d900708190740h62b8d8b4qaeee9eab0fbf07d3@mail.gmail.com>
	<57c63afe0708190744k68f50ea9g33b2336cea0ed1de@mail.gmail.com>
Message-ID: <46C9F55F.5070002@tastapod.com>

Forgive me chiming in here.

My understanding of the conventions for 3-part numbering are:

Major release (1.x -> 2.0) can break compatibility with deprecated APIs
Minor release (1.3, -> 1.4) maintains backward compatibility but can 
introduce new interfaces
Patch release (1.3.2 -> 1.3.3) is a bugfix that doesn't change any 
(significant) APIs

(This is stolen from http://jmock.org/versioning.html).

If you want to remove the old non-matcher expectations (and thereby 
break backward compatibility), you might want to consider a 2.0 release. 
So the question is, are we ready for a 2.0 release yet?*

Cheers,
Dan

* For my opinion on this you only need buy me a beer - I'm pretty cheap.


David Chelimsky wrote:
> On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>   
>> On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>>     
>>> On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>>>       
>>>> On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>>>>         
>>>>> On 8/18/07, Brian Takita <brian.takita at gmail.com> wrote:
>>>>>           
>>>>>> Can somebody explain what the translated specs are?
>>>>>>             
>>>>> Funny - that was added when we were preparing for 1.0 as a test for
>>>>> the translator. The translator is still necessary, but the translated
>>>>> specs are obsolete at this point (as there is nothing to actually
>>>>> translate).
>>>>>
>>>>> Aslak - can you weigh in on this? Unless you think otherwise, I'd like
>>>>> to kill that part of the pre_commit process.
>>>>>
>>>>>           
>>>> The translator translates deprecated code (which we still have - the matchers).
>>>>         
>>> Do you mean the mock argument constraints that are expressed as Symbols?
>>>
>>>       
>> Yes
>>     
>
> OK - so when we release 1.1, we should yank the deprecated code and
> the translated specs, agree?
>
>   
>>>> As long as we keep deprecated code around and want a translator that
>>>> can translate it we should keep this part of the build around. It
>>>> verifies that translated code still passes.
>>>>
>>>> Aslak
>>>>
>>>>         
>>>>>> To me they look
>>>>>> exactly the same as the regular example suite.
>>>>>> Is the translated specs rake task dead code?
>>>>>>
>>>>>> Thanks,
>>>>>> Brian
>>>>>> _______________________________________________
>>>>>> rspec-devel mailing list
>>>>>> rspec-devel at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>>>
>>>>>>             
>>>>> _______________________________________________
>>>>> rspec-devel mailing list
>>>>> rspec-devel at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> rspec-devel mailing list
>>>> rspec-devel at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>
>>>>         
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>>>       
>> _______________________________________________
>> 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/20070820/fff0f672/attachment-0001.html 

From aslak.hellesoy at gmail.com  Mon Aug 20 16:24:52 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 20 Aug 2007 22:24:52 +0200
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <46C9F55F.5070002@tastapod.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
	<57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>
	<8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>
	<57c63afe0708190728q6501c64p3b64e979dfe9d4c7@mail.gmail.com>
	<8d961d900708190740h62b8d8b4qaeee9eab0fbf07d3@mail.gmail.com>
	<57c63afe0708190744k68f50ea9g33b2336cea0ed1de@mail.gmail.com>
	<46C9F55F.5070002@tastapod.com>
Message-ID: <8d961d900708201324i694e8b4ehfccc771597cb2b66@mail.gmail.com>

On 8/20/07, Dan North <dan at tastapod.com> wrote:
>
>  Forgive me chiming in here.
>
>  My understanding of the conventions for 3-part numbering are:
>
>  Major release (1.x -> 2.0) can break compatibility with deprecated APIs
>  Minor release (1.3, -> 1.4) maintains backward compatibility but can
> introduce new interfaces
>  Patch release (1.3.2 -> 1.3.3) is a bugfix that doesn't change any
> (significant) APIs
>

This is a good convention that I think we should have as a guideline.
When it comes to the mock constraint args, I think it's a fairly
insignificant part of the API. Sure - many people are already using
it, but we also have a translator that will translate 99% of them (not
scientific).

I therefore think we can release 1.1 and remove support for the
deprecated constraints - doing a 2.0 seems a little drastic.

However, when RBehave and Brian's cleanup of the internals are merged
back to trunk we could consider it. (But I'm still not sure - the
public API remains mostly unchanged).

Aslak

>  (This is stolen from http://jmock.org/versioning.html).
>
>  If you want to remove the old non-matcher expectations (and thereby break
> backward compatibility), you might want to consider a 2.0 release. So the
> question is, are we ready for a 2.0 release yet?*
>
>  Cheers,
>  Dan
>
>  * For my opinion on this you only need buy me a beer - I'm pretty cheap.
>
>
>
>  David Chelimsky wrote:
>  On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
>
>  On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
>
>  On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
>
>  On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
>
>  On 8/18/07, Brian Takita <brian.takita at gmail.com> wrote:
>
>
>  Can somebody explain what the translated specs are?
>
>  Funny - that was added when we were preparing for 1.0 as a test for
> the translator. The translator is still necessary, but the translated
> specs are obsolete at this point (as there is nothing to actually
> translate).
>
> Aslak - can you weigh in on this? Unless you think otherwise, I'd like
> to kill that part of the pre_commit process.
>
>
>  The translator translates deprecated code (which we still have - the
> matchers).
>
>  Do you mean the mock argument constraints that are expressed as Symbols?
>
>
>  Yes
>
>  OK - so when we release 1.1, we should yank the deprecated code and
> the translated specs, agree?
>
>
>
>
>
>  As long as we keep deprecated code around and want a translator that
> can translate it we should keep this part of the build around. It
> verifies that translated code still passes.
>
> Aslak
>
>
>
>
>  To me they look
> exactly the same as the regular example suite.
> Is the translated specs rake task dead code?
>
> Thanks,
> Brian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
>  _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
>  _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
>  _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
>  _______________________________________________
> 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 20 16:39:22 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 20 Aug 2007 15:39:22 -0500
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <8d961d900708201324i694e8b4ehfccc771597cb2b66@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>
	<57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>
	<8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>
	<57c63afe0708190728q6501c64p3b64e979dfe9d4c7@mail.gmail.com>
	<8d961d900708190740h62b8d8b4qaeee9eab0fbf07d3@mail.gmail.com>
	<57c63afe0708190744k68f50ea9g33b2336cea0ed1de@mail.gmail.com>
	<46C9F55F.5070002@tastapod.com>
	<8d961d900708201324i694e8b4ehfccc771597cb2b66@mail.gmail.com>
Message-ID: <57c63afe0708201339s1cac6d69h1c0f3b7058c25356@mail.gmail.com>

On 8/20/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/20/07, Dan North <dan at tastapod.com> wrote:
> >
> >  Forgive me chiming in here.
> >
> >  My understanding of the conventions for 3-part numbering are:
> >
> >  Major release (1.x -> 2.0) can break compatibility with deprecated APIs
> >  Minor release (1.3, -> 1.4) maintains backward compatibility but can
> > introduce new interfaces
> >  Patch release (1.3.2 -> 1.3.3) is a bugfix that doesn't change any
> > (significant) APIs
> >
>
> This is a good convention that I think we should have as a guideline.
> When it comes to the mock constraint args, I think it's a fairly
> insignificant part of the API. Sure - many people are already using
> it, but we also have a translator that will translate 99% of them (not
> scientific).
>
> I therefore think we can release 1.1 and remove support for the
> deprecated constraints - doing a 2.0 seems a little drastic.

I also feel like 2.0 is a bit pre-mature. We only released 1.0 a few
months ago, we're just getting the story runner merged in now, etc. I
think the story runner needs to bake in for a while, let ppl use it,
see what sorts of feature requests come up, etc, before we just dump
out a 2.0 release.

2 cents.

>
> However, when RBehave and Brian's cleanup of the internals are merged
> back to trunk we could consider it. (But I'm still not sure - the
> public API remains mostly unchanged).
>
> Aslak
>
> >  (This is stolen from http://jmock.org/versioning.html).
> >
> >  If you want to remove the old non-matcher expectations (and thereby break
> > backward compatibility), you might want to consider a 2.0 release. So the
> > question is, are we ready for a 2.0 release yet?*
> >
> >  Cheers,
> >  Dan
> >
> >  * For my opinion on this you only need buy me a beer - I'm pretty cheap.
> >
> >
> >
> >  David Chelimsky wrote:
> >  On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> >
> >
> >  On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >
> >
> >  On 8/19/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> >
> >
> >  On 8/19/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >
> >
> >  On 8/18/07, Brian Takita <brian.takita at gmail.com> wrote:
> >
> >
> >  Can somebody explain what the translated specs are?
> >
> >  Funny - that was added when we were preparing for 1.0 as a test for
> > the translator. The translator is still necessary, but the translated
> > specs are obsolete at this point (as there is nothing to actually
> > translate).
> >
> > Aslak - can you weigh in on this? Unless you think otherwise, I'd like
> > to kill that part of the pre_commit process.
> >
> >
> >  The translator translates deprecated code (which we still have - the
> > matchers).
> >
> >  Do you mean the mock argument constraints that are expressed as Symbols?
> >
> >
> >  Yes
> >
> >  OK - so when we release 1.1, we should yank the deprecated code and
> > the translated specs, agree?
> >
> >
> >
> >
> >
> >  As long as we keep deprecated code around and want a translator that
> > can translate it we should keep this part of the build around. It
> > verifies that translated code still passes.
> >
> > Aslak
> >
> >
> >
> >
> >  To me they look
> > exactly the same as the regular example suite.
> > Is the translated specs rake task dead code?
> >
> > Thanks,
> > Brian
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
> >  _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
> >  _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
> >  _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
> >  _______________________________________________
> > 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 20 16:39:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 20 Aug 2007 16:39:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-11428 ] autotest with --drb and --color
Message-ID: <20070820203932.ED01A5240D23@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: autotest with --drb and --color

Initial Comment:
No color is seen when using autotest with an options file that contains both --drb and --color

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

Comment By: Richard Poirier (richpoirier)
Date: 2007-08-20 15:39

Message:
I have the same problem running "ruby script/spec spec/ --drb --colour"

I'm running:
Vista 32-bit
ruby 1.8.6
rails 1.2.3
win32console 1.0.8
rspec 1.0.8

I found a workaround, but don't really understand why it works. Maybe it can help someone really fix the bug though.

I add "require 'Win32/Console/ANSI'" before the last line in my spec
file and change the STDOUT parameter in the last line to $stdout.

So my <project>/script/spec looks like this:

#!/usr/bin/env ruby
$LOAD_PATH.unshift(File.expand_path(File.dirname(__FILE__) + "/../
vendor/plugins/rspec/lib"))
require 'spec'
require 'Win32/Console/ANSI'
::Spec::Runner::CommandLine.run(ARGV, STDERR, $stdout, true, true)

It's not perfect. The first run will print the output to the console
that spec_server is running in. All subsequent runs will print to the
correct console though. I couldn't figure out why it was doing this
but the way it works is good enough for me until the bug is really fixed.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-09 19:54

Message:
OS X.4.9
Ruby 1.8.6
rspec trunk (@ rev. 2087)
rspec_on_rails trunk
autotest 3.6.0

This bug has been around since Nick Seiger's original
plugin.  David C. and I have talked about it before on the
mailing list.  

I would have written a spec, but I got intimidated by the
idea of mocking DRB, Autotest, and color values given by the
terminal.


Sorry that you had to drop in that boilerplate message.  I'm
sorry that it's even a boiler plate message.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-08 05:55

Message:
OS X.4.9
Ruby 1.8.6
rspec trunk (@ rev. 2087)
rspec_on_rails trunk
autotest 3.6.0

This bug has been around since Nick Seiger's original
plugin.  David C. and I have talked about it before on the
mailing list.  

I would have written a spec, but I got intimidated by the
idea of mocking DRB, Autotest, and color values given by the
terminal.


Sorry that you had to drop in that boilerplate message.  I'm
sorry that it's even a boiler plate message.

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-08 04:14

Message:
Before investigating this we need to know the versions of all 
relevant software you are using, for example:

* OS X 10.4.9
* Ruby 1.8.6
* RSpec 1.8.2 or RSpec trunk r1643
* Spec::Rails 1.8.2 or Spec::Rails tag r1234...
* Rails 1.2.3 or Rails edge r5645
* Whatever other relevant software.

Without this information it's like solving 1 equation (your 
question) with 5 unknown variables (the versions).

We strongly recommend that you use the latest released version of
RSpec, alternatively the subversion trunk (if you're the bleeding
edge kind of person).

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

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

From dan at tastapod.com  Mon Aug 20 16:59:08 2007
From: dan at tastapod.com (Dan North)
Date: Mon, 20 Aug 2007 21:59:08 +0100
Subject: [rspec-devel] Translated Specs?
In-Reply-To: <57c63afe0708201339s1cac6d69h1c0f3b7058c25356@mail.gmail.com>
References: <1d7ddd110708181736m3bd16f80v25d3da976d29f34c@mail.gmail.com>	<57c63afe0708182017h625c9e4eud32f2f400a39930d@mail.gmail.com>	<8d961d900708190710h2e111751w45e94a7d2e4fb36d@mail.gmail.com>	<57c63afe0708190728q6501c64p3b64e979dfe9d4c7@mail.gmail.com>	<8d961d900708190740h62b8d8b4qaeee9eab0fbf07d3@mail.gmail.com>	<57c63afe0708190744k68f50ea9g33b2336cea0ed1de@mail.gmail.com>	<46C9F55F.5070002@tastapod.com>	<8d961d900708201324i694e8b4ehfccc771597cb2b66@mail.gmail.com>
	<57c63afe0708201339s1cac6d69h1c0f3b7058c25356@mail.gmail.com>
Message-ID: <46CA009C.8010801@tastapod.com>

David Chelimsky wrote:
> On 8/20/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>   
>> On 8/20/07, Dan North <dan at tastapod.com> wrote:
>>     
>>>  Forgive me chiming in here.
>>>
>>>  My understanding of the conventions for 3-part numbering are:
>>>
>>>  Major release (1.x -> 2.0) can break compatibility with deprecated APIs
>>>  Minor release (1.3, -> 1.4) maintains backward compatibility but can
>>> introduce new interfaces
>>>  Patch release (1.3.2 -> 1.3.3) is a bugfix that doesn't change any
>>> (significant) APIs
>>>
>>>       
>> This is a good convention that I think we should have as a guideline.
>> When it comes to the mock constraint args, I think it's a fairly
>> insignificant part of the API. Sure - many people are already using
>> it, but we also have a translator that will translate 99% of them (not
>> scientific).
>>
>> I therefore think we can release 1.1 and remove support for the
>> deprecated constraints - doing a 2.0 seems a little drastic.
>>     
>
> I also feel like 2.0 is a bit pre-mature. We only released 1.0 a few
> months ago, we're just getting the story runner merged in now, etc. I
> think the story runner needs to bake in for a while, let ppl use it,
> see what sorts of feature requests come up, etc, before we just dump
> out a 2.0 release.
>
> 2 cents.
>
>   
I agree - I don't think the matcher changes are significant enough to 
warrant bumping the major release number, and 1.0 is still very new. I 
didn't mean to give the impression I want to see a 2.0 release number 
any time soon. The point I was making is that it's important to manage 
the message around breaking backward compatibility with a 1.x release.

Cheers,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070820/647193fb/attachment.html 

From noreply at rubyforge.org  Mon Aug 20 21:26:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 20 Aug 2007 21:26:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13020 ]
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	should not be included in helper specs?
Message-ID: <20070821012601.E4D3EA970002@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike Vincent (agile)
Assigned to: Nobody (None)
Summary: ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods should not be included in helper specs?

Initial Comment:
1.0.6+ includes additional modules into the helper specs. 

including ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods

causes conflicts in helpers as it redefines several methods, such as << 

def simple_example(name)
  markup = ''
  markup << content_tag(:h1, "hello #{name}")
  markup
end

simple_example('foo').should have_tag('h1', 'foo')


will throw a confusing method missing error from nil about the << method.








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

>Comment By: Mike Vincent (agile)
Date: 2007-08-20 20:26

Message:
I think maybe I wasn't clear in the original message. I
don't believe the GeneratorMethods module is intended to be
mixed into the helper context and breaks things while it is
included. 

Not much clearer, I know. Someday me speak gooder.

Index:
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
===================================================================
---
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
       (revision 2411)
+++
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
       (working copy)
@@ -32,7 +32,7 @@
           include ActionView::Helpers::NumberHelper
           include ActionView::Helpers::PaginationHelper
rescue nil #removed after 1.2.3
           include ActionView::Helpers::PrototypeHelper
-          include
ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
+          #include
ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
           include ActionView::Helpers::ScriptaculousHelper
           include ActionView::Helpers::TagHelper
           include ActionView::Helpers::TextHelper


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

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

From brian.takita at gmail.com  Tue Aug 21 02:39:37 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Aug 2007 23:39:37 -0700
Subject: [rspec-devel] Refactorings merged into Trunk
Message-ID: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>

Hello, I merged the Behaviour and Example refactorings into trunk.
Please check it out and see how it works for you.

It would be great to iron any domain name inconsistencies and parts
that are difficult to understand. If it is hard to understand, lets
make it simple. :)

Here are some of the changes in Rspec core:
* BehaviourEval is gone
* Behaviour is a subclass of Module, which allows it to take the place
of BehaviourEval
* Behaviour#inherit is removed
* ExampleSpace replaces BehaviourEval#execution_context_class

Here are some of the changes in Rspec on rails:
* Each Behaviour subclass is stripped down
* Each Behaviour subclass has a ExampleSpace subclass, with
functionality moved from the Behaviour subclasses to the ExampleSpace
subclasses

Here are some of the changes to pre_commit:
* If the rspec_on_rails pre_commit fails, the generated files are left
behind to specs can be run individually in example_rails_app
* General refactorings

Thanks,
Brian Takita

From aslak.hellesoy at gmail.com  Tue Aug 21 03:38:10 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 21 Aug 2007 09:38:10 +0200
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
Message-ID: <8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>

This is great,

I'm getting a (surprising) error when running rake from the top level
(Ruby 1.8.4). The error is not printed to stdout, but I found it in
doc/output/report.html:

Kernel when creating behaviours with describe

should fail when no block given

expected ArgumentError, got #<Errno::EMFILE: Too many open files - getcwd>

/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations.rb:52:in
`fail_with'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/handler.rb:16:in
`handle_matcher'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/extensions/object.rb:32:in
`should'
./spec/spec/runner/extensions/kernel_spec.rb:13:
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:81:in
`run_example'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:26:in `run'
/usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:24:in `run'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:179:in
`run'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:173:in
`run'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:60:in
`run_behaviours'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:59:in
`run_behaviours'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:23:in
`run'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/command_line.rb:17:in
`run'
/Users/aslakhellesoy/scm/rspec/trunk/rspec/bin/spec:3:

An other question:

What's Behaviour#xit and Behaviour#xspecify ?

Aslak

On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> Hello, I merged the Behaviour and Example refactorings into trunk.
> Please check it out and see how it works for you.
>
> It would be great to iron any domain name inconsistencies and parts
> that are difficult to understand. If it is hard to understand, lets
> make it simple. :)
>
> Here are some of the changes in Rspec core:
> * BehaviourEval is gone
> * Behaviour is a subclass of Module, which allows it to take the place
> of BehaviourEval
> * Behaviour#inherit is removed
> * ExampleSpace replaces BehaviourEval#execution_context_class
>
> Here are some of the changes in Rspec on rails:
> * Each Behaviour subclass is stripped down
> * Each Behaviour subclass has a ExampleSpace subclass, with
> functionality moved from the Behaviour subclasses to the ExampleSpace
> subclasses
>
> Here are some of the changes to pre_commit:
> * If the rspec_on_rails pre_commit fails, the generated files are left
> behind to specs can be run individually in example_rails_app
> * General refactorings
>
> Thanks,
> Brian Takita
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brian.takita at gmail.com  Tue Aug 21 03:59:54 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 00:59:54 -0700
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
Message-ID: <1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>

On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> This is great,
Cool.
>
> I'm getting a (surprising) error when running rake from the top level
> (Ruby 1.8.4). The error is not printed to stdout, but I found it in
> doc/output/report.html:
>
> Kernel when creating behaviours with describe
>
> should fail when no block given
>
> expected ArgumentError, got #<Errno::EMFILE: Too many open files - getcwd>
>
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations.rb:52:in
> `fail_with'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/handler.rb:16:in
> `handle_matcher'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/extensions/object.rb:32:in
> `should'
> ./spec/spec/runner/extensions/kernel_spec.rb:13:
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:81:in
> `run_example'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:26:in `run'
> /usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:24:in `run'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:179:in
> `run'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:173:in
> `run'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:60:in
> `run_behaviours'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:59:in
> `run_behaviours'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:23:in
> `run'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/command_line.rb:17:in
> `run'
> /Users/aslakhellesoy/scm/rspec/trunk/rspec/bin/spec:3:
>

I can't reproduce this issue, but I think it has to do with
PreCommit::Rspec#fix_cr_lf
There was a File.open(f).read which was not being closed.

> An other question:
>
> What's Behaviour#xit and Behaviour#xspecify ?
>
xit and xspecify makes a pending spec. I found it very useful when
refactoring to isolate an example when the focused behaviour runner
did not work because it is easy to search and replace.

I suppose I could have done:
it "should do something" do; pending

but it didn't occur to me at that moment. I am also used to this
convention to disable a test, as well as alot of other developers I
know.

> Aslak
>
> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello, I merged the Behaviour and Example refactorings into trunk.
> > Please check it out and see how it works for you.
> >
> > It would be great to iron any domain name inconsistencies and parts
> > that are difficult to understand. If it is hard to understand, lets
> > make it simple. :)
> >
> > Here are some of the changes in Rspec core:
> > * BehaviourEval is gone
> > * Behaviour is a subclass of Module, which allows it to take the place
> > of BehaviourEval
> > * Behaviour#inherit is removed
> > * ExampleSpace replaces BehaviourEval#execution_context_class
> >
> > Here are some of the changes in Rspec on rails:
> > * Each Behaviour subclass is stripped down
> > * Each Behaviour subclass has a ExampleSpace subclass, with
> > functionality moved from the Behaviour subclasses to the ExampleSpace
> > subclasses
> >
> > Here are some of the changes to pre_commit:
> > * If the rspec_on_rails pre_commit fails, the generated files are left
> > behind to specs can be run individually in example_rails_app
> > * General refactorings
> >
> > Thanks,
> > Brian Takita
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brian.takita at gmail.com  Tue Aug 21 04:00:58 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 01:00:58 -0700
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
Message-ID: <1d7ddd110708210100y79135281qeb60d7d04b7ff9a9@mail.gmail.com>

On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > This is great,
> Cool.
> >
> > I'm getting a (surprising) error when running rake from the top level
> > (Ruby 1.8.4). The error is not printed to stdout, but I found it in
> > doc/output/report.html:
> >
> > Kernel when creating behaviours with describe
> >
> > should fail when no block given
> >
> > expected ArgumentError, got #<Errno::EMFILE: Too many open files - getcwd>
> >
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations.rb:52:in
> > `fail_with'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/handler.rb:16:in
> > `handle_matcher'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/extensions/object.rb:32:in
> > `should'
> > ./spec/spec/runner/extensions/kernel_spec.rb:13:
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:81:in
> > `run_example'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:26:in `run'
> > /usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:24:in `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:179:in
> > `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:173:in
> > `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:60:in
> > `run_behaviours'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:59:in
> > `run_behaviours'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:23:in
> > `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/command_line.rb:17:in
> > `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/bin/spec:3:
> >
>
> I can't reproduce this issue, but I think it has to do with
> PreCommit::Rspec#fix_cr_lf
> There was a File.open(f).read which was not being closed.
I checked in an attempt to fix this.
>
> > An other question:
> >
> > What's Behaviour#xit and Behaviour#xspecify ?
> >
> xit and xspecify makes a pending spec. I found it very useful when
> refactoring to isolate an example when the focused behaviour runner
> did not work because it is easy to search and replace.
>
> I suppose I could have done:
> it "should do something" do; pending
>
> but it didn't occur to me at that moment. I am also used to this
> convention to disable a test, as well as alot of other developers I
> know.
>
> > Aslak
> >
> > On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > Hello, I merged the Behaviour and Example refactorings into trunk.
> > > Please check it out and see how it works for you.
> > >
> > > It would be great to iron any domain name inconsistencies and parts
> > > that are difficult to understand. If it is hard to understand, lets
> > > make it simple. :)
> > >
> > > Here are some of the changes in Rspec core:
> > > * BehaviourEval is gone
> > > * Behaviour is a subclass of Module, which allows it to take the place
> > > of BehaviourEval
> > > * Behaviour#inherit is removed
> > > * ExampleSpace replaces BehaviourEval#execution_context_class
> > >
> > > Here are some of the changes in Rspec on rails:
> > > * Each Behaviour subclass is stripped down
> > > * Each Behaviour subclass has a ExampleSpace subclass, with
> > > functionality moved from the Behaviour subclasses to the ExampleSpace
> > > subclasses
> > >
> > > Here are some of the changes to pre_commit:
> > > * If the rspec_on_rails pre_commit fails, the generated files are left
> > > behind to specs can be run individually in example_rails_app
> > > * General refactorings
> > >
> > > Thanks,
> > > Brian Takita
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>

From aslak.hellesoy at gmail.com  Tue Aug 21 04:17:24 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 21 Aug 2007 10:17:24 +0200
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
Message-ID: <8d961d900708210117v53f843cdn5775ed05fcbaa223@mail.gmail.com>

On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > This is great,
> Cool.
> >
> > I'm getting a (surprising) error when running rake from the top level
> > (Ruby 1.8.4). The error is not printed to stdout, but I found it in
> > doc/output/report.html:
> >
> > Kernel when creating behaviours with describe
> >
> > should fail when no block given
> >
> > expected ArgumentError, got #<Errno::EMFILE: Too many open files - getcwd>
> >
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations.rb:52:in
> > `fail_with'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/handler.rb:16:in
> > `handle_matcher'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/extensions/object.rb:32:in
> > `should'
> > ./spec/spec/runner/extensions/kernel_spec.rb:13:
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:81:in
> > `run_example'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:26:in `run'
> > /usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:24:in `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:179:in
> > `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:173:in
> > `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:60:in
> > `run_behaviours'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:59:in
> > `run_behaviours'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:23:in
> > `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/command_line.rb:17:in
> > `run'
> > /Users/aslakhellesoy/scm/rspec/trunk/rspec/bin/spec:3:
> >
>
> I can't reproduce this issue, but I think it has to do with
> PreCommit::Rspec#fix_cr_lf
> There was a File.open(f).read which was not being closed.
>
> > An other question:
> >
> > What's Behaviour#xit and Behaviour#xspecify ?
> >
> xit and xspecify makes a pending spec. I found it very useful when
> refactoring to isolate an example when the focused behaviour runner
> did not work because it is easy to search and replace.
>
> I suppose I could have done:
> it "should do something" do; pending
>

I understand - I used to do it all the time with xUnit. However, I
don't think introducing a third "pending" technique is a good idea, it
will only confuse users and make us look wishy-washy ;-)

Aslak

> but it didn't occur to me at that moment. I am also used to this
> convention to disable a test, as well as alot of other developers I
> know.
>
> > Aslak
> >
> > On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > Hello, I merged the Behaviour and Example refactorings into trunk.
> > > Please check it out and see how it works for you.
> > >
> > > It would be great to iron any domain name inconsistencies and parts
> > > that are difficult to understand. If it is hard to understand, lets
> > > make it simple. :)
> > >
> > > Here are some of the changes in Rspec core:
> > > * BehaviourEval is gone
> > > * Behaviour is a subclass of Module, which allows it to take the place
> > > of BehaviourEval
> > > * Behaviour#inherit is removed
> > > * ExampleSpace replaces BehaviourEval#execution_context_class
> > >
> > > Here are some of the changes in Rspec on rails:
> > > * Each Behaviour subclass is stripped down
> > > * Each Behaviour subclass has a ExampleSpace subclass, with
> > > functionality moved from the Behaviour subclasses to the ExampleSpace
> > > subclasses
> > >
> > > Here are some of the changes to pre_commit:
> > > * If the rspec_on_rails pre_commit fails, the generated files are left
> > > behind to specs can be run individually in example_rails_app
> > > * General refactorings
> > >
> > > Thanks,
> > > Brian Takita
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Tue Aug 21 04:21:40 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 21 Aug 2007 10:21:40 +0200
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <1d7ddd110708210100y79135281qeb60d7d04b7ff9a9@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
	<1d7ddd110708210100y79135281qeb60d7d04b7ff9a9@mail.gmail.com>
Message-ID: <8d961d900708210121i61764e75g4f5aa186e09c2cfb@mail.gmail.com>

On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > This is great,
> > Cool.
> > >
> > > I'm getting a (surprising) error when running rake from the top level
> > > (Ruby 1.8.4). The error is not printed to stdout, but I found it in
> > > doc/output/report.html:
> > >
> > > Kernel when creating behaviours with describe
> > >
> > > should fail when no block given
> > >
> > > expected ArgumentError, got #<Errno::EMFILE: Too many open files - getcwd>
> > >
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations.rb:52:in
> > > `fail_with'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/handler.rb:16:in
> > > `handle_matcher'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/extensions/object.rb:32:in
> > > `should'
> > > ./spec/spec/runner/extensions/kernel_spec.rb:13:
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:81:in
> > > `run_example'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:26:in `run'
> > > /usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:24:in `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:179:in
> > > `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:173:in
> > > `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:60:in
> > > `run_behaviours'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:59:in
> > > `run_behaviours'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:23:in
> > > `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/command_line.rb:17:in
> > > `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/bin/spec:3:
> > >
> >
> > I can't reproduce this issue, but I think it has to do with
> > PreCommit::Rspec#fix_cr_lf
> > There was a File.open(f).read which was not being closed.
> I checked in an attempt to fix this.

Spot on! That fixed it for me.

Aslak

> >
> > > An other question:
> > >
> > > What's Behaviour#xit and Behaviour#xspecify ?
> > >
> > xit and xspecify makes a pending spec. I found it very useful when
> > refactoring to isolate an example when the focused behaviour runner
> > did not work because it is easy to search and replace.
> >
> > I suppose I could have done:
> > it "should do something" do; pending
> >
> > but it didn't occur to me at that moment. I am also used to this
> > convention to disable a test, as well as alot of other developers I
> > know.
> >
> > > Aslak
> > >
> > > On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > > Hello, I merged the Behaviour and Example refactorings into trunk.
> > > > Please check it out and see how it works for you.
> > > >
> > > > It would be great to iron any domain name inconsistencies and parts
> > > > that are difficult to understand. If it is hard to understand, lets
> > > > make it simple. :)
> > > >
> > > > Here are some of the changes in Rspec core:
> > > > * BehaviourEval is gone
> > > > * Behaviour is a subclass of Module, which allows it to take the place
> > > > of BehaviourEval
> > > > * Behaviour#inherit is removed
> > > > * ExampleSpace replaces BehaviourEval#execution_context_class
> > > >
> > > > Here are some of the changes in Rspec on rails:
> > > > * Each Behaviour subclass is stripped down
> > > > * Each Behaviour subclass has a ExampleSpace subclass, with
> > > > functionality moved from the Behaviour subclasses to the ExampleSpace
> > > > subclasses
> > > >
> > > > Here are some of the changes to pre_commit:
> > > > * If the rspec_on_rails pre_commit fails, the generated files are left
> > > > behind to specs can be run individually in example_rails_app
> > > > * General refactorings
> > > >
> > > > Thanks,
> > > > Brian Takita
> > > > _______________________________________________
> > > > 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 brian at pivotallabs.com  Tue Aug 21 04:49:16 2007
From: brian at pivotallabs.com (Brian Takita)
Date: Tue, 21 Aug 2007 01:49:16 -0700
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <8d961d900708210117v53f843cdn5775ed05fcbaa223@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
	<8d961d900708210117v53f843cdn5775ed05fcbaa223@mail.gmail.com>
Message-ID: <1d7ddd110708210149r3169f1a0k758d43ac2a823762@mail.gmail.com>

I'm not sure if having 3 solutions is confusing, especially if people
are used to it. I'm curious if this would make it easier to learn
rspec coming from an xUnit world. I certainly have heard the question
"how do I x out my specs" several times.

>From personal experience, I reimplement this method quite often in
projects I'm involved with because people find it easy to use and
remember.
Its also the easiest solution to search and replace on the table.

> make us look wishy-washy ;-)
I prefer responding to users' needs.

Is this something that can be voted on?

On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > This is great,
> > Cool.
> > >
> > > I'm getting a (surprising) error when running rake from the top level
> > > (Ruby 1.8.4). The error is not printed to stdout, but I found it in
> > > doc/output/report.html:
> > >
> > > Kernel when creating behaviours with describe
> > >
> > > should fail when no block given
> > >
> > > expected ArgumentError, got #<Errno::EMFILE: Too many open files - getcwd>
> > >
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations.rb:52:in
> > > `fail_with'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/handler.rb:16:in
> > > `handle_matcher'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/expectations/extensions/object.rb:32:in
> > > `should'
> > > ./spec/spec/runner/extensions/kernel_spec.rb:13:
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:81:in
> > > `run_example'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:26:in `run'
> > > /usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/example.rb:24:in `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:179:in
> > > `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/dsl/behaviour.rb:173:in
> > > `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:60:in
> > > `run_behaviours'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:59:in
> > > `run_behaviours'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/behaviour_runner.rb:23:in
> > > `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/lib/spec/runner/command_line.rb:17:in
> > > `run'
> > > /Users/aslakhellesoy/scm/rspec/trunk/rspec/bin/spec:3:
> > >
> >
> > I can't reproduce this issue, but I think it has to do with
> > PreCommit::Rspec#fix_cr_lf
> > There was a File.open(f).read which was not being closed.
> >
> > > An other question:
> > >
> > > What's Behaviour#xit and Behaviour#xspecify ?
> > >
> > xit and xspecify makes a pending spec. I found it very useful when
> > refactoring to isolate an example when the focused behaviour runner
> > did not work because it is easy to search and replace.
> >
> > I suppose I could have done:
> > it "should do something" do; pending
> >
>
> I understand - I used to do it all the time with xUnit. However, I
> don't think introducing a third "pending" technique is a good idea, it
> will only confuse users and make us look wishy-washy ;-)
>
> Aslak
>
> > but it didn't occur to me at that moment. I am also used to this
> > convention to disable a test, as well as alot of other developers I
> > know.
> >
> > > Aslak
> > >
> > > On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > > Hello, I merged the Behaviour and Example refactorings into trunk.
> > > > Please check it out and see how it works for you.
> > > >
> > > > It would be great to iron any domain name inconsistencies and parts
> > > > that are difficult to understand. If it is hard to understand, lets
> > > > make it simple. :)
> > > >
> > > > Here are some of the changes in Rspec core:
> > > > * BehaviourEval is gone
> > > > * Behaviour is a subclass of Module, which allows it to take the place
> > > > of BehaviourEval
> > > > * Behaviour#inherit is removed
> > > > * ExampleSpace replaces BehaviourEval#execution_context_class
> > > >
> > > > Here are some of the changes in Rspec on rails:
> > > > * Each Behaviour subclass is stripped down
> > > > * Each Behaviour subclass has a ExampleSpace subclass, with
> > > > functionality moved from the Behaviour subclasses to the ExampleSpace
> > > > subclasses
> > > >
> > > > Here are some of the changes to pre_commit:
> > > > * If the rspec_on_rails pre_commit fails, the generated files are left
> > > > behind to specs can be run individually in example_rails_app
> > > > * General refactorings
> > > >
> > > > Thanks,
> > > > Brian Takita
> > > > _______________________________________________
> > > > 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 brian.takita at gmail.com  Tue Aug 21 05:01:09 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 02:01:09 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example -> ExampleDefinition
	&& ExampleSpace -> Example
Message-ID: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>

I propose renaming Example to ExampleDefinition and ExampleSpace to
Example because the current ExampleSpace is the object that the
example is run with.

It seems a little too meta to be understandable, in my opinion.

ExampleDefinition is a fitting name for the current Example class
because it would hold the description and matches? method.

It also responsible for running the example and setting up and tearing
down the mocks.
Does this mean that this class has too much responsibility?

From brian.takita at gmail.com  Tue Aug 21 05:04:59 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 02:04:59 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace class
	subclasses Test::Unit::TestCase
Message-ID: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>

This is a way to utilize Test::Unit in rspec.

There are a number of BDD frameworks that utilize Test::Unit to create
a simple implementation.

This could also be a first step to using Test::Unit's runner.

From aslak.hellesoy at gmail.com  Tue Aug 21 05:19:12 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 21 Aug 2007 11:19:12 +0200
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <1d7ddd110708210149r3169f1a0k758d43ac2a823762@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
	<8d961d900708210117v53f843cdn5775ed05fcbaa223@mail.gmail.com>
	<1d7ddd110708210149r3169f1a0k758d43ac2a823762@mail.gmail.com>
Message-ID: <8d961d900708210219t636b99dfh81b0c535ff94a617@mail.gmail.com>

On 8/21/07, Brian Takita <brian at pivotallabs.com> wrote:
> I'm not sure if having 3 solutions is confusing, especially if people
> are used to it. I'm curious if this would make it easier to learn
> rspec coming from an xUnit world. I certainly have heard the question
> "how do I x out my specs" several times.
>

Is it harder to answer "put a pending statement as the first statement
the block" than "replace it with xit"?

> >From personal experience, I reimplement this method quite often in
> projects I'm involved with because people find it easy to use and
> remember.
> Its also the easiest solution to search and replace on the table.
>
> > make us look wishy-washy ;-)
> I prefer responding to users' needs.
>
> Is this something that can be voted on?
>

Sure! =)

-1

Aslak

From aslak.hellesoy at gmail.com  Tue Aug 21 05:28:20 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 21 Aug 2007 11:28:20 +0200
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
Message-ID: <8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>

On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> This is a way to utilize Test::Unit in rspec.
>
> There are a number of BDD frameworks that utilize Test::Unit to create
> a simple implementation.
>
> This could also be a first step to using Test::Unit's runner.

Using Test::Unit's runner might be compelling, but I don't know how
easy it will be to make it behave like today's RSpec. We have a lot of
extra command line options, different output and so on. I'm not sure
what it takes to make it happen.

What would be the main benefit for users? And for us?

Aslak

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

From dchelimsky at gmail.com  Tue Aug 21 09:47:44 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Aug 2007 08:47:44 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
Message-ID: <57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>

On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> I propose renaming Example to ExampleDefinition and ExampleSpace to
> Example because the current ExampleSpace is the object that the
> example is run with.
>
> It seems a little too meta to be understandable, in my opinion.

I agree about it feeling meta. And I like the idea of changing
ExampleSpace to Example. I'm not sure about ExampleDefinition though.
Other ideas that come to mind are:

ExampleWrapper
ExampleProxy
ExampleDriver
ExampleConfig
ExampleContainer

Not really in love with any of these, but you get the idea.

> ExampleDefinition is a fitting name for the current Example class
> because it would hold the description and matches? method.
>
> It also responsible for running the example and setting up and tearing
> down the mocks.
> Does this mean that this class has too much responsibility?

I don't think so - it manages the lifecycle of an Example (perhaps
ExampleLifeCycleManager???) and these things are all related.

From dchelimsky at gmail.com  Tue Aug 21 10:00:33 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Aug 2007 09:00:33 -0500
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <8d961d900708210219t636b99dfh81b0c535ff94a617@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
	<8d961d900708210117v53f843cdn5775ed05fcbaa223@mail.gmail.com>
	<1d7ddd110708210149r3169f1a0k758d43ac2a823762@mail.gmail.com>
	<8d961d900708210219t636b99dfh81b0c535ff94a617@mail.gmail.com>
Message-ID: <57c63afe0708210700q3163e64dp726d28af2b9e9d@mail.gmail.com>

On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/21/07, Brian Takita <brian at pivotallabs.com> wrote:
> > I'm not sure if having 3 solutions is confusing, especially if people
> > are used to it. I'm curious if this would make it easier to learn
> > rspec coming from an xUnit world. I certainly have heard the question
> > "how do I x out my specs" several times.
> >
>
> Is it harder to answer "put a pending statement as the first statement
> the block" than "replace it with xit"?
>
> > >From personal experience, I reimplement this method quite often in
> > projects I'm involved with because people find it easy to use and
> > remember.
> > Its also the easiest solution to search and replace on the table.
> >
> > > make us look wishy-washy ;-)
> > I prefer responding to users' needs.
> >
> > Is this something that can be voted on?
> >
>
> Sure! =)
>
> -1

-1 more. There are already 3 ways to do pending, because the pending
method lets you wrap some code in a block, or not.

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

From james.deville at gmail.com  Tue Aug 21 11:42:57 2007
From: james.deville at gmail.com (Jim Deville)
Date: Tue, 21 Aug 2007 08:42:57 -0700
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <57c63afe0708210700q3163e64dp726d28af2b9e9d@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
	<8d961d900708210117v53f843cdn5775ed05fcbaa223@mail.gmail.com>
	<1d7ddd110708210149r3169f1a0k758d43ac2a823762@mail.gmail.com>
	<8d961d900708210219t636b99dfh81b0c535ff94a617@mail.gmail.com>
	<57c63afe0708210700q3163e64dp726d28af2b9e9d@mail.gmail.com>
Message-ID: <5EC69DE1-4955-4238-8B38-58DB8F5499B0@gmail.com>

>>>
>>>> make us look wishy-washy ;-)
>>> I prefer responding to users' needs.
>>>
>>> Is this something that can be voted on?
>>>
>>
>> Sure! =)
>>
>> -1
>
> -1 more. There are already 3 ways to do pending, because the pending
> method lets you wrap some code in a block, or not.
>
>>
>> Aslak
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

-1, I agree with what's already been said. I think that if a user is  
moving to the BDD/Rspec world, then they won't mind doing things  
differently, since most of BDD is different.

Jim

From brian.takita at gmail.com  Tue Aug 21 12:36:56 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 09:36:56 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
Message-ID: <1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>

On 8/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > I propose renaming Example to ExampleDefinition and ExampleSpace to
> > Example because the current ExampleSpace is the object that the
> > example is run with.
> >
> > It seems a little too meta to be understandable, in my opinion.
>
> I agree about it feeling meta. And I like the idea of changing
> ExampleSpace to Example. I'm not sure about ExampleDefinition though.
> Other ideas that come to mind are:
>
> ExampleWrapper
> ExampleProxy
> ExampleDriver
> ExampleConfig
> ExampleContainer
>
> Not really in love with any of these, but you get the idea.
>
> > ExampleDefinition is a fitting name for the current Example class
> > because it would hold the description and matches? method.
> >
> > It also responsible for running the example and setting up and tearing
> > down the mocks.
> > Does this mean that this class has too much responsibility?
>
> I don't think so - it manages the lifecycle of an Example (perhaps
> ExampleLifeCycleManager???) and these things are all related.
I'm suspicious of anything named Manager :)
How about ExampleLifeCycle?
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brian.takita at gmail.com  Tue Aug 21 12:56:56 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 09:56:56 -0700
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <5EC69DE1-4955-4238-8B38-58DB8F5499B0@gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
	<8d961d900708210117v53f843cdn5775ed05fcbaa223@mail.gmail.com>
	<1d7ddd110708210149r3169f1a0k758d43ac2a823762@mail.gmail.com>
	<8d961d900708210219t636b99dfh81b0c535ff94a617@mail.gmail.com>
	<57c63afe0708210700q3163e64dp726d28af2b9e9d@mail.gmail.com>
	<5EC69DE1-4955-4238-8B38-58DB8F5499B0@gmail.com>
Message-ID: <1d7ddd110708210956g37db873el4ded1131f2ff3553@mail.gmail.com>

On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
> >>>
> >>>> make us look wishy-washy ;-)
> >>> I prefer responding to users' needs.
> >>>
> >>> Is this something that can be voted on?
> >>>
> >>
> >> Sure! =)
> >>
> >> -1
> Is it harder to answer "put a pending statement as the first statement
> the block" than "replace it with xit"?
Yes it is. The search/replace needs to be a regex instead of a simple replace.
Its different than the convention and that evokes frustration and
sometimes anger. It also causes anger to say "well just do blah, blah,
blah" in that situation. People are emotional.

> >
> > -1 more. There are already 3 ways to do pending, because the pending
> > method lets you wrap some code in a block, or not.
I didn't know that. That is a good answer. I still find xit more
convenient because the spec I want to run is often in the middle of
the file. Its also simple and just an alias, which is conceptually
cheap.

Also, can pending we wrapped around describe blocks? That would be
nice. But even then, two pending blocks are needed.
> >
> >>
> >> Aslak
> >> _______________________________________________
> >> rspec-devel mailing list
> >> rspec-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-devel
> >>
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
>
> -1, I agree with what's already been said. I think that if a user is
> moving to the BDD/Rspec world, then they won't mind doing things
> differently, since most of BDD is different.
That's sort of presumptuous. Alot of people are being turned off by
rspec being "unnecessarily" pedantic. People like the benefit of
rspec's DSL (behaviour/it and the should methods). I doubt that the
pending keyword is a selling point. Its just seems different.
>
> Jim
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
It seems there is no support for this, so I'll remove xit and
xspecify. This particular feature request is not that big of a deal
anyways.

I don't mean to be unnecessarily harsh, I'm just relaying the thoughts
of the people I work with (real rspec users who aren't necessarily in
love with it). These users also tend not to participate in forums like
this, so they are underrepresented here.

I want rspec to be better, just like all of us. :)

From brian.takita at gmail.com  Tue Aug 21 13:08:52 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 10:08:52 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
Message-ID: <1d7ddd110708211008w1d09d645uaf2f54cf381c9257@mail.gmail.com>

On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > This is a way to utilize Test::Unit in rspec.
> >
> > There are a number of BDD frameworks that utilize Test::Unit to create
> > a simple implementation.
> >
> > This could also be a first step to using Test::Unit's runner.
>
> Using Test::Unit's runner might be compelling, but I don't know how
> easy it will be to make it behave like today's RSpec. We have a lot of
> extra command line options, different output and so on. I'm not sure
> what it takes to make it happen.
>
> What would be the main benefit for users? And for us?
The main benefit is a clean, evolutionary path from Test::Unit to
rspec. I just got this request from Nathan Sobo when I talked to him
this morning.

Alot of people are frustrated that they need to run rake test and rake
spec, for example. It is a hurdle of adopting rspec. I've also seen
resentment because of this.

The evidence is the multitude of Test::Unit BDD frameworks.
* test/spec
* Spec Unit
* Shoulda
* Screw::Unit
* Simply BDD

It would be cool if we can consolidate effort and even be the catalyst
to improve Test::Unit.

Additions to Test::Unit would simply work. Having a Test::Unit runner
would arguably lead to a simpler codebase.

I don't mind taking the responsibility for the confusing
Behaviour/Example architecture that is in our current release, but it
was a solution to solve a problem rooted in the fact that we were not
using Test::Unit.
>
> Aslak
>
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Tue Aug 21 13:39:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 13:39:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20070821173929.E3A305240DA9@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 10:39

Message:
+1

I'm running into this problem and it makes it very difficult to debug without a full stack trace.


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

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

From james.deville at gmail.com  Tue Aug 21 13:40:11 2007
From: james.deville at gmail.com (Jim Deville)
Date: Tue, 21 Aug 2007 10:40:11 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
Message-ID: <5FDF39FB-3905-4C4A-848F-26D96BFBECD4@gmail.com>


On Aug 21, 2007, at 9:36 AM, Brian Takita wrote:

> On 8/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
>>> I propose renaming Example to ExampleDefinition and ExampleSpace to
>>> Example because the current ExampleSpace is the object that the
>>> example is run with.
>>>
>>> It seems a little too meta to be understandable, in my opinion.
>>
>> I agree about it feeling meta. And I like the idea of changing
>> ExampleSpace to Example. I'm not sure about ExampleDefinition though.
>> Other ideas that come to mind are:
>>
>> ExampleWrapper
>> ExampleProxy
>> ExampleDriver
>> ExampleConfig
>> ExampleContainer
>>
>> Not really in love with any of these, but you get the idea.
>>
>>> ExampleDefinition is a fitting name for the current Example class
>>> because it would hold the description and matches? method.
>>>
>>> It also responsible for running the example and setting up and  
>>> tearing
>>> down the mocks.
>>> Does this mean that this class has too much responsibility?
>>
>> I don't think so - it manages the lifecycle of an Example (perhaps
>> ExampleLifeCycleManager???) and these things are all related.
> I'm suspicious of anything named Manager :)
> How about ExampleLifeCycle?

LifeCycle seems a little buzzwordish... what about ExampleController  
or something similar
>> _______________________________________________
>> 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 james.deville at gmail.com  Tue Aug 21 13:45:19 2007
From: james.deville at gmail.com (Jim Deville)
Date: Tue, 21 Aug 2007 10:45:19 -0700
Subject: [rspec-devel] Refactorings merged into Trunk
In-Reply-To: <1d7ddd110708210956g37db873el4ded1131f2ff3553@mail.gmail.com>
References: <1d7ddd110708202339u35f3898arc45bc70aed4626a2@mail.gmail.com>
	<8d961d900708210038o7442617bmb697081544106df2@mail.gmail.com>
	<1d7ddd110708210059g52c13b39t2b3e8d59d1ce0528@mail.gmail.com>
	<8d961d900708210117v53f843cdn5775ed05fcbaa223@mail.gmail.com>
	<1d7ddd110708210149r3169f1a0k758d43ac2a823762@mail.gmail.com>
	<8d961d900708210219t636b99dfh81b0c535ff94a617@mail.gmail.com>
	<57c63afe0708210700q3163e64dp726d28af2b9e9d@mail.gmail.com>
	<5EC69DE1-4955-4238-8B38-58DB8F5499B0@gmail.com>
	<1d7ddd110708210956g37db873el4ded1131f2ff3553@mail.gmail.com>
Message-ID: <BA28DC1B-FD72-4E40-BE21-126D04D61C1F@gmail.com>

>
> Also, can pending we wrapped around describe blocks? That would be
> nice. But even then, two pending blocks are needed.

+1 on this idea. If it isn't already implemented
>>>
>> -1, I agree with what's already been said. I think that if a user is
>> moving to the BDD/Rspec world, then they won't mind doing things
>> differently, since most of BDD is different.
> That's sort of presumptuous. Alot of people are being turned off by
> rspec being "unnecessarily" pedantic. People like the benefit of
> rspec's DSL (behaviour/it and the should methods). I doubt that the
> pending keyword is a selling point. Its just seems different.
>>

My bad, I guess I assumed that if someone were to come to BDD's mind- 
point, then they would be willing to change. I forgot that there are  
a lot of other convenience's like this, such as using Test::Unit  
assertions in an example.  From that point of view, it is a good  
idea, it still might be overloading with the other forms already  
existing.

>> Jim
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> It seems there is no support for this, so I'll remove xit and
> xspecify. This particular feature request is not that big of a deal
> anyways.
>
> I don't mean to be unnecessarily harsh, I'm just relaying the thoughts
> of the people I work with (real rspec users who aren't necessarily in
> love with it). These users also tend not to participate in forums like
> this, so they are underrepresented here.
>
> I want rspec to be better, just like all of us. :)
>

:)


From james.deville at gmail.com  Tue Aug 21 13:49:53 2007
From: james.deville at gmail.com (Jim Deville)
Date: Tue, 21 Aug 2007 10:49:53 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <1d7ddd110708211008w1d09d645uaf2f54cf381c9257@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<1d7ddd110708211008w1d09d645uaf2f54cf381c9257@mail.gmail.com>
Message-ID: <6EF7BE96-660B-4986-BAEC-D3323774BA7C@gmail.com>


On Aug 21, 2007, at 10:08 AM, Brian Takita wrote:
>>
>>
>> What would be the main benefit for users? And for us?
> The main benefit is a clean, evolutionary path from Test::Unit to
> rspec. I just got this request from Nathan Sobo when I talked to him
> this morning.
>
> Alot of people are frustrated that they need to run rake test and rake
> spec, for example. It is a hurdle of adopting rspec. I've also seen
> resentment because of this.
>

Why not suggest that they only run rake? RSpec over-rides the default  
rake task.

> The evidence is the multitude of Test::Unit BDD frameworks.
> * test/spec
> * Spec Unit
> * Shoulda
> * Screw::Unit
> * Simply BDD
>
> It would be cool if we can consolidate effort and even be the catalyst
> to improve Test::Unit.
>

Agreed. Although I'm not entirely sure if the multitude of Test::Unit  
BDD frameworks should be considered as evidence for a desire to  
change. It could just be NIH, plus not knowing about RSpec when the  
framework was started. (Ignore this if you know it to be false ;))

> Additions to Test::Unit would simply work. Having a Test::Unit runner
> would arguably lead to a simpler codebase.
>

It would be kinda nice if there were a good plugin architecture to  
either Test::Unit or Rspec. Something that would allow frameworks  
like RSpec to be built on top of the runner, instead of around the  
runner.

> I don't mind taking the responsibility for the confusing
> Behaviour/Example architecture that is in our current release, but it
> was a solution to solve a problem rooted in the fact that we were not
> using Test::Unit.
>>

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070821/62c07c79/attachment.html 

From noreply at rubyforge.org  Tue Aug 21 13:53:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 13:53:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20070821175340.CDB575240DC0@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 17:53

Message:
Ryan - this is a request for a different backtrace, not a full backtrace. You can already get a full backtrace with the -b option.

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 17:39

Message:
+1

I'm running into this problem and it makes it very difficult to debug without a full stack trace.


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

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

From dchelimsky at gmail.com  Tue Aug 21 13:54:47 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Aug 2007 12:54:47 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <5FDF39FB-3905-4C4A-848F-26D96BFBECD4@gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
	<5FDF39FB-3905-4C4A-848F-26D96BFBECD4@gmail.com>
Message-ID: <57c63afe0708211054t7a516645l76bd4d3ce1281a10@mail.gmail.com>

On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
>
> On Aug 21, 2007, at 9:36 AM, Brian Takita wrote:
>
> > On 8/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> >>> I propose renaming Example to ExampleDefinition and ExampleSpace to
> >>> Example because the current ExampleSpace is the object that the
> >>> example is run with.
> >>>
> >>> It seems a little too meta to be understandable, in my opinion.
> >>
> >> I agree about it feeling meta. And I like the idea of changing
> >> ExampleSpace to Example. I'm not sure about ExampleDefinition though.
> >> Other ideas that come to mind are:
> >>
> >> ExampleWrapper
> >> ExampleProxy
> >> ExampleDriver
> >> ExampleConfig
> >> ExampleContainer
> >>
> >> Not really in love with any of these, but you get the idea.
> >>
> >>> ExampleDefinition is a fitting name for the current Example class
> >>> because it would hold the description and matches? method.
> >>>
> >>> It also responsible for running the example and setting up and
> >>> tearing
> >>> down the mocks.
> >>> Does this mean that this class has too much responsibility?
> >>
> >> I don't think so - it manages the lifecycle of an Example (perhaps
> >> ExampleLifeCycleManager???) and these things are all related.
> > I'm suspicious of anything named Manager :)
> > How about ExampleLifeCycle?
>
> LifeCycle seems a little buzzwordish... what about ExampleController
> or something similar

Oh cool. Controller doesn't have any baggage attached to it either :)

We're getting there, but not quite yet. Keep the ideas coming ...

> >> _______________________________________________
> >> 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 srbaker at pobox.com  Tue Aug 21 14:08:15 2007
From: srbaker at pobox.com (Steven R. Baker)
Date: Tue, 21 Aug 2007 14:08:15 -0400
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
 class subclasses Test::Unit::TestCase
In-Reply-To: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
Message-ID: <46CB2A0F.908@pobox.com>

Brian Takita wrote:
> This is a way to utilize Test::Unit in rspec.
>
> There are a number of BDD frameworks that utilize Test::Unit to create
> a simple implementation.
>
> This could also be a first step to using Test::Unit's runner.
>   
Agreed.  The recent change of hands of Test::Unit to Ryan Davis poses a 
great opportunity to do this.  I want to see RSpec and Test::Unit 
tool-compatible.  ZenTest, autotest, Test::Rails, heckle, and others all 
have their own special hooks to work with both, and it's time for that 
to stop.

I have some thoughts on the right way to do this, but we're off to have 
a baby in less than 6 hours, so I don't have time for immediate 
discussion.  This is, however, something I'm *very* interested in 
working on in the next week or three.

I'm going to collect my thoughts on it, and do some research.  When we 
get back from the hospital, I'll explain what I have in mind.  If 
anything.  And I'd like feedback.

-Steven


From brian.takita at gmail.com  Tue Aug 21 14:14:36 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 11:14:36 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <6EF7BE96-660B-4986-BAEC-D3323774BA7C@gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<1d7ddd110708211008w1d09d645uaf2f54cf381c9257@mail.gmail.com>
	<6EF7BE96-660B-4986-BAEC-D3323774BA7C@gmail.com>
Message-ID: <1d7ddd110708211114n79dd7746o91dae4d91b129bd6@mail.gmail.com>

On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
>
>
> On Aug 21, 2007, at 10:08 AM, Brian Takita wrote:
>
>
> What would be the main benefit for users? And for us?
> The main benefit is a clean, evolutionary path from Test::Unit to
> rspec. I just got this request from Nathan Sobo when I talked to him
> this morning.
>
> Alot of people are frustrated that they need to run rake test and rake
> spec, for example. It is a hurdle of adopting rspec. I've also seen
> resentment because of this.
>
>
> Why not suggest that they only run rake? RSpec over-rides the default rake
> task.
Interesting. We made a testspec task. I'll need to look into it.
Personally, I'm not a fan of using rake to run the suite. I prefer
suite.rb files, but I'm glad you mentioned this. :)
>
> The evidence is the multitude of Test::Unit BDD frameworks.
> * test/spec
> * Spec Unit
> * Shoulda
> * Screw::Unit
> * Simply BDD
>
> It would be cool if we can consolidate effort and even be the catalyst
> to improve Test::Unit.
>
>
> Agreed. Although I'm not entirely sure if the multitude of Test::Unit BDD
> frameworks should be considered as evidence for a desire to change. It could
> just be NIH, plus not knowing about RSpec when the framework was started.
> (Ignore this if you know it to be false ;))
I know that its not NIH. Its frustration about how difficult it is to
extend rspec. People want simplicity.
See http://www.pivotalblabs.com/articles/2007/08/17/taking-a-break-from-rspec
http://giantrobots.thoughtbot.com/2007/3/9/specin-rspec-with-rails

This issue has also been mentioned to me by Josh Susser, Ryan Davis,
and Eric Hodel.
>
> Additions to Test::Unit would simply work. Having a Test::Unit runner
> would arguably lead to a simpler codebase.
>
>
> It would be kinda nice if there were a good plugin architecture to either
> Test::Unit or Rspec. Something that would allow frameworks like RSpec to be
> built on top of the runner, instead of around the runner.
Yes, that would be awesome. It would benefit everybody. :)
>
> I don't mind taking the responsibility for the confusing
> Behaviour/Example architecture that is in our current release, but it
> was a solution to solve a problem rooted in the fact that we were not
> using Test::Unit.
>
>
> Jim
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brian.takita at gmail.com  Tue Aug 21 14:15:05 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 11:15:05 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <1d7ddd110708211114n79dd7746o91dae4d91b129bd6@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<1d7ddd110708211008w1d09d645uaf2f54cf381c9257@mail.gmail.com>
	<6EF7BE96-660B-4986-BAEC-D3323774BA7C@gmail.com>
	<1d7ddd110708211114n79dd7746o91dae4d91b129bd6@mail.gmail.com>
Message-ID: <1d7ddd110708211115s2a9bb73fuc0f641456885f542@mail.gmail.com>

On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
> >
> >
> > On Aug 21, 2007, at 10:08 AM, Brian Takita wrote:
> >
> >
> > What would be the main benefit for users? And for us?
> > The main benefit is a clean, evolutionary path from Test::Unit to
> > rspec. I just got this request from Nathan Sobo when I talked to him
> > this morning.
> >
> > Alot of people are frustrated that they need to run rake test and rake
> > spec, for example. It is a hurdle of adopting rspec. I've also seen
> > resentment because of this.
> >
> >
> > Why not suggest that they only run rake? RSpec over-rides the default rake
> > task.
> Interesting. We made a testspec task. I'll need to look into it.
We, as in "Pivotal Labs", the company I work for.
> Personally, I'm not a fan of using rake to run the suite. I prefer
> suite.rb files, but I'm glad you mentioned this. :)
> >
> > The evidence is the multitude of Test::Unit BDD frameworks.
> > * test/spec
> > * Spec Unit
> > * Shoulda
> > * Screw::Unit
> > * Simply BDD
> >
> > It would be cool if we can consolidate effort and even be the catalyst
> > to improve Test::Unit.
> >
> >
> > Agreed. Although I'm not entirely sure if the multitude of Test::Unit BDD
> > frameworks should be considered as evidence for a desire to change. It could
> > just be NIH, plus not knowing about RSpec when the framework was started.
> > (Ignore this if you know it to be false ;))
> I know that its not NIH. Its frustration about how difficult it is to
> extend rspec. People want simplicity.
> See http://www.pivotalblabs.com/articles/2007/08/17/taking-a-break-from-rspec
> http://giantrobots.thoughtbot.com/2007/3/9/specin-rspec-with-rails
>
> This issue has also been mentioned to me by Josh Susser, Ryan Davis,
> and Eric Hodel.
> >
> > Additions to Test::Unit would simply work. Having a Test::Unit runner
> > would arguably lead to a simpler codebase.
> >
> >
> > It would be kinda nice if there were a good plugin architecture to either
> > Test::Unit or Rspec. Something that would allow frameworks like RSpec to be
> > built on top of the runner, instead of around the runner.
> Yes, that would be awesome. It would benefit everybody. :)
> >
> > I don't mind taking the responsibility for the confusing
> > Behaviour/Example architecture that is in our current release, but it
> > was a solution to solve a problem rooted in the fact that we were not
> > using Test::Unit.
> >
> >
> > Jim
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>

From noreply at rubyforge.org  Tue Aug 21 14:22:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 14:22:11 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20070821182211.15C4E5240DC8@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 11:22

Message:
Is this problem unrelated to the backtrace tweaker then? From my understanding that just removes some lines of the backtrace.

Either way, I'm sure my problem is the same as mentioned in this ticket. It's a helper spec and I'm getting the same error message. Here's the full backtrace: http://pastie.caboo.se/89745

I'm on edge rails as you can probably tell. Maybe that is part of the problem?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 10:53

Message:
Ryan - this is a request for a different backtrace, not a full backtrace. You can already get a full backtrace with the -b option.

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 10:39

Message:
+1

I'm running into this problem and it makes it very difficult to debug without a full stack trace.


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

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

From noreply at rubyforge.org  Tue Aug 21 14:27:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 14:27:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20070821182707.076BC5240DCC@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 18:27

Message:
Jay's problem is that the filtered backtrace is lying about the location of the error. The backtrace you posted is a complete backtrace and tells you exactly where to look to debug the problem. Two completely separate issues.

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 18:22

Message:
Is this problem unrelated to the backtrace tweaker then? From my understanding that just removes some lines of the backtrace.

Either way, I'm sure my problem is the same as mentioned in this ticket. It's a helper spec and I'm getting the same error message. Here's the full backtrace: http://pastie.caboo.se/89745

I'm on edge rails as you can probably tell. Maybe that is part of the problem?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 17:53

Message:
Ryan - this is a request for a different backtrace, not a full backtrace. You can already get a full backtrace with the -b option.

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 17:39

Message:
+1

I'm running into this problem and it makes it very difficult to debug without a full stack trace.


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

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

From noreply at rubyforge.org  Tue Aug 21 14:35:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 14:35:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20070821183558.9E0FE5240DD3@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 11:35

Message:
I understand now. Sorry for the confusion. I see there's a separate ticket [#13020] which (I think) covers the problem I am having. I'll post over there.

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

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

Message:
Jay's problem is that the filtered backtrace is lying about the location of the error. The backtrace you posted is a complete backtrace and tells you exactly where to look to debug the problem. Two completely separate issues.

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 11:22

Message:
Is this problem unrelated to the backtrace tweaker then? From my understanding that just removes some lines of the backtrace.

Either way, I'm sure my problem is the same as mentioned in this ticket. It's a helper spec and I'm getting the same error message. Here's the full backtrace: http://pastie.caboo.se/89745

I'm on edge rails as you can probably tell. Maybe that is part of the problem?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 10:53

Message:
Ryan - this is a request for a different backtrace, not a full backtrace. You can already get a full backtrace with the -b option.

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 10:39

Message:
+1

I'm running into this problem and it makes it very difficult to debug without a full stack trace.


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

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

From noreply at rubyforge.org  Tue Aug 21 14:39:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 14:39:49 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13141 ] backtrace should only be tweaked
	at end, not beginning
Message-ID: <20070821183949.CBBC35240DD3@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: backtrace should only be tweaked at end, not beginning

Initial Comment:
Imagine this failing view spec:

describe "this spec" do
  it "should fail" do
    form_for(nil,nil){}
  end
end

The output is:

NoMethodError in 'LabelledBuilderHelper providing labelled_form_for should fail'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<
./spec/helpers/labelled_builder_helper_spec.rb:4:
script/spec:4:

But of course there is no << in line 4 of this spec.  The error happened inside form_for, and thus the error message is tweaked away.

I think tweak_backtrace should only eliminate those matching lines that occur at the end of the backtrace - i.e. the many parent classes of rails.  Ya?


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 18:39

Message:
Great. Thanks for playing!

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 18:35

Message:
I understand now. Sorry for the confusion. I see there's a separate ticket [#13020] which (I think) covers the problem I am having. I'll post over there.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 18:27

Message:
Jay's problem is that the filtered backtrace is lying about the location of the error. The backtrace you posted is a complete backtrace and tells you exactly where to look to debug the problem. Two completely separate issues.

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 18:22

Message:
Is this problem unrelated to the backtrace tweaker then? From my understanding that just removes some lines of the backtrace.

Either way, I'm sure my problem is the same as mentioned in this ticket. It's a helper spec and I'm getting the same error message. Here's the full backtrace: http://pastie.caboo.se/89745

I'm on edge rails as you can probably tell. Maybe that is part of the problem?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-21 17:53

Message:
Ryan - this is a request for a different backtrace, not a full backtrace. You can already get a full backtrace with the -b option.

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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 17:39

Message:
+1

I'm running into this problem and it makes it very difficult to debug without a full stack trace.


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

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

From noreply at rubyforge.org  Tue Aug 21 14:54:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 14:54:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13020 ]
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	should not be included in helper specs?
Message-ID: <20070821185421.0D63D5240DF1@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike Vincent (agile)
Assigned to: Nobody (None)
Summary: ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods should not be included in helper specs?

Initial Comment:
1.0.6+ includes additional modules into the helper specs. 

including ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods

causes conflicts in helpers as it redefines several methods, such as << 

def simple_example(name)
  markup = ''
  markup << content_tag(:h1, "hello #{name}")
  markup
end

simple_example('foo').should have_tag('h1', 'foo')


will throw a confusing method missing error from nil about the << method.








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

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 11:54

Message:
+1

I had this problem which led to a lot of confusion since the error message is not very helpful. Commenting out the include statement fixed it, although it makes me wonder if I'm breaking something else by doing this. Why are the generator methods included in the first place?

At least my specs are passing again...

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

Comment By: Mike Vincent (agile)
Date: 2007-08-20 18:26

Message:
I think maybe I wasn't clear in the original message. I
don't believe the GeneratorMethods module is intended to be
mixed into the helper context and breaks things while it is
included. 

Not much clearer, I know. Someday me speak gooder.

Index:
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
===================================================================
---
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
       (revision 2411)
+++
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
       (working copy)
@@ -32,7 +32,7 @@
           include ActionView::Helpers::NumberHelper
           include ActionView::Helpers::PaginationHelper
rescue nil #removed after 1.2.3
           include ActionView::Helpers::PrototypeHelper
-          include
ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
+          #include
ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
           include ActionView::Helpers::ScriptaculousHelper
           include ActionView::Helpers::TagHelper
           include ActionView::Helpers::TextHelper


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

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

From dan at tastapod.com  Tue Aug 21 18:36:06 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 21 Aug 2007 23:36:06 +0100
Subject: [rspec-devel] [Proposed Refactoring] - Example
 ->	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
Message-ID: <46CB68D6.4050305@tastapod.com>

Hi Brian.

Brian Takita wrote:
> On 8/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>   
>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
>>     
>>> I propose renaming Example to ExampleDefinition and ExampleSpace to
>>> Example because the current ExampleSpace is the object that the
>>> example is run with.
>>>
>>> It seems a little too meta to be understandable, in my opinion.
>>>       
>> I agree about it feeling meta. And I like the idea of changing
>> ExampleSpace to Example. I'm not sure about ExampleDefinition though.
>> Other ideas that come to mind are:
>>
>> ExampleWrapper
>> ExampleProxy
>> ExampleDriver
>> ExampleConfig
>> ExampleContainer
>>     
The story runner calls it a World, because it's where everything takes 
place (it's a term I reused from jbehave). In the example runner I would 
expect to see something like ExampleInstance. Or maybe World again. I 
like calling the example block Example. That speaks to me.
>> Not really in love with any of these, but you get the idea.
>>
>>     
>>> ExampleDefinition is a fitting name for the current Example class
>>> because it would hold the description and matches? method.
>>>
>>> It also responsible for running the example and setting up and tearing
>>> down the mocks.
>>> Does this mean that this class has too much responsibility?
>>>       
>> I don't think so - it manages the lifecycle of an Example (perhaps
>> ExampleLifeCycleManager???) and these things are all related.
>>     
> I'm suspicious of anything named Manager :)
>   
Seconded. Or Helper or Service or Util while we're at it :)
> How about ExampleLifeCycle?
>   
Not so much.

Cheers,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070821/eeda8b0d/attachment-0001.html 

From james.deville at gmail.com  Tue Aug 21 18:58:20 2007
From: james.deville at gmail.com (Jim Deville)
Date: Tue, 21 Aug 2007 15:58:20 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example
	->	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <46CB68D6.4050305@tastapod.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
	<46CB68D6.4050305@tastapod.com>
Message-ID: <9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>

>>> ExampleLifeCycleManager???) and these things are all related.
>>>
>> I'm suspicious of anything named Manager :)
>>
> Seconded. Or Helper or Service or Util while we're at it :)

Service rings with me, perhaps some combination of it could work.

>
>> How about ExampleLifeCycle?
>>
> Not so much.
>
> Cheers,
> Dan
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Tue Aug 21 19:38:30 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 22 Aug 2007 01:38:30 +0200
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
	<46CB68D6.4050305@tastapod.com>
	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
Message-ID: <8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>

On 8/22/07, Jim Deville <james.deville at gmail.com> wrote:
> >>> ExampleLifeCycleManager???) and these things are all related.
> >>>
> >> I'm suspicious of anything named Manager :)
> >>
> > Seconded. Or Helper or Service or Util while we're at it :)
>
> Service rings with me, perhaps some combination of it could work.
>

I think Dan meant Manager,Helper,Service,Util are all suspicious
names, and I agree.

I like ExampleWorld and Example.

Aslak

> >
> >> How about ExampleLifeCycle?
> >>
> > Not so much.
> >
> > Cheers,
> > Dan
> > _______________________________________________
> > 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 21 20:19:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 20:19:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822001954.C220AA97000B@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 02:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 17:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 17:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 17:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From undees at gmail.com  Tue Aug 21 20:20:59 2007
From: undees at gmail.com (Ian Dees)
Date: Tue, 21 Aug 2007 17:20:59 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses
Message-ID: <ad4f9af90708211720g34f033eci3cb2b93dc7acf167@mail.gmail.com>

Quoth the many:

> > I know that its not NIH. Its frustration about how difficult it is to
> > extend rspec. People want simplicity.

Hmmm.  Bending and extending RSpec in a couple of
we-probably-shouldn't ways hasn't been that nasty for us in my day
job.  But then again, we're not using it to test Rails apps; that's
probably a whole other level of complexity.

The biggest problems we encountered were method names/signatures
moving out from under us after an upgrade---which we fully expected,
since we weren't using the publicly documented interfaces.

In some cases RSpec later implemented stuff we had been tacking
awkwardly on, so we were able to add functionality by removing our own
code.  Gotta love that.

> > > Additions to Test::Unit would simply work. Having a Test::Unit runner
> > > would arguably lead to a simpler codebase.

How?  Wouldn't that introduce a dependency on Test::Unit?

> > > It would be kinda nice if there were a good plugin architecture to either
> > > Test::Unit or Rspec.

That's a really good idea---my work colleagues and I could make our
current hacks a little more future-proof, and the folks who (for some
reason) like Test::Unit can find a way to make the two play nicely
together.

I guess I just don't understand the recent rash of "we're abandoning
RSpec" or "we're coding the next great RSpec alternative" blog posts.
I suppose software inevitably runs into things it just can't do well
as its user base increases.

But for us, over a year after we started looking at this thing, the
bloom is still firmly on the rose.

--Ian

From noreply at rubyforge.org  Tue Aug 21 20:28:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 20:28:07 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822002808.63FB75240EBB@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 15:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From noreply at rubyforge.org  Tue Aug 21 20:41:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 20:41:07 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822004107.103F2A97000B@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 15:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From noreply at rubyforge.org  Tue Aug 21 20:51:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 20:51:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822005101.E03145240EBB@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 02:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 02:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 02:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 02:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 17:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 17:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 17:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From noreply at rubyforge.org  Tue Aug 21 21:03:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 21 Aug 2007 21:03:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822010341.A0127A970009@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 15:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From brian.takita at gmail.com  Tue Aug 21 21:17:28 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 18:17:28 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
	<46CB68D6.4050305@tastapod.com>
	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
Message-ID: <1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>

On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/22/07, Jim Deville <james.deville at gmail.com> wrote:
> > >>> ExampleLifeCycleManager???) and these things are all related.
> > >>>
> > >> I'm suspicious of anything named Manager :)
> > >>
> > > Seconded. Or Helper or Service or Util while we're at it :)
> >
> > Service rings with me, perhaps some combination of it could work.
> >
>
> I think Dan meant Manager,Helper,Service,Util are all suspicious
> names, and I agree.
>
> I like ExampleWorld and Example.

Yes. I like it.

>
> Aslak
>
> > >
> > >> How about ExampleLifeCycle?
> > >>
> > > Not so much.
> > >
> > > Cheers,
> > > Dan
> > > _______________________________________________
> > > 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  Tue Aug 21 23:35:36 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Aug 2007 22:35:36 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
	<46CB68D6.4050305@tastapod.com>
	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
Message-ID: <57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>

On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 8/22/07, Jim Deville <james.deville at gmail.com> wrote:
> > > >>> ExampleLifeCycleManager???) and these things are all related.
> > > >>>
> > > >> I'm suspicious of anything named Manager :)
> > > >>
> > > > Seconded. Or Helper or Service or Util while we're at it :)
> > >
> > > Service rings with me, perhaps some combination of it could work.
> > >
> >
> > I think Dan meant Manager,Helper,Service,Util are all suspicious
> > names, and I agree.
> >
> > I like ExampleWorld and Example.

Well - which is which - in the story runner, the world is where the
stuff happens - which would equate to the current example_space. So
Example would remain Example, and ExampleSpace would become
ExampleWorld. Is that what you are thinking Brian?

>
> Yes. I like it.
>
> >
> > Aslak
> >
> > > >
> > > >> How about ExampleLifeCycle?
> > > >>
> > > > Not so much.
> > > >
> > > > Cheers,
> > > > Dan
> > > > _______________________________________________
> > > > 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 james.deville at gmail.com  Wed Aug 22 00:23:30 2007
From: james.deville at gmail.com (Jim Deville)
Date: Tue, 21 Aug 2007 21:23:30 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses
In-Reply-To: <ad4f9af90708211720g34f033eci3cb2b93dc7acf167@mail.gmail.com>
References: <ad4f9af90708211720g34f033eci3cb2b93dc7acf167@mail.gmail.com>
Message-ID: <C0F22117-07D3-435B-AE40-E499CA3F4EE8@gmail.com>


>
>>>> It would be kinda nice if there were a good plugin architecture  
>>>> to either
>>>> Test::Unit or Rspec.
>
> That's a really good idea---my work colleagues and I could make our
> current hacks a little more future-proof, and the folks who (for some
> reason) like Test::Unit can find a way to make the two play nicely
> together.
>

I just wish I knew more about both projects internals to do something  
about it. Still might be worth a try, though.

> I guess I just don't understand the recent rash of "we're abandoning
> RSpec" or "we're coding the next great RSpec alternative" blog posts.
> I suppose software inevitably runs into things it just can't do well
> as its user base increases.
>

For me, I am a big supporter of RSpec and BDD, but I have trouble  
explaining why I like it so much more than Test::Unit to other  
people. I also have a co-worker who doubts the benefits of using  
mocks to isolate the tests. He mainly wonders why we are duplicating  
our effort by doing Unit tests and Integration tests. I am in the odd  
position of being one of the most knowledgeble Ruby/RSpec coders at  
my job, but I am the least experienced in OO Design, TDD/BDD and  
Agile processes. I wonder if a little more push on the BDD ideas  
would help build faith in the RSpec framework and techniques.

> But for us, over a year after we started looking at this thing, the
> bloom is still firmly on the rose.
>
> --Ian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

Jim

From dchelimsky at gmail.com  Wed Aug 22 00:59:33 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Aug 2007 23:59:33 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses
In-Reply-To: <C0F22117-07D3-435B-AE40-E499CA3F4EE8@gmail.com>
References: <ad4f9af90708211720g34f033eci3cb2b93dc7acf167@mail.gmail.com>
	<C0F22117-07D3-435B-AE40-E499CA3F4EE8@gmail.com>
Message-ID: <57c63afe0708212159x5f40d953o4a8ca38f78391d74@mail.gmail.com>

On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
>
> >
> >>>> It would be kinda nice if there were a good plugin architecture
> >>>> to either
> >>>> Test::Unit or Rspec.
> >
> > That's a really good idea---my work colleagues and I could make our
> > current hacks a little more future-proof, and the folks who (for some
> > reason) like Test::Unit can find a way to make the two play nicely
> > together.
> >
>
> I just wish I knew more about both projects internals to do something
> about it. Still might be worth a try, though.
>
> > I guess I just don't understand the recent rash of "we're abandoning
> > RSpec" or "we're coding the next great RSpec alternative" blog posts.
> > I suppose software inevitably runs into things it just can't do well
> > as its user base increases.
> >
>
> For me, I am a big supporter of RSpec and BDD, but I have trouble
> explaining why I like it so much more than Test::Unit to other
> people. I also have a co-worker who doubts the benefits of using
> mocks to isolate the tests.

Mocking has been around a lot longer than BDD and there is a wealth of
literature on why mocking is good and why, to those who think so, it
is bad.

> He mainly wonders why we are duplicating
> our effort by doing Unit tests and Integration tests.

The really difficult thing to get across about mocking, and about TDD
in general, is that it is a process, not an end result. Duplication
between Programmer Tests (what you're calling Unit Tests) and Customer
Tests (what you're calling Integration Tests) is temporal - there are
moments in time when there is duplication and then, because we're
refactoring relentlessly, that duplication goes away. That's because
when we're refactoring we're not changing the system requirements as
expressed in the Customer Tests, but we are changing the granular
requirements of individual objects, as expressed in the Programmer
Tests.

This all make sense?


> I am in the odd
> position of being one of the most knowledgeble Ruby/RSpec coders at
> my job, but I am the least experienced in OO Design, TDD/BDD and
> Agile processes. I wonder if a little more push on the BDD ideas
> would help build faith in the RSpec framework and techniques.
>
> > But for us, over a year after we started looking at this thing, the
> > bloom is still firmly on the rose.
> >
> > --Ian
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
>
> Jim
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Aug 22 01:32:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 01:32:52 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13271 ] incorrect behaviour with
	expect_render and stub_render
Message-ID: <20070822053252.DB5255240ED8@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: incorrect behaviour with expect_render and stub_render

Initial Comment:
>From Michael Hamann in http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797.

Failing spec:
http://pastie.caboo.se/89880

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

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

From noreply at rubyforge.org  Wed Aug 22 01:34:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 01:34:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13271 ] incorrect behaviour with
	expect_render and stub_render
Message-ID: <20070822053442.3C2225240EDB@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
>Assigned to: David Chelimsky (dchelimsky)
Summary: incorrect behaviour with expect_render and stub_render

Initial Comment:
>From Michael Hamann in http://rubyforge.org/tracker/?func=detail&atid=3149&aid=12547&group_id=797.

Failing spec:
http://pastie.caboo.se/89880

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 05:34

Message:
Fixed in r2421.

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

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

From noreply at rubyforge.org  Wed Aug 22 01:38:55 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 01:38:55 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822053855.71C1A5240ED8@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 05:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 15:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From brian.takita at gmail.com  Wed Aug 22 01:49:29 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 22:49:29 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <46CB2A0F.908@pobox.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<46CB2A0F.908@pobox.com>
Message-ID: <1d7ddd110708212249v6e68e50r21e1186dabeaa203@mail.gmail.com>

On 8/21/07, Steven R. Baker <srbaker at pobox.com> wrote:
> Brian Takita wrote:
> > This is a way to utilize Test::Unit in rspec.
> >
> > There are a number of BDD frameworks that utilize Test::Unit to create
> > a simple implementation.
> >
> > This could also be a first step to using Test::Unit's runner.
> >
> Agreed.  The recent change of hands of Test::Unit to Ryan Davis poses a
> great opportunity to do this.  I want to see RSpec and Test::Unit
> tool-compatible.  ZenTest, autotest, Test::Rails, heckle, and others all
> have their own special hooks to work with both, and it's time for that
> to stop.
>
> I have some thoughts on the right way to do this, but we're off to have
> a baby in less than 6 hours, so I don't have time for immediate
Wow, congratulations, Steven!! :)
> discussion.  This is, however, something I'm *very* interested in
> working on in the next week or three.
>
> I'm going to collect my thoughts on it, and do some research.  When we
> get back from the hospital, I'll explain what I have in mind.  If
> anything.  And I'd like feedback.
>
> -Steven
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From mailing_lists at railsnewbie.com  Wed Aug 22 02:18:41 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 22 Aug 2007 02:18:41 -0400
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses
In-Reply-To: <57c63afe0708212159x5f40d953o4a8ca38f78391d74@mail.gmail.com>
References: <ad4f9af90708211720g34f033eci3cb2b93dc7acf167@mail.gmail.com>
	<C0F22117-07D3-435B-AE40-E499CA3F4EE8@gmail.com>
	<57c63afe0708212159x5f40d953o4a8ca38f78391d74@mail.gmail.com>
Message-ID: <C0F62976-99B1-4F6A-BCA0-C31ECCC4D7EE@railsnewbie.com>


On Aug 22, 2007, at 12:59 AM, David Chelimsky wrote:

> On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
>>
>>>
>>>>>> It would be kinda nice if there were a good plugin architecture
>>>>>> to either
>>>>>> Test::Unit or Rspec.
>>>
>>> That's a really good idea---my work colleagues and I could make our
>>> current hacks a little more future-proof, and the folks who (for  
>>> some
>>> reason) like Test::Unit can find a way to make the two play nicely
>>> together.
>>>
>>
>> I just wish I knew more about both projects internals to do something
>> about it. Still might be worth a try, though.
>>
>>> I guess I just don't understand the recent rash of "we're abandoning
>>> RSpec" or "we're coding the next great RSpec alternative" blog  
>>> posts.
>>> I suppose software inevitably runs into things it just can't do well
>>> as its user base increases.
>>>
>>
>> For me, I am a big supporter of RSpec and BDD, but I have trouble
>> explaining why I like it so much more than Test::Unit to other
>> people. I also have a co-worker who doubts the benefits of using
>> mocks to isolate the tests.
>
> Mocking has been around a lot longer than BDD and there is a wealth of
> literature on why mocking is good and why, to those who think so, it
> is bad.
>
>> He mainly wonders why we are duplicating
>> our effort by doing Unit tests and Integration tests.

One of the real advantages to having a "test" suite is refactoring.   
The test suite allows you to sleep at night.  And if your integration  
tests (alone) cover 100% of the code (go ahead - run rcov on your  
integration tests), then those granular tests are a waste.  Getting  
your integration tests to cover 100% of the code on any non-trivial  
project seems simple enough - until you realize that the complexity  
is incredibly enormous (I'm thinking of the simplicity of Zeno  
catching up with the tortoise).

So if you are thinking it of testing - then sure, some of it is  
duplication, but most of it is testing the incredible complexity in  
your system which would be nearly impossible to express in a high  
level customer-story/integration test.  This is only further  
magnified by the lack of a type system in Ruby.


More relevant speak, but I'm too tired to connect it:

Having just acquired a new rails project, with something like 30  
models and 30 controllers, I've really just learned one of the  
biggest benefits of TDD - and that is documentation - not just for  
domain experts, but future coders who are going to work on YOUR  
complex system.  In a way, you could think of specs (or unit tests)  
as the best comments possible.  Normal Comments can lie (and will, as  
the system changes), but executable specs never can.  Integrations  
tests are good for testing the system - but they aren't going to give  
you examples of how the objects interact on a more granular level.   
But they too, can serve as high level comments (or specifications)  
for what the system can do (usually more for the non-hacker).

If the only benefit your receiving from this process is a good night  
sleep (i.e. testing) - then it certainly is a waste to "duplicate"  
these things.  But the BDD side of things is to treat these "tests"  
as just an extra added benefit (like finding a twenty dollar bill  
under your couch).  Hey - look at that!  I've designed an  
understandable system (the real benefit of BDD/TDD) - and it just  
happens to be nearly bug free (the "testing" involved)!

>
> The really difficult thing to get across about mocking, and about TDD
> in general, is that it is a process, not an end result.

+1, but:

Certainly not a silver bullet : ) , although I do think it is a great  
process to have - and one I wouldn't live without - just like I'd  
refuse to work on a project where the other developers didn't use  
version control.

Scott


From brian.takita at gmail.com  Wed Aug 22 02:48:55 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Aug 2007 23:48:55 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
	<46CB68D6.4050305@tastapod.com>
	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
Message-ID: <1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>

On 8/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 8/22/07, Jim Deville <james.deville at gmail.com> wrote:
> > > > >>> ExampleLifeCycleManager???) and these things are all related.
> > > > >>>
> > > > >> I'm suspicious of anything named Manager :)
> > > > >>
> > > > > Seconded. Or Helper or Service or Util while we're at it :)
> > > >
> > > > Service rings with me, perhaps some combination of it could work.
> > > >
> > >
> > > I think Dan meant Manager,Helper,Service,Util are all suspicious
> > > names, and I agree.
> > >
> > > I like ExampleWorld and Example.
>
> Well - which is which - in the story runner, the world is where the
> stuff happens - which would equate to the current example_space. So
> Example would remain Example, and ExampleSpace would become
> ExampleWorld. Is that what you are thinking Brian?
I was actuallly thinking the opposite.

Comparing this with Test::Unit, a Behaviour is equivalent to a TestCase class.
ExampleSpace + Example is equivalent to a TestCase instance.

Example holds the run and error adding methods, while ExampleSpace is
unpolluted by the run and other methods (not that this is really an
issue with Test::Unit).

Here the the responsibilities for each part:
* The life of the example call chain (run, before and after callbacks,
setup and teardown mocks, etc.)
* The actual execution of the code within the example block, along
with the other methods defined in the Describe block

Developers who wish to extend rspec will probably be subclassing
Behaviour and the current ExampleSpace. I feel a little strange having
other developers subclassing a class named ExampleSpace. Maybe
ExampleWorld is better, but Example seems like the most inviting name
to extend.

>
> >
> > Yes. I like it.
> >
> > >
> > > Aslak
> > >
> > > > >
> > > > >> How about ExampleLifeCycle?
> > > > >>
> > > > > Not so much.
> > > > >
> > > > > Cheers,
> > > > > Dan
> > > > > _______________________________________________
> > > > > rspec-devel mailing list
> > > > > rspec-devel at rubyforge.org
> > > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Aug 22 03:24:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 03:24:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822072427.1650B5240EED@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 17:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 15:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

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

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From noreply at rubyforge.org  Wed Aug 22 06:10:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 06:10:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13274 ] ThrowSymbol recognized a
	NameError triggered by Kernel#method_missing as a thrown Symbol
Message-ID: <20070822101049.01B4A5240B01@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Phillips (jicksta)
Assigned to: Nobody (None)
Summary: ThrowSymbol recognized a NameError triggered by Kernel#method_missing as a thrown Symbol

Initial Comment:
Without my patch, the following spec fails:

#############################################################
describe ThrowSymbol, "(constructed with a Symbol)" do
  
  before(:each) { @matcher = ThrowSymbol.new(:sym) }
  
  it "should only match NameErrors raised by uncaught throws" do
    @matcher.matches?(lambda{ sym }).should be_false
  end
  
end
#############################################################

Though nothing is throw()n here, it still finds a thrown symbol by taking the NameError raised from the sym method that didn't exist and calling name.to_sym on it.

The problem existed in the matches?() method of ThrowSymbol. Since an uncaught throw() returns a NameError, normal name errors were being caught as well as a thrown symbol. In the example above, "sym" gets raised as a NameError (like a throw() does) assigned to variable "e" and e.name.to_sym evaluates to :sym. Since this NameError isn't a thrown Symbol, it should not match a *normal* NameError.

Attached is my patch for this issue.

Thanks,

Jay Phillips



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

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

From dchelimsky at gmail.com  Wed Aug 22 07:26:30 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 06:26:30 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
	<46CB68D6.4050305@tastapod.com>
	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
Message-ID: <57c63afe0708220426o1a3e9a41m6dafdd9eb9d172ed@mail.gmail.com>

On 8/22/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 8/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > On 8/22/07, Jim Deville <james.deville at gmail.com> wrote:
> > > > > >>> ExampleLifeCycleManager???) and these things are all related.
> > > > > >>>
> > > > > >> I'm suspicious of anything named Manager :)
> > > > > >>
> > > > > > Seconded. Or Helper or Service or Util while we're at it :)
> > > > >
> > > > > Service rings with me, perhaps some combination of it could work.
> > > > >
> > > >
> > > > I think Dan meant Manager,Helper,Service,Util are all suspicious
> > > > names, and I agree.
> > > >
> > > > I like ExampleWorld and Example.
> >
> > Well - which is which - in the story runner, the world is where the
> > stuff happens - which would equate to the current example_space. So
> > Example would remain Example, and ExampleSpace would become
> > ExampleWorld. Is that what you are thinking Brian?
> I was actuallly thinking the opposite.
>
> Comparing this with Test::Unit, a Behaviour is equivalent to a TestCase class.
> ExampleSpace + Example is equivalent to a TestCase instance.
>
> Example holds the run and error adding methods, while ExampleSpace is
> unpolluted by the run and other methods (not that this is really an
> issue with Test::Unit).
>
> Here the the responsibilities for each part:
> * The life of the example call chain (run, before and after callbacks,
> setup and teardown mocks, etc.)
> * The actual execution of the code within the example block, along
> with the other methods defined in the Describe block
>
> Developers who wish to extend rspec will probably be subclassing
> Behaviour and the current ExampleSpace. I feel a little strange having
> other developers subclassing a class named ExampleSpace. Maybe
> ExampleWorld is better, but Example seems like the most inviting name
> to extend.

I agree that what is now ExampleSpace should be Example, but I don't
think that ExampleWorld is the right name for what is now Example. The
World that Dan brought up is more aligned with what is current
ExampleSpace - the place where stuff happens.

So I re-submit earlier suggestions for consideration:

ExampleWrapper
ExampleProxy
ExampleDriver
ExampleConfig
ExampleContainer
ExampleLifeCycle

Other ideas welcome - but they have to mean "the thing that manages
the life cycle of an example" and not "the place where stuff happens."



>
> >
> > >
> > > Yes. I like it.
> > >
> > > >
> > > > Aslak
> > > >
> > > > > >
> > > > > >> How about ExampleLifeCycle?
> > > > > >>
> > > > > > Not so much.
> > > > > >
> > > > > > Cheers,
> > > > > > Dan
> > > > > > _______________________________________________
> > > > > > 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  Wed Aug 22 07:30:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 07:30:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13274 ] ThrowSymbol recognized a
	NameError triggered by Kernel#method_missing as a thrown Symbol
Message-ID: <20070822113019.D5AE65240B01@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Phillips (jicksta)
Assigned to: Nobody (None)
Summary: ThrowSymbol recognized a NameError triggered by Kernel#method_missing as a thrown Symbol

Initial Comment:
Without my patch, the following spec fails:

#############################################################
describe ThrowSymbol, "(constructed with a Symbol)" do
  
  before(:each) { @matcher = ThrowSymbol.new(:sym) }
  
  it "should only match NameErrors raised by uncaught throws" do
    @matcher.matches?(lambda{ sym }).should be_false
  end
  
end
#############################################################

Though nothing is throw()n here, it still finds a thrown symbol by taking the NameError raised from the sym method that didn't exist and calling name.to_sym on it.

The problem existed in the matches?() method of ThrowSymbol. Since an uncaught throw() returns a NameError, normal name errors were being caught as well as a thrown symbol. In the example above, "sym" gets raised as a NameError (like a throw() does) assigned to variable "e" and e.name.to_sym evaluates to :sym. Since this NameError isn't a thrown Symbol, it should not match a *normal* NameError.

Attached is my patch for this issue.

Thanks,

Jay Phillips



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 11:30

Message:
Anybody remember those commercials for McDonalds or Burger King in the 80s w/ this elderly woman opening up a sandwich and asking "where's the beef?"?

Where's the patch?

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

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

From noreply at rubyforge.org  Wed Aug 22 07:32:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 07:32:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13274 ] ThrowSymbol recognized a
	NameError triggered by Kernel#method_missing as a thrown Symbol
Message-ID: <20070822113219.441375240B01@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Phillips (jicksta)
Assigned to: Nobody (None)
Summary: ThrowSymbol recognized a NameError triggered by Kernel#method_missing as a thrown Symbol

Initial Comment:
Without my patch, the following spec fails:

#############################################################
describe ThrowSymbol, "(constructed with a Symbol)" do
  
  before(:each) { @matcher = ThrowSymbol.new(:sym) }
  
  it "should only match NameErrors raised by uncaught throws" do
    @matcher.matches?(lambda{ sym }).should be_false
  end
  
end
#############################################################

Though nothing is throw()n here, it still finds a thrown symbol by taking the NameError raised from the sym method that didn't exist and calling name.to_sym on it.

The problem existed in the matches?() method of ThrowSymbol. Since an uncaught throw() returns a NameError, normal name errors were being caught as well as a thrown symbol. In the example above, "sym" gets raised as a NameError (like a throw() does) assigned to variable "e" and e.name.to_sym evaluates to :sym. Since this NameError isn't a thrown Symbol, it should not match a *normal* NameError.

Attached is my patch for this issue.

Thanks,

Jay Phillips



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 06:30

Message:
Anybody remember those commercials for McDonalds or Burger King in the 80s w/ this elderly woman opening up a sandwich and asking "where's the beef?"?

Where's the patch?

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

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

From noreply at rubyforge.org  Wed Aug 22 07:32:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 07:32:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13274 ] ThrowSymbol recognized a
	NameError triggered by Kernel#method_missing as a thrown Symbol
Message-ID: <20070822113254.F2A5F5240B64@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Phillips (jicksta)
Assigned to: Nobody (None)
Summary: ThrowSymbol recognized a NameError triggered by Kernel#method_missing as a thrown Symbol

Initial Comment:
Without my patch, the following spec fails:

#############################################################
describe ThrowSymbol, "(constructed with a Symbol)" do
  
  before(:each) { @matcher = ThrowSymbol.new(:sym) }
  
  it "should only match NameErrors raised by uncaught throws" do
    @matcher.matches?(lambda{ sym }).should be_false
  end
  
end
#############################################################

Though nothing is throw()n here, it still finds a thrown symbol by taking the NameError raised from the sym method that didn't exist and calling name.to_sym on it.

The problem existed in the matches?() method of ThrowSymbol. Since an uncaught throw() returns a NameError, normal name errors were being caught as well as a thrown symbol. In the example above, "sym" gets raised as a NameError (like a throw() does) assigned to variable "e" and e.name.to_sym evaluates to :sym. Since this NameError isn't a thrown Symbol, it should not match a *normal* NameError.

Attached is my patch for this issue.

Thanks,

Jay Phillips



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 06:30

Message:
Anybody remember those commercials for McDonalds or Burger King in the 80s w/ this elderly woman opening up a sandwich and asking "where's the beef?"?

Where's the patch?

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

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

From noreply at rubyforge.org  Wed Aug 22 07:33:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 07:33:17 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13274 ] ThrowSymbol recognized a
	NameError triggered by Kernel#method_missing as a thrown Symbol
Message-ID: <20070822113317.5AEB55240B64@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Phillips (jicksta)
Assigned to: Nobody (None)
Summary: ThrowSymbol recognized a NameError triggered by Kernel#method_missing as a thrown Symbol

Initial Comment:
Without my patch, the following spec fails:

#############################################################
describe ThrowSymbol, "(constructed with a Symbol)" do
  
  before(:each) { @matcher = ThrowSymbol.new(:sym) }
  
  it "should only match NameErrors raised by uncaught throws" do
    @matcher.matches?(lambda{ sym }).should be_false
  end
  
end
#############################################################

Though nothing is throw()n here, it still finds a thrown symbol by taking the NameError raised from the sym method that didn't exist and calling name.to_sym on it.

The problem existed in the matches?() method of ThrowSymbol. Since an uncaught throw() returns a NameError, normal name errors were being caught as well as a thrown symbol. In the example above, "sym" gets raised as a NameError (like a throw() does) assigned to variable "e" and e.name.to_sym evaluates to :sym. Since this NameError isn't a thrown Symbol, it should not match a *normal* NameError.

Attached is my patch for this issue.

Thanks,

Jay Phillips



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

>Comment By: Jay Phillips (jicksta)
Date: 2007-08-22 06:33

Message:
Pesky checkbox!

Patch uploaded. Sorry.  :)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 06:30

Message:
Anybody remember those commercials for McDonalds or Burger King in the 80s w/ this elderly woman opening up a sandwich and asking "where's the beef?"?

Where's the patch?

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

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

From noreply at rubyforge.org  Wed Aug 22 08:35:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 08:35:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822123559.142AB5240B85@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 12:35

Message:
I'm on to something, but haven't gotten there yet.

Modifying the example in the pastie, the following passes:

    @book.should_receive(:can_store?) do |clip|
      @clip.object_id.should == clip.object_id
    end

But the following fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should == clip
    end

And this fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should equal(clip)
    end

I added specs for mocks and mock_models:

@mock.should == @mock
@mock.should equal(@mock)

@mock_model.should == @mock_model
@mock_model.should equal(@mock_model)

They all pass.

Here's my theory:

model.book.clip is not actually the clip object, but a Rails Association Proxy and it is not responding as you would expect to == or equal?.

Anybody else paying attention to this thread think that's a reasonable theory?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 07:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 05:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 15:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From lists-rspec at shopwatch.org  Wed Aug 22 07:57:28 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Wed, 22 Aug 2007 07:57:28 -0400
Subject: [rspec-devel] [Proposed Refactoring] - Example
 ->	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <57c63afe0708220426o1a3e9a41m6dafdd9eb9d172ed@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>	<46CB68D6.4050305@tastapod.com>	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
	<57c63afe0708220426o1a3e9a41m6dafdd9eb9d172ed@mail.gmail.com>
Message-ID: <46CC24A8.4020603@jay.fm>

On 8/22/2007 7:26 AM, David Chelimsky wrote:
> On 8/22/07, Brian Takita <brian.takita at gmail.com> wrote:
>> On 8/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
>>>> On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>>>>> On 8/22/07, Jim Deville <james.deville at gmail.com> wrote:
>>>>>>>>> ExampleLifeCycleManager???) and these things are all related.
>>>>>>>>>
>>>>>>>> I'm suspicious of anything named Manager :)
>>>>>>>>
>>>>>>> Seconded. Or Helper or Service or Util while we're at it :)
>>>>>> Service rings with me, perhaps some combination of it could work.
>>>>>>
>>>>> I think Dan meant Manager,Helper,Service,Util are all suspicious
>>>>> names, and I agree.
>>>>>
>>>>> I like ExampleWorld and Example.
>>> Well - which is which - in the story runner, the world is where the
>>> stuff happens - which would equate to the current example_space. So
>>> Example would remain Example, and ExampleSpace would become
>>> ExampleWorld. Is that what you are thinking Brian?
>> I was actuallly thinking the opposite.
>>
>> Comparing this with Test::Unit, a Behaviour is equivalent to a TestCase class.
>> ExampleSpace + Example is equivalent to a TestCase instance.
>>
>> Example holds the run and error adding methods, while ExampleSpace is
>> unpolluted by the run and other methods (not that this is really an
>> issue with Test::Unit).
>>
>> Here the the responsibilities for each part:
>> * The life of the example call chain (run, before and after callbacks,
>> setup and teardown mocks, etc.)
>> * The actual execution of the code within the example block, along
>> with the other methods defined in the Describe block
>>
>> Developers who wish to extend rspec will probably be subclassing
>> Behaviour and the current ExampleSpace. I feel a little strange having
>> other developers subclassing a class named ExampleSpace. Maybe
>> ExampleWorld is better, but Example seems like the most inviting name
>> to extend.
> 
> I agree that what is now ExampleSpace should be Example, but I don't
> think that ExampleWorld is the right name for what is now Example. The
> World that Dan brought up is more aligned with what is current
> ExampleSpace - the place where stuff happens.
> 
> So I re-submit earlier suggestions for consideration:
> 
> ExampleWrapper
> ExampleProxy
> ExampleDriver
> ExampleConfig
> ExampleContainer
> ExampleLifeCycle
> 
> Other ideas welcome - but they have to mean "the thing that manages
> the life cycle of an example" and not "the place where stuff happens."

ExampleNursery? :)

Jay


From noreply at rubyforge.org  Wed Aug 22 09:49:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 09:49:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13278 ] should_receive fails too fast?
Message-ID: <20070822134909.CA6B35240B62@rubyforge.org>

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

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Hamann (michitux)
Assigned to: Nobody (None)
Summary: should_receive fails too fast?

Initial Comment:
I don't know if this is a bug. 

I discovered the problem when I wanted to verify that a specific link in a view-template is created and so I mocked link_to with these arguments. But link_to is already called before the call I want to match with other arguments. And now the expectation fails although the correct arguments are passed to link_to, too. To reproduce this behavior I patched the specs of rspec, the diff is here: http://pastie.caboo.se/90016. A workaround is to stub the method before setting up the mock, then it works.

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

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

From noreply at rubyforge.org  Wed Aug 22 10:04:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 10:04:08 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13278 ] should_receive fails too fast?
Message-ID: <20070822140408.9B7C55240B87@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Michael Hamann (michitux)
Assigned to: Nobody (None)
Summary: should_receive fails too fast?

Initial Comment:
I don't know if this is a bug. 

I discovered the problem when I wanted to verify that a specific link in a view-template is created and so I mocked link_to with these arguments. But link_to is already called before the call I want to match with other arguments. And now the expectation fails although the correct arguments are passed to link_to, too. To reproduce this behavior I patched the specs of rspec, the diff is here: http://pastie.caboo.se/90016. A workaround is to stub the method before setting up the mock, then it works.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 14:04

Message:
This is just the way mocks work. When you mock a method with specific arguments, it is only expecting that one call with those arguments. This is true of mocha, flexmock, jmock, easymock, etc.

To solve your problem you want to stub the method first and then mock it:

template.stub!(:link_to).and_return(whatever)
template.should_receive(:link_to).with(specific args).and_return(whatever)

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

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

From noreply at rubyforge.org  Wed Aug 22 10:05:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 10:05:44 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822140544.43AB45240B87@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 14:05

Message:
OK - Here's the deal:

clip

@mock_clip == association_proxy_clip => false
association_proxy_clip == @mock_clip => true

RSpec happens to be doing the comparison the first way:

expected == actual

I'm not sure of the best way to handle this. We could have rspec try == in both directions:

actual == expected || expected == actual

But that seems slimy to me. Anybody have an opinion about that?

Incidentally, mocha also compares [expected == actual], so the same problem would occur w/ mocha - and I'd bet the same is true of flexmock. In the end, the source of this problem is AssociationProxy, which seems to violate the Principle of Least Surprise in most sinister ways.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 12:35

Message:
I'm on to something, but haven't gotten there yet.

Modifying the example in the pastie, the following passes:

    @book.should_receive(:can_store?) do |clip|
      @clip.object_id.should == clip.object_id
    end

But the following fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should == clip
    end

And this fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should equal(clip)
    end

I added specs for mocks and mock_models:

@mock.should == @mock
@mock.should equal(@mock)

@mock_model.should == @mock_model
@mock_model.should equal(@mock_model)

They all pass.

Here's my theory:

model.book.clip is not actually the clip object, but a Rails Association Proxy and it is not responding as you would expect to == or equal?.

Anybody else paying attention to this thread think that's a reasonable theory?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 07:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 05:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 15:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From noreply at rubyforge.org  Wed Aug 22 10:08:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 10:08:51 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822140851.547155240B8A@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 00:08

Message:
I'm glad your on the case David.  I wouldn't have found that!

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-23 00:05

Message:
OK - Here's the deal:

clip

@mock_clip == association_proxy_clip => false
association_proxy_clip == @mock_clip => true

RSpec happens to be doing the comparison the first way:

expected == actual

I'm not sure of the best way to handle this. We could have rspec try == in both directions:

actual == expected || expected == actual

But that seems slimy to me. Anybody have an opinion about that?

Incidentally, mocha also compares [expected == actual], so the same problem would occur w/ mocha - and I'd bet the same is true of flexmock. In the end, the source of this problem is AssociationProxy, which seems to violate the Principle of Least Surprise in most sinister ways.


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

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

Message:
I'm on to something, but haven't gotten there yet.

Modifying the example in the pastie, the following passes:

    @book.should_receive(:can_store?) do |clip|
      @clip.object_id.should == clip.object_id
    end

But the following fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should == clip
    end

And this fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should equal(clip)
    end

I added specs for mocks and mock_models:

@mock.should == @mock
@mock.should equal(@mock)

@mock_model.should == @mock_model
@mock_model.should equal(@mock_model)

They all pass.

Here's my theory:

model.book.clip is not actually the clip object, but a Rails Association Proxy and it is not responding as you would expect to == or equal?.

Anybody else paying attention to this thread think that's a reasonable theory?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 17:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 15:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

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

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From noreply at rubyforge.org  Wed Aug 22 10:11:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 10:11:33 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822141133.2C7895240B8A@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 14:11

Message:
Thanks for the props - but do you have an opinion about modifying the comparison?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 14:08

Message:
I'm glad your on the case David.  I wouldn't have found that!

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 14:05

Message:
OK - Here's the deal:

clip

@mock_clip == association_proxy_clip => false
association_proxy_clip == @mock_clip => true

RSpec happens to be doing the comparison the first way:

expected == actual

I'm not sure of the best way to handle this. We could have rspec try == in both directions:

actual == expected || expected == actual

But that seems slimy to me. Anybody have an opinion about that?

Incidentally, mocha also compares [expected == actual], so the same problem would occur w/ mocha - and I'd bet the same is true of flexmock. In the end, the source of this problem is AssociationProxy, which seems to violate the Principle of Least Surprise in most sinister ways.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 12:35

Message:
I'm on to something, but haven't gotten there yet.

Modifying the example in the pastie, the following passes:

    @book.should_receive(:can_store?) do |clip|
      @clip.object_id.should == clip.object_id
    end

But the following fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should == clip
    end

And this fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should equal(clip)
    end

I added specs for mocks and mock_models:

@mock.should == @mock
@mock.should equal(@mock)

@mock_model.should == @mock_model
@mock_model.should equal(@mock_model)

They all pass.

Here's my theory:

model.book.clip is not actually the clip object, but a Rails Association Proxy and it is not responding as you would expect to == or equal?.

Anybody else paying attention to this thread think that's a reasonable theory?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 07:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 05:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 15:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From noreply at rubyforge.org  Wed Aug 22 10:18:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 10:18:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822141827.193665240B9D@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 00:18

Message:
Since this directly involves the rails magic that is
association_proxy, I don't see how it can be gotten around
without checking both ways.

That is unless you wanted to check to make sure it was an
association_proxy first then swap the comparison.  But that
seems the worse course.

I would grudgingly have to say you need to check both ways.
 As weird as it seems to me, it seems it is necessary in
this situation.

My 0.02

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-23 00:11

Message:
Thanks for the props - but do you have an opinion about modifying the comparison?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 00:08

Message:
I'm glad your on the case David.  I wouldn't have found that!

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-23 00:05

Message:
OK - Here's the deal:

clip

@mock_clip == association_proxy_clip => false
association_proxy_clip == @mock_clip => true

RSpec happens to be doing the comparison the first way:

expected == actual

I'm not sure of the best way to handle this. We could have rspec try == in both directions:

actual == expected || expected == actual

But that seems slimy to me. Anybody have an opinion about that?

Incidentally, mocha also compares [expected == actual], so the same problem would occur w/ mocha - and I'd bet the same is true of flexmock. In the end, the source of this problem is AssociationProxy, which seems to violate the Principle of Least Surprise in most sinister ways.


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

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

Message:
I'm on to something, but haven't gotten there yet.

Modifying the example in the pastie, the following passes:

    @book.should_receive(:can_store?) do |clip|
      @clip.object_id.should == clip.object_id
    end

But the following fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should == clip
    end

And this fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should equal(clip)
    end

I added specs for mocks and mock_models:

@mock.should == @mock
@mock.should equal(@mock)

@mock_model.should == @mock_model
@mock_model.should equal(@mock_model)

They all pass.

Here's my theory:

model.book.clip is not actually the clip object, but a Rails Association Proxy and it is not responding as you would expect to == or equal?.

Anybody else paying attention to this thread think that's a reasonable theory?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 17:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 15:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

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

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From dchelimsky at gmail.com  Wed Aug 22 10:55:25 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 09:55:25 -0500
Subject: [rspec-devel] mock framework
Message-ID: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>

I'd like to ditch rspec's mock framework and let ppl use mocha or
flexmock or RR (or others). RSpec's mocking framework doesn't really
offer anything above those frameworks, and it's therefore an
unnecessary burden to maintain.

Here's my thinking:

We break spec/mocks out into a separate project and release the one
and only release when we release rspec 1.1.

If you want to continue to use rspec mocks you can do so but you'll
have to declare it in spec_helper (or somewhere global), but
spec/mocks will be deprecated, and people would be encouraged to start
using other frameworks.

This isn't a slam dunk, btw - there are some dependencies on rspec's
mock framework in the rails plugin that would have to be addressed
with either one-off solutions or adapters for the other frameworks.
One thing I do NOT want to do is have RSpec prefer one framework over
another.

Thoughts?

From aslak.hellesoy at gmail.com  Wed Aug 22 11:09:00 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 22 Aug 2007 17:09:00 +0200
Subject: [rspec-devel] mock framework
In-Reply-To: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
Message-ID: <8d961d900708220809h1767a314wbfdcb73f2965c64b@mail.gmail.com>

On 8/22/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> I'd like to ditch rspec's mock framework and let ppl use mocha or
> flexmock or RR (or others). RSpec's mocking framework doesn't really
> offer anything above those frameworks, and it's therefore an
> unnecessary burden to maintain.
>
> Here's my thinking:
>
> We break spec/mocks out into a separate project and release the one
> and only release when we release rspec 1.1.
>
> If you want to continue to use rspec mocks you can do so but you'll
> have to declare it in spec_helper (or somewhere global), but
> spec/mocks will be deprecated, and people would be encouraged to start
> using other frameworks.
>
> This isn't a slam dunk, btw - there are some dependencies on rspec's
> mock framework in the rails plugin that would have to be addressed
> with either one-off solutions or adapters for the other frameworks.
> One thing I do NOT want to do is have RSpec prefer one framework over
> another.
>
> Thoughts?

You mean throw away code that we all worked hard to make as good as possible?
Sounds good to me. +1 Ja.

If we break it out to a separate project, can I recommend we move it
to a separate RubyForge project at the same time? Yurii has registered
rspec-ext (RSpec Extras), which is  currently empty. I've been
thinking about moving Spec::Ui and Spec::Distributed there. All these
sub projects could share the same svn, but with their own
trunk/tags/branches structure. This would allow for separate release
cycles. We could put Spec::Mock here.

Aslak

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

From dchelimsky at gmail.com  Wed Aug 22 11:11:23 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 10:11:23 -0500
Subject: [rspec-devel] mock framework
In-Reply-To: <8d961d900708220809h1767a314wbfdcb73f2965c64b@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<8d961d900708220809h1767a314wbfdcb73f2965c64b@mail.gmail.com>
Message-ID: <57c63afe0708220811ga0c4962lf5738a1fe1e6aa42@mail.gmail.com>

On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/22/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > I'd like to ditch rspec's mock framework and let ppl use mocha or
> > flexmock or RR (or others). RSpec's mocking framework doesn't really
> > offer anything above those frameworks, and it's therefore an
> > unnecessary burden to maintain.
> >
> > Here's my thinking:
> >
> > We break spec/mocks out into a separate project and release the one
> > and only release when we release rspec 1.1.
> >
> > If you want to continue to use rspec mocks you can do so but you'll
> > have to declare it in spec_helper (or somewhere global), but
> > spec/mocks will be deprecated, and people would be encouraged to start
> > using other frameworks.
> >
> > This isn't a slam dunk, btw - there are some dependencies on rspec's
> > mock framework in the rails plugin that would have to be addressed
> > with either one-off solutions or adapters for the other frameworks.
> > One thing I do NOT want to do is have RSpec prefer one framework over
> > another.
> >
> > Thoughts?
>
> You mean throw away code that we all worked hard to make as good as possible?
> Sounds good to me. +1 Ja.
>
> If we break it out to a separate project, can I recommend we move it
> to a separate RubyForge project at the same time? Yurii has registered
> rspec-ext (RSpec Extras), which is  currently empty. I've been
> thinking about moving Spec::Ui and Spec::Distributed there. All these
> sub projects could share the same svn, but with their own
> trunk/tags/branches structure. This would allow for separate release
> cycles. We could put Spec::Mock here.

As long as Yurii is on board that's fine.

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

From noreply at rubyforge.org  Wed Aug 22 11:11:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 11:11:49 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13274 ] ThrowSymbol recognized a
	NameError triggered by Kernel#method_missing as a thrown Symbol
Message-ID: <20070822151149.4A895A970006@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Phillips (jicksta)
Assigned to: Nobody (None)
Summary: ThrowSymbol recognized a NameError triggered by Kernel#method_missing as a thrown Symbol

Initial Comment:
Without my patch, the following spec fails:

#############################################################
describe ThrowSymbol, "(constructed with a Symbol)" do
  
  before(:each) { @matcher = ThrowSymbol.new(:sym) }
  
  it "should only match NameErrors raised by uncaught throws" do
    @matcher.matches?(lambda{ sym }).should be_false
  end
  
end
#############################################################

Though nothing is throw()n here, it still finds a thrown symbol by taking the NameError raised from the sym method that didn't exist and calling name.to_sym on it.

The problem existed in the matches?() method of ThrowSymbol. Since an uncaught throw() returns a NameError, normal name errors were being caught as well as a thrown symbol. In the example above, "sym" gets raised as a NameError (like a throw() does) assigned to variable "e" and e.name.to_sym evaluates to :sym. Since this NameError isn't a thrown Symbol, it should not match a *normal* NameError.

Attached is my patch for this issue.

Thanks,

Jay Phillips



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

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

Message:
It was Wendy's

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

Comment By: Jay Phillips (jicksta)
Date: 2007-08-22 07:33

Message:
Pesky checkbox!

Patch uploaded. Sorry.  :)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 07:30

Message:
Anybody remember those commercials for McDonalds or Burger King in the 80s w/ this elderly woman opening up a sandwich and asking "where's the beef?"?

Where's the patch?

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

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

From aslak.hellesoy at gmail.com  Wed Aug 22 11:18:04 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 22 Aug 2007 17:18:04 +0200
Subject: [rspec-devel] mock framework
In-Reply-To: <57c63afe0708220811ga0c4962lf5738a1fe1e6aa42@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<8d961d900708220809h1767a314wbfdcb73f2965c64b@mail.gmail.com>
	<57c63afe0708220811ga0c4962lf5738a1fe1e6aa42@mail.gmail.com>
Message-ID: <8d961d900708220818l3c855c13y1e55ac4757db3048@mail.gmail.com>

On 8/22/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 8/22/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > I'd like to ditch rspec's mock framework and let ppl use mocha or
> > > flexmock or RR (or others). RSpec's mocking framework doesn't really
> > > offer anything above those frameworks, and it's therefore an
> > > unnecessary burden to maintain.
> > >
> > > Here's my thinking:
> > >
> > > We break spec/mocks out into a separate project and release the one
> > > and only release when we release rspec 1.1.
> > >
> > > If you want to continue to use rspec mocks you can do so but you'll
> > > have to declare it in spec_helper (or somewhere global), but
> > > spec/mocks will be deprecated, and people would be encouraged to start
> > > using other frameworks.
> > >
> > > This isn't a slam dunk, btw - there are some dependencies on rspec's
> > > mock framework in the rails plugin that would have to be addressed
> > > with either one-off solutions or adapters for the other frameworks.
> > > One thing I do NOT want to do is have RSpec prefer one framework over
> > > another.
> > >
> > > Thoughts?
> >
> > You mean throw away code that we all worked hard to make as good as possible?
> > Sounds good to me. +1 Ja.
> >
> > If we break it out to a separate project, can I recommend we move it
> > to a separate RubyForge project at the same time? Yurii has registered
> > rspec-ext (RSpec Extras), which is  currently empty. I've been
> > thinking about moving Spec::Ui and Spec::Distributed there. All these
> > sub projects could share the same svn, but with their own
> > trunk/tags/branches structure. This would allow for separate release
> > cycles. We could put Spec::Mock here.
>
> As long as Yurii is on board that's fine.
>

He is :-)

Aslak

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

From lists-rspec at shopwatch.org  Wed Aug 22 11:20:36 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Wed, 22 Aug 2007 11:20:36 -0400
Subject: [rspec-devel] mock framework
In-Reply-To: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
Message-ID: <46CC5444.3010102@jay.fm>

David Chelimsky wrote:
> I'd like to ditch rspec's mock framework and let ppl use mocha or
> flexmock or RR (or others). RSpec's mocking framework doesn't really
> offer anything above those frameworks, and it's therefore an
> unnecessary burden to maintain.
+1!  I currently use rspec's mocks because they're the default, but I'd 
have no problems switching frameworks.  If there's no good reason to 
have our own, let's not have our own.

Jay



From james.deville at gmail.com  Wed Aug 22 11:26:47 2007
From: james.deville at gmail.com (Jim Deville)
Date: Wed, 22 Aug 2007 08:26:47 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses
In-Reply-To: <57c63afe0708212159x5f40d953o4a8ca38f78391d74@mail.gmail.com>
References: <ad4f9af90708211720g34f033eci3cb2b93dc7acf167@mail.gmail.com>
	<C0F22117-07D3-435B-AE40-E499CA3F4EE8@gmail.com>
	<57c63afe0708212159x5f40d953o4a8ca38f78391d74@mail.gmail.com>
Message-ID: <6D68C18B-52CE-4C7C-9D2C-FC90C83904DC@gmail.com>


On Aug 21, 2007, at 9:59 PM, David Chelimsky wrote:

> On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
>>
>>>
>>>>>> It would be kinda nice if there were a good plugin architecture
>>>>>> to either
>>>>>> Test::Unit or Rspec.
>>>
>>> That's a really good idea---my work colleagues and I could make our
>>> current hacks a little more future-proof, and the folks who (for  
>>> some
>>> reason) like Test::Unit can find a way to make the two play nicely
>>> together.
>>>
>>
>> I just wish I knew more about both projects internals to do something
>> about it. Still might be worth a try, though.
>>
>>> I guess I just don't understand the recent rash of "we're abandoning
>>> RSpec" or "we're coding the next great RSpec alternative" blog  
>>> posts.
>>> I suppose software inevitably runs into things it just can't do well
>>> as its user base increases.
>>>
>>
>> For me, I am a big supporter of RSpec and BDD, but I have trouble
>> explaining why I like it so much more than Test::Unit to other
>> people. I also have a co-worker who doubts the benefits of using
>> mocks to isolate the tests.
>
> Mocking has been around a lot longer than BDD and there is a wealth of
> literature on why mocking is good and why, to those who think so, it
> is bad.
>

I've found some of that literature, and it seems to keep him at bay.  
The problem is, every time we break a feature, he blames it on the  
mocks.

  The real problem seems to be bad mocks, bad tests, or incomplete  
tests. I tend towards the later.

>> He mainly wonders why we are duplicating
>> our effort by doing Unit tests and Integration tests.
>
> The really difficult thing to get across about mocking, and about TDD
> in general, is that it is a process, not an end result. Duplication
> between Programmer Tests (what you're calling Unit Tests) and Customer
> Tests (what you're calling Integration Tests) is temporal - there are
> moments in time when there is duplication and then, because we're
> refactoring relentlessly, that duplication goes away. That's because
> when we're refactoring we're not changing the system requirements as
> expressed in the Customer Tests, but we are changing the granular
> requirements of individual objects, as expressed in the Programmer
> Tests.
>
> This all make sense?
>

I think so. I think his feeling is that since the Customer tests  
should break whenever the Programmer tests break, we should just use  
the Customer tests. I feel that there is valuable insight, due to the  
isolation of the tests, in the breakage's of the Programmer tests. I  
think they are usually more thorough.

I think I'll try to point him to Fowler's article and the BDD/TDD  
websites next time. Maybe they will be able to clarify the point of  
view you're making better than I can.

Thanks,
Jim

>
>> I am in the odd
>> position of being one of the most knowledgeble Ruby/RSpec coders at
>> my job, but I am the least experienced in OO Design, TDD/BDD and
>> Agile processes. I wonder if a little more push on the BDD ideas
>> would help build faith in the RSpec framework and techniques.
>>
>>> But for us, over a year after we started looking at this thing, the
>>> bloom is still firmly on the rose.
>>>
>>> --Ian
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>> Jim
>> _______________________________________________
>> 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 james.deville at gmail.com  Wed Aug 22 11:28:51 2007
From: james.deville at gmail.com (Jim Deville)
Date: Wed, 22 Aug 2007 08:28:51 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <1d7ddd110708212249v6e68e50r21e1186dabeaa203@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<46CB2A0F.908@pobox.com>
	<1d7ddd110708212249v6e68e50r21e1186dabeaa203@mail.gmail.com>
Message-ID: <C7F092A1-A25B-4DC0-91E4-BDF0061A396F@gmail.com>


On Aug 21, 2007, at 10:49 PM, Brian Takita wrote:

> On 8/21/07, Steven R. Baker <srbaker at pobox.com> wrote:
>> Brian Takita wrote:
>>> This is a way to utilize Test::Unit in rspec.
>>>
>>> There are a number of BDD frameworks that utilize Test::Unit to  
>>> create
>>> a simple implementation.
>>>
>>> This could also be a first step to using Test::Unit's runner.
>>>
>> Agreed.  The recent change of hands of Test::Unit to Ryan Davis  
>> poses a
>> great opportunity to do this.  I want to see RSpec and Test::Unit
>> tool-compatible.  ZenTest, autotest, Test::Rails, heckle, and  
>> others all
>> have their own special hooks to work with both, and it's time for  
>> that
>> to stop.
>>
>> I have some thoughts on the right way to do this, but we're off to  
>> have
>> a baby in less than 6 hours, so I don't have time for immediate
> Wow, congratulations, Steven!! :)

Ditto on the congrats. Children are just plain awesome.
>> discussion.  This is, however, something I'm *very* interested in
>> working on in the next week or three.
>>
>> I'm going to collect my thoughts on it, and do some research.   
>> When we
>> get back from the hospital, I'll explain what I have in mind.  If
>> anything.  And I'd like feedback.
>>

I'd love to pitch in however I can. I know a little of the RSpec  
internals, but pretty much nothing of the ZenTest, and Test::Unit  
internals. However, I'd love to learn.

>> -Steven
>>
>> _______________________________________________
>> 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 james.deville at gmail.com  Wed Aug 22 11:30:40 2007
From: james.deville at gmail.com (Jim Deville)
Date: Wed, 22 Aug 2007 08:30:40 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses
In-Reply-To: <C0F62976-99B1-4F6A-BCA0-C31ECCC4D7EE@railsnewbie.com>
References: <ad4f9af90708211720g34f033eci3cb2b93dc7acf167@mail.gmail.com>
	<C0F22117-07D3-435B-AE40-E499CA3F4EE8@gmail.com>
	<57c63afe0708212159x5f40d953o4a8ca38f78391d74@mail.gmail.com>
	<C0F62976-99B1-4F6A-BCA0-C31ECCC4D7EE@railsnewbie.com>
Message-ID: <2085E333-FA82-4BB8-A286-899DA3E51F0C@gmail.com>


On Aug 21, 2007, at 11:18 PM, Scott Taylor wrote:

>
> On Aug 22, 2007, at 12:59 AM, David Chelimsky wrote:
>
>> On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
>>>
>>>>
>>>>>>> It would be kinda nice if there were a good plugin architecture
>>>>>>> to either
>>>>>>> Test::Unit or Rspec.
>>>>
>>>> That's a really good idea---my work colleagues and I could make our
>>>> current hacks a little more future-proof, and the folks who (for
>>>> some
>>>> reason) like Test::Unit can find a way to make the two play nicely
>>>> together.
>>>>
>>>
>>> I just wish I knew more about both projects internals to do  
>>> something
>>> about it. Still might be worth a try, though.
>>>
>>>> I guess I just don't understand the recent rash of "we're  
>>>> abandoning
>>>> RSpec" or "we're coding the next great RSpec alternative" blog
>>>> posts.
>>>> I suppose software inevitably runs into things it just can't do  
>>>> well
>>>> as its user base increases.
>>>>
>>>
>>> For me, I am a big supporter of RSpec and BDD, but I have trouble
>>> explaining why I like it so much more than Test::Unit to other
>>> people. I also have a co-worker who doubts the benefits of using
>>> mocks to isolate the tests.
>>
>> Mocking has been around a lot longer than BDD and there is a  
>> wealth of
>> literature on why mocking is good and why, to those who think so, it
>> is bad.
>>
>>> He mainly wonders why we are duplicating
>>> our effort by doing Unit tests and Integration tests.
>
> One of the real advantages to having a "test" suite is refactoring.
> The test suite allows you to sleep at night.  And if your integration
> tests (alone) cover 100% of the code (go ahead - run rcov on your
> integration tests), then those granular tests are a waste.  Getting
> your integration tests to cover 100% of the code on any non-trivial
> project seems simple enough - until you realize that the complexity
> is incredibly enormous (I'm thinking of the simplicity of Zeno
> catching up with the tortoise).
>
> So if you are thinking it of testing - then sure, some of it is
> duplication, but most of it is testing the incredible complexity in
> your system which would be nearly impossible to express in a high
> level customer-story/integration test.  This is only further
> magnified by the lack of a type system in Ruby.
>
>
> More relevant speak, but I'm too tired to connect it:
>
> Having just acquired a new rails project, with something like 30
> models and 30 controllers, I've really just learned one of the
> biggest benefits of TDD - and that is documentation - not just for
> domain experts, but future coders who are going to work on YOUR
> complex system.  In a way, you could think of specs (or unit tests)
> as the best comments possible.  Normal Comments can lie (and will, as
> the system changes), but executable specs never can.  Integrations
> tests are good for testing the system - but they aren't going to give
> you examples of how the objects interact on a more granular level.
> But they too, can serve as high level comments (or specifications)
> for what the system can do (usually more for the non-hacker).
>
> If the only benefit your receiving from this process is a good night
> sleep (i.e. testing) - then it certainly is a waste to "duplicate"
> these things.  But the BDD side of things is to treat these "tests"
> as just an extra added benefit (like finding a twenty dollar bill
> under your couch).  Hey - look at that!  I've designed an
> understandable system (the real benefit of BDD/TDD) - and it just
> happens to be nearly bug free (the "testing" involved)!
>

That is a really good point. Thanks.
>>
>> The really difficult thing to get across about mocking, and about TDD
>> in general, is that it is a process, not an end result.
>
> +1, but:
>
> Certainly not a silver bullet : ) , although I do think it is a great
> process to have - and one I wouldn't live without - just like I'd
> refuse to work on a project where the other developers didn't use
> version control.
>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From james.deville at gmail.com  Wed Aug 22 11:40:40 2007
From: james.deville at gmail.com (Jim Deville)
Date: Wed, 22 Aug 2007 08:40:40 -0700
Subject: [rspec-devel] mock framework
In-Reply-To: <46CC5444.3010102@jay.fm>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CC5444.3010102@jay.fm>
Message-ID: <9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>


On Aug 22, 2007, at 8:20 AM, Jay Levitt wrote:

> David Chelimsky wrote:
>> I'd like to ditch rspec's mock framework and let ppl use mocha or
>> flexmock or RR (or others). RSpec's mocking framework doesn't really
>> offer anything above those frameworks, and it's therefore an
>> unnecessary burden to maintain.
> +1!  I currently use rspec's mocks because they're the default, but  
> I'd
> have no problems switching frameworks.  If there's no good reason to
> have our own, let's not have our own.
>
> Jay
>

+1, and +1 to moving things like Spec:UI and Spec:distributed. I  
would suggest keeping the literature on mocking, with minor  
modifications. The tight integration with mocking, and the pushing  
the ideas in the literature is what got my team and I to use it.  The  
current Rails literature really only shows mocks as a way to mock out  
an external project, but I think it is good to use it to isolate  
tests as well. I think that is proper BDD, too.

JIm

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


From yrashk at gmail.com  Wed Aug 22 11:52:24 2007
From: yrashk at gmail.com (Yurii Rashkovskii)
Date: Wed, 22 Aug 2007 18:52:24 +0300
Subject: [rspec-devel] mock framework
In-Reply-To: <57c63afe0708220811ga0c4962lf5738a1fe1e6aa42@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<8d961d900708220809h1767a314wbfdcb73f2965c64b@mail.gmail.com>
	<57c63afe0708220811ga0c4962lf5738a1fe1e6aa42@mail.gmail.com>
Message-ID: <858F9E4C-B7AE-4203-A8CB-DECF9D079D06@gmail.com>


On Aug 22, 2007, at 6:11 PM, David Chelimsky wrote:

> On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>> On 8/22/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>>> I'd like to ditch rspec's mock framework and let ppl use mocha or
>>> flexmock or RR (or others). RSpec's mocking framework doesn't really
>>> offer anything above those frameworks, and it's therefore an
>>> unnecessary burden to maintain.
>>>
>>> Here's my thinking:
>>>
>>> We break spec/mocks out into a separate project and release the one
>>> and only release when we release rspec 1.1.
>>>
>>> If you want to continue to use rspec mocks you can do so but you'll
>>> have to declare it in spec_helper (or somewhere global), but
>>> spec/mocks will be deprecated, and people would be encouraged to  
>>> start
>>> using other frameworks.
>>>
>>> This isn't a slam dunk, btw - there are some dependencies on rspec's
>>> mock framework in the rails plugin that would have to be addressed
>>> with either one-off solutions or adapters for the other frameworks.
>>> One thing I do NOT want to do is have RSpec prefer one framework  
>>> over
>>> another.
>>>
>>> Thoughts?
>>
>> You mean throw away code that we all worked hard to make as good  
>> as possible?
>> Sounds good to me. +1 Ja.
>>
>> If we break it out to a separate project, can I recommend we move it
>> to a separate RubyForge project at the same time? Yurii has  
>> registered
>> rspec-ext (RSpec Extras), which is  currently empty. I've been
>> thinking about moving Spec::Ui and Spec::Distributed there. All these
>> sub projects could share the same svn, but with their own
>> trunk/tags/branches structure. This would allow for separate release
>> cycles. We could put Spec::Mock here.
>
> As long as Yurii is on board that's fine.
>

Just say whom I should add to project admins.

Y.

From aslak.hellesoy at gmail.com  Wed Aug 22 11:59:39 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 22 Aug 2007 17:59:39 +0200
Subject: [rspec-devel] mock framework
In-Reply-To: <858F9E4C-B7AE-4203-A8CB-DECF9D079D06@gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<8d961d900708220809h1767a314wbfdcb73f2965c64b@mail.gmail.com>
	<57c63afe0708220811ga0c4962lf5738a1fe1e6aa42@mail.gmail.com>
	<858F9E4C-B7AE-4203-A8CB-DECF9D079D06@gmail.com>
Message-ID: <8d961d900708220859l14fd6ffen5b3e84a1fdd9e2ce@mail.gmail.com>

On 8/22/07, Yurii Rashkovskii <yrashk at gmail.com> wrote:
>
> On Aug 22, 2007, at 6:11 PM, David Chelimsky wrote:
>
> > On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> >> On 8/22/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >>> I'd like to ditch rspec's mock framework and let ppl use mocha or
> >>> flexmock or RR (or others). RSpec's mocking framework doesn't really
> >>> offer anything above those frameworks, and it's therefore an
> >>> unnecessary burden to maintain.
> >>>
> >>> Here's my thinking:
> >>>
> >>> We break spec/mocks out into a separate project and release the one
> >>> and only release when we release rspec 1.1.
> >>>
> >>> If you want to continue to use rspec mocks you can do so but you'll
> >>> have to declare it in spec_helper (or somewhere global), but
> >>> spec/mocks will be deprecated, and people would be encouraged to
> >>> start
> >>> using other frameworks.
> >>>
> >>> This isn't a slam dunk, btw - there are some dependencies on rspec's
> >>> mock framework in the rails plugin that would have to be addressed
> >>> with either one-off solutions or adapters for the other frameworks.
> >>> One thing I do NOT want to do is have RSpec prefer one framework
> >>> over
> >>> another.
> >>>
> >>> Thoughts?
> >>
> >> You mean throw away code that we all worked hard to make as good
> >> as possible?
> >> Sounds good to me. +1 Ja.
> >>
> >> If we break it out to a separate project, can I recommend we move it
> >> to a separate RubyForge project at the same time? Yurii has
> >> registered
> >> rspec-ext (RSpec Extras), which is  currently empty. I've been
> >> thinking about moving Spec::Ui and Spec::Distributed there. All these
> >> sub projects could share the same svn, but with their own
> >> trunk/tags/branches structure. This would allow for separate release
> >> cycles. We could put Spec::Mock here.
> >
> > As long as Yurii is on board that's fine.
> >
>
> Just say whom I should add to project admins.
>

Me please :-)

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

From badcarl at gmail.com  Wed Aug 22 13:51:59 2007
From: badcarl at gmail.com (Carl Porth)
Date: Wed, 22 Aug 2007 10:51:59 -0700
Subject: [rspec-devel] mock framework
In-Reply-To: <9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CC5444.3010102@jay.fm>
	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>
Message-ID: <84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>

+1, but what framework will rspec's generators use?  Should there be  
a translator? and what framework should the translator translate to?

Carl


On Aug 22, 2007, at 8:40 AM, Jim Deville wrote:

>
> On Aug 22, 2007, at 8:20 AM, Jay Levitt wrote:
>
>> David Chelimsky wrote:
>>> I'd like to ditch rspec's mock framework and let ppl use mocha or
>>> flexmock or RR (or others). RSpec's mocking framework doesn't really
>>> offer anything above those frameworks, and it's therefore an
>>> unnecessary burden to maintain.
>> +1!  I currently use rspec's mocks because they're the default, but
>> I'd
>> have no problems switching frameworks.  If there's no good reason to
>> have our own, let's not have our own.
>>
>> Jay
>>
>
> +1, and +1 to moving things like Spec:UI and Spec:distributed. I
> would suggest keeping the literature on mocking, with minor
> modifications. The tight integration with mocking, and the pushing
> the ideas in the literature is what got my team and I to use it.  The
> current Rails literature really only shows mocks as a way to mock out
> an external project, but I think it is good to use it to isolate
> tests as well. I think that is proper BDD, too.
>
> JIm
>
>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Wed Aug 22 14:00:09 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 22 Aug 2007 20:00:09 +0200
Subject: [rspec-devel] mock framework
In-Reply-To: <84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CC5444.3010102@jay.fm>
	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>
	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
Message-ID: <8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>

On 8/22/07, Carl Porth <badcarl at gmail.com> wrote:
> +1, but what framework will rspec's generators use?  Should there be
> a translator? and what framework should the translator translate to?
>

A translator from what to what? The RSpec mock framework will still
exist, it's just being factored out.

> Carl
>
>
> On Aug 22, 2007, at 8:40 AM, Jim Deville wrote:
>
> >
> > On Aug 22, 2007, at 8:20 AM, Jay Levitt wrote:
> >
> >> David Chelimsky wrote:
> >>> I'd like to ditch rspec's mock framework and let ppl use mocha or
> >>> flexmock or RR (or others). RSpec's mocking framework doesn't really
> >>> offer anything above those frameworks, and it's therefore an
> >>> unnecessary burden to maintain.
> >> +1!  I currently use rspec's mocks because they're the default, but
> >> I'd
> >> have no problems switching frameworks.  If there's no good reason to
> >> have our own, let's not have our own.
> >>
> >> Jay
> >>
> >
> > +1, and +1 to moving things like Spec:UI and Spec:distributed. I
> > would suggest keeping the literature on mocking, with minor
> > modifications. The tight integration with mocking, and the pushing
> > the ideas in the literature is what got my team and I to use it.  The
> > current Rails literature really only shows mocks as a way to mock out
> > an external project, but I think it is good to use it to isolate
> > tests as well. I think that is proper BDD, too.
> >
> > JIm
> >
> >>
> >> _______________________________________________
> >> 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 dan at tastapod.com  Wed Aug 22 13:40:29 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 22 Aug 2007 18:40:29 +0100
Subject: [rspec-devel] [Proposed Refactoring] - Current
 ExampleSpace	class subclasses Test::Unit::TestCase
In-Reply-To: <8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
Message-ID: <46CC750D.4020408@tastapod.com>

Hi Aslak.

aslak hellesoy wrote:
> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
>   
>> This is a way to utilize Test::Unit in rspec.
>>
>> There are a number of BDD frameworks that utilize Test::Unit to create
>> a simple implementation.
>>
>> This could also be a first step to using Test::Unit's runner.
>>     
A similar conversation happened in the early days of jbehave about 
whether to use junit's runner. We decided to go with our own runner 
(like rspec did) because we wanted it to do other stuff (mostly 
lifecycle callbacks).
> Using Test::Unit's runner might be compelling, but I don't know how
> easy it will be to make it behave like today's RSpec. We have a lot of
> extra command line options, different output and so on. I'm not sure
> what it takes to make it happen.
>   
I don't think it would be too difficult to write an adapter to run under 
test::unit. Right now, the describe method captures a block of code - 
the description (aka context) - and the it method captures another block 
of code - the example. You can replace these methods as follows:

- describe Sheep dynamically creates a class called SheepTest that 
extends a subclass of TestCase, then it executes its block to gather 
examples, by using a modified it() method as follows:
- it "should baa" dynamically creates a method in SheepTest called 
test_should_baa that looks like this:
cls.define_method :test_should_baa do
    begin
       alert_listeners(:starting)
       run_describe_block_with_it_method_disabled # so helper methods 
are defined
       run_the_actual_example_block
       alert_listeners(:succeeded)
    rescue
       alert_listeners(:failed)
       raise
    end
end

- Any before(:each) or after(:each) blocks get added to lists inside 
SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down methods.
- before :all and after :all would be more tricky, but they are 
discouraged anyway.

All this would allow test::unit to find the adapted test case in 
ObjectSpace with a bunch of test methods that it would run as normal. I 
wrote a hack like this a while back so that I could have test methods 
that started with "should_" instead of "test_" and it worked pretty 
well. (Then I deleted it all - d'oh!)

You can invoke the suite using testrb --options-to-test-unit -- 
--options-to-rspec-after-double-dash

Most of the rspec command line options are about attaching different 
listeners around the behaviour invocation, so this would still work 
using a template test method.

No doubt there are edge cases, but this would get us started.

> What would be the main benefit for users? And for us?
>   
Tools. Right now I can run a test::unit suite in eclipse using a 
short-cut and get a nice red/green tree of tests that I can drill into, 
right-click and re-run any test, etc. In contrast I can run my rspec 
suite as a "ruby application" and see rows of dots.

Any effort that goes into making test::unit easier to use (say in rake 
or buildr) is immediately useful to rspec.

Cheers,
Dan



From lists-rspec at shopwatch.org  Wed Aug 22 14:30:21 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Wed, 22 Aug 2007 14:30:21 -0400
Subject: [rspec-devel] mock framework
In-Reply-To: <8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>	<46CC5444.3010102@jay.fm>	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
Message-ID: <46CC80BD.6080705@jay.fm>

aslak hellesoy wrote:
> On 8/22/07, Carl Porth <badcarl at gmail.com> wrote:
>> +1, but what framework will rspec's generators use?  Should there be
>> a translator? and what framework should the translator translate to?
>>
> 
> A translator from what to what? The RSpec mock framework will still
> exist, it's just being factored out.

But then RSpec and its example specs will be using an unmaintained mock 
framework that we don't recommend anyone else use?

Jay


From badcarl at gmail.com  Wed Aug 22 14:34:16 2007
From: badcarl at gmail.com (Carl Porth)
Date: Wed, 22 Aug 2007 11:34:16 -0700
Subject: [rspec-devel] mock framework
In-Reply-To: <8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CC5444.3010102@jay.fm>
	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>
	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
Message-ID: <A0CDA627-2D97-4D55-857E-80B4561FF226@gmail.com>

Oh I see.  I thought since the current mocking framework wouldn't be  
maintained there would be a desire for developers to start using a  
new mocking framework.  And since David said that "people would be  
encouraged to start using other frameworks", I thought that it might  
be viable to have some sort of translator for the old mocking system  
to the once of your choice.

However, there may not be a need.

On another note: David expressed the desire to not prefer any one  
mocking framework over another.  However, rspec has to pick a mocking  
framework for default configuration, generators, and documentation/ 
examples.  Or does it?

Carl


On Aug 22, 2007, at 11:00 AM, aslak hellesoy wrote:

> On 8/22/07, Carl Porth <badcarl at gmail.com> wrote:
>> +1, but what framework will rspec's generators use?  Should there be
>> a translator? and what framework should the translator translate to?
>>
>
> A translator from what to what? The RSpec mock framework will still
> exist, it's just being factored out.
>
>> Carl
>>
>>
>> On Aug 22, 2007, at 8:40 AM, Jim Deville wrote:
>>
>>>
>>> On Aug 22, 2007, at 8:20 AM, Jay Levitt wrote:
>>>
>>>> David Chelimsky wrote:
>>>>> I'd like to ditch rspec's mock framework and let ppl use mocha or
>>>>> flexmock or RR (or others). RSpec's mocking framework doesn't  
>>>>> really
>>>>> offer anything above those frameworks, and it's therefore an
>>>>> unnecessary burden to maintain.
>>>> +1!  I currently use rspec's mocks because they're the default, but
>>>> I'd
>>>> have no problems switching frameworks.  If there's no good  
>>>> reason to
>>>> have our own, let's not have our own.
>>>>
>>>> Jay
>>>>
>>>
>>> +1, and +1 to moving things like Spec:UI and Spec:distributed. I
>>> would suggest keeping the literature on mocking, with minor
>>> modifications. The tight integration with mocking, and the pushing
>>> the ideas in the literature is what got my team and I to use it.   
>>> The
>>> current Rails literature really only shows mocks as a way to mock  
>>> out
>>> an external project, but I think it is good to use it to isolate
>>> tests as well. I think that is proper BDD, too.
>>>
>>> JIm
>>>
>>>>
>>>> _______________________________________________
>>>> 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 dan at tastapod.com  Wed Aug 22 14:40:31 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 22 Aug 2007 19:40:31 +0100
Subject: [rspec-devel] [Proposed Refactoring] - Example
 ->	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>	<46CB68D6.4050305@tastapod.com>	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
Message-ID: <46CC831F.9000100@tastapod.com>

David is right - I had the wrong end of the stick. More inline:

Brian Takita wrote:
> On 8/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>   
>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
>>     
>>> On 8/21/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>>>       
>>>> On 8/22/07, Jim Deville <james.deville at gmail.com> wrote:
>>>>         
>>>>>>>> ExampleLifeCycleManager???) and these things are all related.
>>>>>>>>
>>>>>>>>                 
>>>>>>> I'm suspicious of anything named Manager :)
>>>>>>>
>>>>>>>               
>>>>>> Seconded. Or Helper or Service or Util while we're at it :)
>>>>>>             
>>>>> Service rings with me, perhaps some combination of it could work.
>>>>>
>>>>>           
>>>> I think Dan meant Manager,Helper,Service,Util are all suspicious
>>>> names, and I agree.
>>>>         
Yes I did!
>>>> I like ExampleWorld and Example.
>>>>         
>> Well - which is which - in the story runner, the world is where the
>> stuff happens - which would equate to the current example_space. So
>> Example would remain Example, and ExampleSpace would become
>> ExampleWorld. Is that what you are thinking Brian?
>>     
> I was actuallly thinking the opposite.
>
> Comparing this with Test::Unit, a Behaviour is equivalent to a TestCase class.
> ExampleSpace + Example is equivalent to a TestCase instance.
>
> Example holds the run and error adding methods, while ExampleSpace is
> unpolluted by the run and other methods (not that this is really an
> issue with Test::Unit).
>
> Here the the responsibilities for each part:
> * The life of the example call chain (run, before and after callbacks,
> setup and teardown mocks, etc.)
>   
ExampleRunner
> * The actual execution of the code within the example block, along
> with the other methods defined in the Describe block
>   
Same. The ExampleRunner invokes the Example, which is the actual block 
of code with some other useful information. The actual /instance/ it 
invokes it in is the ExampleWorld.

This is using terms analagous to the story runner. The StoryRunner uses 
a ScenarioRunner to invoke a Scenario in a World, which provides the 
Given(), When() and Then() methods. (Actually World is a module so you 
can mix it in to your own world class, say an IntegrationTestCase).

The extension points are the object the World module gets mixed into 
(you can provide your own implementation, with the default being Object) 
and the ScenarioRunner's listener mechanism, where you can find out 
what's happening.

Cheers,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070822/866bf679/attachment.html 

From aslak.hellesoy at gmail.com  Wed Aug 22 14:53:49 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 22 Aug 2007 20:53:49 +0200
Subject: [rspec-devel] mock framework
In-Reply-To: <46CC80BD.6080705@jay.fm>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CC5444.3010102@jay.fm>
	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>
	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
	<46CC80BD.6080705@jay.fm>
Message-ID: <8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>

On 8/22/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> aslak hellesoy wrote:
> > On 8/22/07, Carl Porth <badcarl at gmail.com> wrote:
> >> +1, but what framework will rspec's generators use?  Should there be
> >> a translator? and what framework should the translator translate to?
> >>
> >
> > A translator from what to what? The RSpec mock framework will still
> > exist, it's just being factored out.
>
> But then RSpec and its example specs will be using an unmaintained mock
> framework that we don't recommend anyone else use?
>

Perhaps, but I don't see a compelling reason to migrate RSpec's own
specs to use a new mocking framework (yet). We have a framework that
works quite nicely for our needs.

Unmaintained code doesn't stop working, it just stops to evolve.

Aslak

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

From dan at tastapod.com  Wed Aug 22 15:02:50 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 22 Aug 2007 20:02:50 +0100
Subject: [rspec-devel] [Proposed Refactoring] - Example
 ->	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <46CC831F.9000100@tastapod.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>	<57c63afe0708210647p2a570915od3da1b731a7b8190@mail.gmail.com>	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>	<46CB68D6.4050305@tastapod.com>	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
	<46CC831F.9000100@tastapod.com>
Message-ID: <46CC885A.6050806@tastapod.com>

>
> The ExampleRunner invokes the Example, which is the actual block of 
> code with some other useful information. The actual /instance/ it 
> invokes it in is the ExampleWorld.

I just realised that I gave the impression Example is just a value 
object. In fact it has a method run_in(world) - which just contains 
world.instance_eval(block) - that the ExampleRunner calls.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070822/e0437cd4/attachment.html 

From aslak.hellesoy at gmail.com  Wed Aug 22 15:02:03 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 22 Aug 2007 21:02:03 +0200
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <46CC750D.4020408@tastapod.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<46CC750D.4020408@tastapod.com>
Message-ID: <8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>

On 8/22/07, Dan North <dan at tastapod.com> wrote:
> Hi Aslak.
>
> aslak hellesoy wrote:
> > On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> >
> >> This is a way to utilize Test::Unit in rspec.
> >>
> >> There are a number of BDD frameworks that utilize Test::Unit to create
> >> a simple implementation.
> >>
> >> This could also be a first step to using Test::Unit's runner.
> >>
> A similar conversation happened in the early days of jbehave about
> whether to use junit's runner. We decided to go with our own runner
> (like rspec did) because we wanted it to do other stuff (mostly
> lifecycle callbacks).
> > Using Test::Unit's runner might be compelling, but I don't know how
> > easy it will be to make it behave like today's RSpec. We have a lot of
> > extra command line options, different output and so on. I'm not sure
> > what it takes to make it happen.
> >
> I don't think it would be too difficult to write an adapter to run under
> test::unit. Right now, the describe method captures a block of code -
> the description (aka context) - and the it method captures another block
> of code - the example. You can replace these methods as follows:
>
> - describe Sheep dynamically creates a class called SheepTest that
> extends a subclass of TestCase, then it executes its block to gather
> examples, by using a modified it() method as follows:
> - it "should baa" dynamically creates a method in SheepTest called
> test_should_baa that looks like this:
> cls.define_method :test_should_baa do
>     begin
>        alert_listeners(:starting)
>        run_describe_block_with_it_method_disabled # so helper methods
> are defined
>        run_the_actual_example_block
>        alert_listeners(:succeeded)
>     rescue
>        alert_listeners(:failed)
>        raise
>     end
> end
>
> - Any before(:each) or after(:each) blocks get added to lists inside
> SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down methods.
> - before :all and after :all would be more tricky, but they are
> discouraged anyway.
>

It's more like the ! ruby methods. It's dangerous, there is a non
dangerous alternative and you should know precisely what you're doing.
(perhaps we should rename it before! to follow that convention).

For example, with Spec::Ui it's sorely needed. I know Bob Cotton will
agree with me here.

> All this would allow test::unit to find the adapted test case in
> ObjectSpace with a bunch of test methods that it would run as normal. I
> wrote a hack like this a while back so that I could have test methods
> that started with "should_" instead of "test_" and it worked pretty
> well. (Then I deleted it all - d'oh!)
>
> You can invoke the suite using testrb --options-to-test-unit --
> --options-to-rspec-after-double-dash
>

I have enough trouble teaching people command lines in the first
place. A more complex command line would not be received with open
arms.

> Most of the rspec command line options are about attaching different
> listeners around the behaviour invocation, so this would still work
> using a template test method.
>
> No doubt there are edge cases, but this would get us started.
>
> > What would be the main benefit for users? And for us?
> >
> Tools. Right now I can run a test::unit suite in eclipse using a
> short-cut and get a nice red/green tree of tests that I can drill into,
> right-click and re-run any test, etc. In contrast I can run my rspec
> suite as a "ruby application" and see rows of dots.
>
> Any effort that goes into making test::unit easier to use (say in rake
> or buildr) is immediately useful to rspec.
>

This is the strongest selling point - I'm with you here.

Another one is that our codebase would be potentially smaller.

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

From dchelimsky at gmail.com  Wed Aug 22 15:12:01 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 14:12:01 -0500
Subject: [rspec-devel] mock framework
In-Reply-To: <8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CC5444.3010102@jay.fm>
	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>
	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
	<46CC80BD.6080705@jay.fm>
	<8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>
Message-ID: <57c63afe0708221212s7ef41f4cyaa7d2f43fa7dcc40@mail.gmail.com>

On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/22/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> > aslak hellesoy wrote:
> > > On 8/22/07, Carl Porth <badcarl at gmail.com> wrote:
> > >> +1, but what framework will rspec's generators use?  Should there be
> > >> a translator? and what framework should the translator translate to?
> > >>
> > >
> > > A translator from what to what? The RSpec mock framework will still
> > > exist, it's just being factored out.
> >
> > But then RSpec and its example specs will be using an unmaintained mock
> > framework that we don't recommend anyone else use?
> >
>
> Perhaps, but I don't see a compelling reason to migrate RSpec's own
> specs to use a new mocking framework (yet). We have a framework that
> works quite nicely for our needs.
>
> Unmaintained code doesn't stop working, it just stops to evolve.

One way this could work would be to modify the generators to use a
mock_adapter based on rspec's current mocking framework. Then we'd
have a model that could be followed for the other frameworks.

In the long run, I do want rspec mocks to fade away, not just to
remain un-evolving. But there is no urgency for this.

David

>
> Aslak
>
> > Jay
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Wed Aug 22 15:16:12 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 14:16:12 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<46CC750D.4020408@tastapod.com>
	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>
Message-ID: <57c63afe0708221216k4ff237c7u98d0828da8f2863@mail.gmail.com>

On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/22/07, Dan North <dan at tastapod.com> wrote:
> > Hi Aslak.
> >
> > aslak hellesoy wrote:
> > > On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > >
> > >> This is a way to utilize Test::Unit in rspec.
> > >>
> > >> There are a number of BDD frameworks that utilize Test::Unit to create
> > >> a simple implementation.
> > >>
> > >> This could also be a first step to using Test::Unit's runner.
> > >>
> > A similar conversation happened in the early days of jbehave about
> > whether to use junit's runner. We decided to go with our own runner
> > (like rspec did) because we wanted it to do other stuff (mostly
> > lifecycle callbacks).
> > > Using Test::Unit's runner might be compelling, but I don't know how
> > > easy it will be to make it behave like today's RSpec. We have a lot of
> > > extra command line options, different output and so on. I'm not sure
> > > what it takes to make it happen.
> > >
> > I don't think it would be too difficult to write an adapter to run under
> > test::unit. Right now, the describe method captures a block of code -
> > the description (aka context) - and the it method captures another block
> > of code - the example. You can replace these methods as follows:
> >
> > - describe Sheep dynamically creates a class called SheepTest that
> > extends a subclass of TestCase, then it executes its block to gather
> > examples, by using a modified it() method as follows:
> > - it "should baa" dynamically creates a method in SheepTest called
> > test_should_baa that looks like this:
> > cls.define_method :test_should_baa do
> >     begin
> >        alert_listeners(:starting)
> >        run_describe_block_with_it_method_disabled # so helper methods
> > are defined
> >        run_the_actual_example_block
> >        alert_listeners(:succeeded)
> >     rescue
> >        alert_listeners(:failed)
> >        raise
> >     end
> > end
> >
> > - Any before(:each) or after(:each) blocks get added to lists inside
> > SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down methods.
> > - before :all and after :all would be more tricky, but they are
> > discouraged anyway.
> >
>
> It's more like the ! ruby methods. It's dangerous, there is a non
> dangerous alternative and you should know precisely what you're doing.
> (perhaps we should rename it before! to follow that convention).
>
> For example, with Spec::Ui it's sorely needed. I know Bob Cotton will
> agree with me here.
>
> > All this would allow test::unit to find the adapted test case in
> > ObjectSpace with a bunch of test methods that it would run as normal. I
> > wrote a hack like this a while back so that I could have test methods
> > that started with "should_" instead of "test_" and it worked pretty
> > well. (Then I deleted it all - d'oh!)
> >
> > You can invoke the suite using testrb --options-to-test-unit --
> > --options-to-rspec-after-double-dash
> >
>
> I have enough trouble teaching people command lines in the first
> place. A more complex command line would not be received with open
> arms.
>
> > Most of the rspec command line options are about attaching different
> > listeners around the behaviour invocation, so this would still work
> > using a template test method.
> >
> > No doubt there are edge cases, but this would get us started.
> >
> > > What would be the main benefit for users? And for us?
> > >
> > Tools. Right now I can run a test::unit suite in eclipse using a
> > short-cut and get a nice red/green tree of tests that I can drill into,
> > right-click and re-run any test, etc. In contrast I can run my rspec
> > suite as a "ruby application" and see rows of dots.
> >
> > Any effort that goes into making test::unit easier to use (say in rake
> > or buildr) is immediately useful to rspec.
> >
>
> This is the strongest selling point - I'm with you here.
>
> Another one is that our codebase would be potentially smaller.

With Brian's recent refactoring, it's getting there. But, oooohhh -
what's this new shiny story runner thing?

>
> > Cheers,
> > Dan
> >
> >
> > _______________________________________________
> > 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  Wed Aug 22 15:26:11 2007
From: dan at tastapod.com (Dan North)
Date: Wed, 22 Aug 2007 20:26:11 +0100
Subject: [rspec-devel] mock framework
In-Reply-To: <57c63afe0708221212s7ef41f4cyaa7d2f43fa7dcc40@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>	<46CC5444.3010102@jay.fm>	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>	<46CC80BD.6080705@jay.fm>	<8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>
	<57c63afe0708221212s7ef41f4cyaa7d2f43fa7dcc40@mail.gmail.com>
Message-ID: <46CC8DD3.8040302@tastapod.com>

One potential issue is the one-mocking-framework-per-run constraint. In 
other words, any future development of rspec would have to continue to 
use the rspec mocking framework because we couldn't suddenly start using 
mocha mocks (say) in new examples.

This isn't a big deal for now, but it would be if we started wanting to 
mock things that rspec's built-in mocking framework couldn't handle.

However it pans out, we will be implicitly "preferring" whichever 
framework rspec itself uses for describing its own behaviour. Of course 
this would become moot if we could choose a mocking framework per 
describe block (maybe using a stack that gets popped at the end of the 
describe block).

Cheers,
Dan

ps. +1 for leveraging other mocking frameworks - the less there is in 
the core, the better we can focus on the important stuff.

pps. +lots for keeping the (excellent) documentation about mocking in 
the core rspec docs. Mocking is a fundamental aspect of BDD.


David Chelimsky wrote:
> On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>   
>> On 8/22/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>>     
>>> aslak hellesoy wrote:
>>>       
>>>> On 8/22/07, Carl Porth <badcarl at gmail.com> wrote:
>>>>         
>>>>> +1, but what framework will rspec's generators use?  Should there be
>>>>> a translator? and what framework should the translator translate to?
>>>>>
>>>>>           
>>>> A translator from what to what? The RSpec mock framework will still
>>>> exist, it's just being factored out.
>>>>         
>>> But then RSpec and its example specs will be using an unmaintained mock
>>> framework that we don't recommend anyone else use?
>>>
>>>       
>> Perhaps, but I don't see a compelling reason to migrate RSpec's own
>> specs to use a new mocking framework (yet). We have a framework that
>> works quite nicely for our needs.
>>
>> Unmaintained code doesn't stop working, it just stops to evolve.
>>     
>
> One way this could work would be to modify the generators to use a
> mock_adapter based on rspec's current mocking framework. Then we'd
> have a model that could be followed for the other frameworks.
>
> In the long run, I do want rspec mocks to fade away, not just to
> remain un-evolving. But there is no urgency for this.
>
> David
>
>   
>> Aslak
>>
>>     
>>> Jay
>>>
>>> _______________________________________________
>>> 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/20070822/dbd559e0/attachment.html 

From mailing_lists at railsnewbie.com  Wed Aug 22 17:39:12 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 22 Aug 2007 17:39:12 -0400
Subject: [rspec-devel] mock framework
In-Reply-To: <46CC8DD3.8040302@tastapod.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>	<46CC5444.3010102@jay.fm>	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>	<46CC80BD.6080705@jay.fm>	<8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>
	<57c63afe0708221212s7ef41f4cyaa7d2f43fa7dcc40@mail.gmail.com>
	<46CC8DD3.8040302@tastapod.com>
Message-ID: <C9757665-12F3-422D-BAB4-BC10168CF882@railsnewbie.com>


On Aug 22, 2007, at 3:26 PM, Dan North wrote:

> One potential issue is the one-mocking-framework-per-run  
> constraint. In other words, any future development of rspec would  
> have to continue to use the rspec mocking framework because we  
> couldn't suddenly start using mocha mocks (say) in new examples.
>
> This isn't a big deal for now, but it would be if we started  
> wanting to mock things that rspec's built-in mocking framework  
> couldn't handle.
>
> However it pans out, we will be implicitly "preferring" whichever  
> framework rspec itself uses for describing its own behaviour. Of  
> course this would become moot if we could choose a mocking  
> framework per describe block (maybe using a stack that gets popped  
> at the end of the describe block).

I believe it's a good option to factor out the mocking framework.   
Why couldn't it just be a dependency on the rspec gem, and use it as  
the default, as it is now? If one wants to use another mocking  
framework, they can - that is the state of things right now (AFAIK).

But I think the docs should be clear about this - that doing bdd w/ 
out mocks & stubs shouldn't be an option.

As for using multiple mock frameworks on one project - is that  
currently an option?  Couldn't different spec_helper.rb files be  
included for different mocking frameworks?

Scott


From dchelimsky at gmail.com  Wed Aug 22 17:43:41 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 16:43:41 -0500
Subject: [rspec-devel] mock framework
In-Reply-To: <C9757665-12F3-422D-BAB4-BC10168CF882@railsnewbie.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CC5444.3010102@jay.fm>
	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>
	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
	<46CC80BD.6080705@jay.fm>
	<8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>
	<57c63afe0708221212s7ef41f4cyaa7d2f43fa7dcc40@mail.gmail.com>
	<46CC8DD3.8040302@tastapod.com>
	<C9757665-12F3-422D-BAB4-BC10168CF882@railsnewbie.com>
Message-ID: <57c63afe0708221443m45debf22wdb6a80a40dbae9fd@mail.gmail.com>

On 8/22/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> On Aug 22, 2007, at 3:26 PM, Dan North wrote:
>
> > One potential issue is the one-mocking-framework-per-run
> > constraint. In other words, any future development of rspec would
> > have to continue to use the rspec mocking framework because we
> > couldn't suddenly start using mocha mocks (say) in new examples.
> >
> > This isn't a big deal for now, but it would be if we started
> > wanting to mock things that rspec's built-in mocking framework
> > couldn't handle.
> >
> > However it pans out, we will be implicitly "preferring" whichever
> > framework rspec itself uses for describing its own behaviour. Of
> > course this would become moot if we could choose a mocking
> > framework per describe block (maybe using a stack that gets popped
> > at the end of the describe block).
>
> I believe it's a good option to factor out the mocking framework.
> Why couldn't it just be a dependency on the rspec gem, and use it as
> the default, as it is now? If one wants to use another mocking
> framework, they can - that is the state of things right now (AFAIK).
>
> But I think the docs should be clear about this - that doing bdd w/
> out mocks & stubs shouldn't be an option.
>
> As for using multiple mock frameworks on one project - is that
> currently an option?  Couldn't different spec_helper.rb files be
> included for different mocking frameworks?

The problem w/ mixing mocking frameworks is that some of them (namely
rspec and mocha) add methods to Object, and they use similar methods
(like mock()) to create mocks. So you can only safely have one mock
framework PER PROCESS, not per file.

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

From mailing_lists at railsnewbie.com  Wed Aug 22 17:50:08 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 22 Aug 2007 17:50:08 -0400
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<46CC750D.4020408@tastapod.com>
	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>
Message-ID: <EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>


On Aug 22, 2007, at 3:02 PM, aslak hellesoy wrote:

> On 8/22/07, Dan North <dan at tastapod.com> wrote:
>> Hi Aslak.
>>
>> aslak hellesoy wrote:
>>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
>>>
>>>> This is a way to utilize Test::Unit in rspec.
>>>>
>>>> There are a number of BDD frameworks that utilize Test::Unit to  
>>>> create
>>>> a simple implementation.
>>>>
>>>> This could also be a first step to using Test::Unit's runner.
>>>>
>> A similar conversation happened in the early days of jbehave about
>> whether to use junit's runner. We decided to go with our own runner
>> (like rspec did) because we wanted it to do other stuff (mostly
>> lifecycle callbacks).
>>> Using Test::Unit's runner might be compelling, but I don't know how
>>> easy it will be to make it behave like today's RSpec. We have a  
>>> lot of
>>> extra command line options, different output and so on. I'm not sure
>>> what it takes to make it happen.
>>>
>> I don't think it would be too difficult to write an adapter to run  
>> under
>> test::unit. Right now, the describe method captures a block of code -
>> the description (aka context) - and the it method captures another  
>> block
>> of code - the example. You can replace these methods as follows:
>>
>> - describe Sheep dynamically creates a class called SheepTest that
>> extends a subclass of TestCase, then it executes its block to gather
>> examples, by using a modified it() method as follows:
>> - it "should baa" dynamically creates a method in SheepTest called
>> test_should_baa that looks like this:
>> cls.define_method :test_should_baa do
>>     begin
>>        alert_listeners(:starting)
>>        run_describe_block_with_it_method_disabled # so helper methods
>> are defined
>>        run_the_actual_example_block
>>        alert_listeners(:succeeded)
>>     rescue
>>        alert_listeners(:failed)
>>        raise
>>     end
>> end
>>
>> - Any before(:each) or after(:each) blocks get added to lists inside
>> SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down  
>> methods.
>> - before :all and after :all would be more tricky, but they are
>> discouraged anyway.
>>
>
> It's more like the ! ruby methods. It's dangerous, there is a non
> dangerous alternative and you should know precisely what you're doing.
> (perhaps we should rename it before! to follow that convention).

I always thought that that was a LISP/Scheme convention - the  
question mark signifying a boolean return value, and the exclamation  
point signifying an "unsafe" function - unsafe in the Haskell/ 
functional way of thinking (i.e. change the state of an object).   
Obviously Ruby isn't a functional language, so I've always been a  
little bit curious as to what is considered "dangerous".

Scott



From dchelimsky at gmail.com  Wed Aug 22 18:00:51 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 17:00:51 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<46CC750D.4020408@tastapod.com>
	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>
	<EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>
Message-ID: <57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>

On 8/22/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> On Aug 22, 2007, at 3:02 PM, aslak hellesoy wrote:
>
> > On 8/22/07, Dan North <dan at tastapod.com> wrote:
> >> Hi Aslak.
> >>
> >> aslak hellesoy wrote:
> >>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> >>>
> >>>> This is a way to utilize Test::Unit in rspec.
> >>>>
> >>>> There are a number of BDD frameworks that utilize Test::Unit to
> >>>> create
> >>>> a simple implementation.
> >>>>
> >>>> This could also be a first step to using Test::Unit's runner.
> >>>>
> >> A similar conversation happened in the early days of jbehave about
> >> whether to use junit's runner. We decided to go with our own runner
> >> (like rspec did) because we wanted it to do other stuff (mostly
> >> lifecycle callbacks).
> >>> Using Test::Unit's runner might be compelling, but I don't know how
> >>> easy it will be to make it behave like today's RSpec. We have a
> >>> lot of
> >>> extra command line options, different output and so on. I'm not sure
> >>> what it takes to make it happen.
> >>>
> >> I don't think it would be too difficult to write an adapter to run
> >> under
> >> test::unit. Right now, the describe method captures a block of code -
> >> the description (aka context) - and the it method captures another
> >> block
> >> of code - the example. You can replace these methods as follows:
> >>
> >> - describe Sheep dynamically creates a class called SheepTest that
> >> extends a subclass of TestCase, then it executes its block to gather
> >> examples, by using a modified it() method as follows:
> >> - it "should baa" dynamically creates a method in SheepTest called
> >> test_should_baa that looks like this:
> >> cls.define_method :test_should_baa do
> >>     begin
> >>        alert_listeners(:starting)
> >>        run_describe_block_with_it_method_disabled # so helper methods
> >> are defined
> >>        run_the_actual_example_block
> >>        alert_listeners(:succeeded)
> >>     rescue
> >>        alert_listeners(:failed)
> >>        raise
> >>     end
> >> end
> >>
> >> - Any before(:each) or after(:each) blocks get added to lists inside
> >> SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down
> >> methods.
> >> - before :all and after :all would be more tricky, but they are
> >> discouraged anyway.
> >>
> >
> > It's more like the ! ruby methods. It's dangerous, there is a non
> > dangerous alternative and you should know precisely what you're doing.
> > (perhaps we should rename it before! to follow that convention).
>
> I always thought that that was a LISP/Scheme convention - the
> question mark signifying a boolean return value, and the exclamation
> point signifying an "unsafe" function - unsafe in the Haskell/
> functional way of thinking (i.e. change the state of an object).
> Obviously Ruby isn't a functional language, so I've always been a
> little bit curious as to what is considered "dangerous".

I don't think of ! as dangerous. To me it means "do this to yourself."
When you say list.reject { ... } you get a new list back with the
appropriate items removed. When you say list.reject! { ... }, those
items are actually removed from the list you're sending the message
to. Make sense?


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

From mailing_lists at railsnewbie.com  Wed Aug 22 18:06:18 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 22 Aug 2007 18:06:18 -0400
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<46CC750D.4020408@tastapod.com>
	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>
	<EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>
	<57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>
Message-ID: <4B624951-90D2-4CDB-B635-D5EEE81E4658@railsnewbie.com>

>>>
>>> It's more like the ! ruby methods. It's dangerous, there is a non
>>> dangerous alternative and you should know precisely what you're  
>>> doing.
>>> (perhaps we should rename it before! to follow that convention).
>>
>> I always thought that that was a LISP/Scheme convention - the
>> question mark signifying a boolean return value, and the exclamation
>> point signifying an "unsafe" function - unsafe in the Haskell/
>> functional way of thinking (i.e. change the state of an object).
>> Obviously Ruby isn't a functional language, so I've always been a
>> little bit curious as to what is considered "dangerous".
>
> I don't think of ! as dangerous. To me it means "do this to yourself."
> When you say list.reject { ... } you get a new list back with the
> appropriate items removed. When you say list.reject! { ... }, those
> items are actually removed from the list you're sending the message
> to. Make sense?

So I guess you do understand it as "dangerous" - that is, in the  
functional sense - of modifying the data your working on.  But this  
would make most methods in ruby ! methods.

Scott


From aslak.hellesoy at gmail.com  Wed Aug 22 18:47:14 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 23 Aug 2007 00:47:14 +0200
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<46CC750D.4020408@tastapod.com>
	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>
	<EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>
	<57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>
Message-ID: <8d961d900708221547n76fa5b06y47315e4f573be918@mail.gmail.com>

On 8/23/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/22/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >
> > On Aug 22, 2007, at 3:02 PM, aslak hellesoy wrote:
> >
> > > On 8/22/07, Dan North <dan at tastapod.com> wrote:
> > >> Hi Aslak.
> > >>
> > >> aslak hellesoy wrote:
> > >>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > >>>
> > >>>> This is a way to utilize Test::Unit in rspec.
> > >>>>
> > >>>> There are a number of BDD frameworks that utilize Test::Unit to
> > >>>> create
> > >>>> a simple implementation.
> > >>>>
> > >>>> This could also be a first step to using Test::Unit's runner.
> > >>>>
> > >> A similar conversation happened in the early days of jbehave about
> > >> whether to use junit's runner. We decided to go with our own runner
> > >> (like rspec did) because we wanted it to do other stuff (mostly
> > >> lifecycle callbacks).
> > >>> Using Test::Unit's runner might be compelling, but I don't know how
> > >>> easy it will be to make it behave like today's RSpec. We have a
> > >>> lot of
> > >>> extra command line options, different output and so on. I'm not sure
> > >>> what it takes to make it happen.
> > >>>
> > >> I don't think it would be too difficult to write an adapter to run
> > >> under
> > >> test::unit. Right now, the describe method captures a block of code -
> > >> the description (aka context) - and the it method captures another
> > >> block
> > >> of code - the example. You can replace these methods as follows:
> > >>
> > >> - describe Sheep dynamically creates a class called SheepTest that
> > >> extends a subclass of TestCase, then it executes its block to gather
> > >> examples, by using a modified it() method as follows:
> > >> - it "should baa" dynamically creates a method in SheepTest called
> > >> test_should_baa that looks like this:
> > >> cls.define_method :test_should_baa do
> > >>     begin
> > >>        alert_listeners(:starting)
> > >>        run_describe_block_with_it_method_disabled # so helper methods
> > >> are defined
> > >>        run_the_actual_example_block
> > >>        alert_listeners(:succeeded)
> > >>     rescue
> > >>        alert_listeners(:failed)
> > >>        raise
> > >>     end
> > >> end
> > >>
> > >> - Any before(:each) or after(:each) blocks get added to lists inside
> > >> SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down
> > >> methods.
> > >> - before :all and after :all would be more tricky, but they are
> > >> discouraged anyway.
> > >>
> > >
> > > It's more like the ! ruby methods. It's dangerous, there is a non
> > > dangerous alternative and you should know precisely what you're doing.
> > > (perhaps we should rename it before! to follow that convention).
> >
> > I always thought that that was a LISP/Scheme convention - the
> > question mark signifying a boolean return value, and the exclamation
> > point signifying an "unsafe" function - unsafe in the Haskell/
> > functional way of thinking (i.e. change the state of an object).
> > Obviously Ruby isn't a functional language, so I've always been a
> > little bit curious as to what is considered "dangerous".
>
> I don't think of ! as dangerous.

http://blog.segment7.net/articles/2007/08/15/david-black-explains-bang-methods

> To me it means "do this to yourself."
> When you say list.reject { ... } you get a new list back with the
> appropriate items removed. When you say list.reject! { ... }, those
> items are actually removed from the list you're sending the message
> to. Make sense?
>
>
> >
> > Scott
> >
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Wed Aug 22 19:11:45 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 23 Aug 2007 01:11:45 +0200
Subject: [rspec-devel] Moved Spec::Distributed
Message-ID: <8d961d900708221611kf9f55bau795d3730a300bc4e@mail.gmail.com>

It's now gone from the RSpec repo and lives in the rspec-ext project's
repo. I have added Bob Cotton (who has done wonders with Moved
Spec::Distributed) as a committer there, as well as David (who will
move Spec::Mock there).

Spec::Ui will follow the same path...

Aslak

From dchelimsky at gmail.com  Wed Aug 22 19:13:46 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 18:13:46 -0500
Subject: [rspec-devel] Moved Spec::Distributed
In-Reply-To: <8d961d900708221611kf9f55bau795d3730a300bc4e@mail.gmail.com>
References: <8d961d900708221611kf9f55bau795d3730a300bc4e@mail.gmail.com>
Message-ID: <57c63afe0708221613i5a13466kd55827b0733e560f@mail.gmail.com>

On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> It's now gone from the RSpec repo and lives in the rspec-ext project's
> repo. I have added Bob Cotton (who has done wonders with Moved
> Spec::Distributed) as a committer there, as well as David (who will
> move Spec::Mock there).

I'm going to wait on moving Spec::Mock for the 1.1 release - I want to
do a 1.0.9 release w/ Brian's refactoring and the addition of Story
Runner first. So, coming soon ....

>
> Spec::Ui will follow the same path...
>
> Aslak
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From undees at gmail.com  Wed Aug 22 19:30:58 2007
From: undees at gmail.com (Ian Dees)
Date: Wed, 22 Aug 2007 16:30:58 -0700
Subject: [rspec-devel] mock framework
Message-ID: <ad4f9af90708221630h2c294fa9m87a991c2f99c7b1@mail.gmail.com>

Quoth David:

> The problem w/ mixing mocking frameworks is that some of them (namely
> rspec and mocha) add methods to Object, and they use similar methods
> (like mock()) to create mocks. So you can only safely have one mock
> framework PER PROCESS, not per file.

Is the FreakyFreaky Sandbox usable/stable enough to deal with this possibility?

http://code.whytheluckystiff.net/sandbox

--Ian

From lists-rspec at shopwatch.org  Wed Aug 22 19:44:31 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Wed, 22 Aug 2007 19:44:31 -0400
Subject: [rspec-devel] [Proposed Refactoring] - Current
 ExampleSpace	class subclasses Test::Unit::TestCase
In-Reply-To: <4B624951-90D2-4CDB-B635-D5EEE81E4658@railsnewbie.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>	<46CC750D.4020408@tastapod.com>	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>	<EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>	<57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>
	<4B624951-90D2-4CDB-B635-D5EEE81E4658@railsnewbie.com>
Message-ID: <46CCCA5F.1040004@jay.fm>

On 8/22/2007 6:06 PM, Scott Taylor wrote:
>>>> It's more like the ! ruby methods. It's dangerous, there is a non
>>>> dangerous alternative and you should know precisely what you're  
>>>> doing.
>>>> (perhaps we should rename it before! to follow that convention).
>>> I always thought that that was a LISP/Scheme convention - the
>>> question mark signifying a boolean return value, and the exclamation
>>> point signifying an "unsafe" function - unsafe in the Haskell/
>>> functional way of thinking (i.e. change the state of an object).
>>> Obviously Ruby isn't a functional language, so I've always been a
>>> little bit curious as to what is considered "dangerous".
>> I don't think of ! as dangerous. To me it means "do this to yourself."
>> When you say list.reject { ... } you get a new list back with the
>> appropriate items removed. When you say list.reject! { ... }, those
>> items are actually removed from the list you're sending the message
>> to. Make sense?
> 
> So I guess you do understand it as "dangerous" - that is, in the  
> functional sense - of modifying the data your working on.  But this  
> would make most methods in ruby ! methods.

David A. Black posted a great blog entry about this last week:

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

Jay


From noreply at rubyforge.org  Wed Aug 22 19:49:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 22 Aug 2007 19:49:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070822234929.7FDB95240F06@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 09:49

Message:
David,

I have been thinking about this a bit more, and I think
checking both ways could be a bad move in 99.9% of cases.

I am thinking that if this happens will the error messages
be around the wrong way as well?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 00:18

Message:
Since this directly involves the rails magic that is
association_proxy, I don't see how it can be gotten around
without checking both ways.

That is unless you wanted to check to make sure it was an
association_proxy first then swap the comparison.  But that
seems the worse course.

I would grudgingly have to say you need to check both ways.
 As weird as it seems to me, it seems it is necessary in
this situation.

My 0.02

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-23 00:11

Message:
Thanks for the props - but do you have an opinion about modifying the comparison?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 00:08

Message:
I'm glad your on the case David.  I wouldn't have found that!

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-23 00:05

Message:
OK - Here's the deal:

clip

@mock_clip == association_proxy_clip => false
association_proxy_clip == @mock_clip => true

RSpec happens to be doing the comparison the first way:

expected == actual

I'm not sure of the best way to handle this. We could have rspec try == in both directions:

actual == expected || expected == actual

But that seems slimy to me. Anybody have an opinion about that?

Incidentally, mocha also compares [expected == actual], so the same problem would occur w/ mocha - and I'd bet the same is true of flexmock. In the end, the source of this problem is AssociationProxy, which seems to violate the Principle of Least Surprise in most sinister ways.


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

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

Message:
I'm on to something, but haven't gotten there yet.

Modifying the example in the pastie, the following passes:

    @book.should_receive(:can_store?) do |clip|
      @clip.object_id.should == clip.object_id
    end

But the following fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should == clip
    end

And this fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should equal(clip)
    end

I added specs for mocks and mock_models:

@mock.should == @mock
@mock.should equal(@mock)

@mock_model.should == @mock_model
@mock_model.should equal(@mock_model)

They all pass.

Here's my theory:

model.book.clip is not actually the clip object, but a Rails Association Proxy and it is not responding as you would expect to == or equal?.

Anybody else paying attention to this thread think that's a reasonable theory?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 17:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 15:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

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

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From mailing_lists at railsnewbie.com  Wed Aug 22 22:46:35 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 22 Aug 2007 22:46:35 -0400
Subject: [rspec-devel] [Proposed Refactoring] - Current
	ExampleSpace	class subclasses Test::Unit::TestCase
In-Reply-To: <46CCCA5F.1040004@jay.fm>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>	<46CC750D.4020408@tastapod.com>	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>	<EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>	<57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>
	<4B624951-90D2-4CDB-B635-D5EEE81E4658@railsnewbie.com>
	<46CCCA5F.1040004@jay.fm>
Message-ID: <03A7B8F8-7B15-46D1-8976-A4B4458AE2B5@railsnewbie.com>


On Aug 22, 2007, at 7:44 PM, Jay Levitt wrote:

> On 8/22/2007 6:06 PM, Scott Taylor wrote:
>>>>> It's more like the ! ruby methods. It's dangerous, there is a non
>>>>> dangerous alternative and you should know precisely what you're
>>>>> doing.
>>>>> (perhaps we should rename it before! to follow that convention).
>>>> I always thought that that was a LISP/Scheme convention - the
>>>> question mark signifying a boolean return value, and the  
>>>> exclamation
>>>> point signifying an "unsafe" function - unsafe in the Haskell/
>>>> functional way of thinking (i.e. change the state of an object).
>>>> Obviously Ruby isn't a functional language, so I've always been a
>>>> little bit curious as to what is considered "dangerous".
>>> I don't think of ! as dangerous. To me it means "do this to  
>>> yourself."
>>> When you say list.reject { ... } you get a new list back with the
>>> appropriate items removed. When you say list.reject! { ... }, those
>>> items are actually removed from the list you're sending the message
>>> to. Make sense?
>>
>> So I guess you do understand it as "dangerous" - that is, in the
>> functional sense - of modifying the data your working on.  But this
>> would make most methods in ruby ! methods.
>
> David A. Black posted a great blog entry about this last week:
>
> http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will- 
> rubyist


Ah - thank you.  The convention of ! methods didn't make a whole of  
sense without this explanation.

Thanks again,

Scott Taylor


From mailing_lists at railsnewbie.com  Wed Aug 22 22:49:17 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 22 Aug 2007 22:49:17 -0400
Subject: [rspec-devel] Moved Spec::Distributed
In-Reply-To: <8d961d900708221611kf9f55bau795d3730a300bc4e@mail.gmail.com>
References: <8d961d900708221611kf9f55bau795d3730a300bc4e@mail.gmail.com>
Message-ID: <D27B041B-052B-45D0-8F9F-D721F65A1502@railsnewbie.com>


On Aug 22, 2007, at 7:11 PM, aslak hellesoy wrote:

> It's now gone from the RSpec repo and lives in the rspec-ext project's
> repo. I have added Bob Cotton (who has done wonders with Moved
> Spec::Distributed) as a committer there, as well as David (who will
> move Spec::Mock there).
>
> Spec::Ui will follow the same path...

Great news.

Just out of curiosity - what will happen to the bug reports/feature  
requests currently in the Rspec tracker related to these issues?  Is  
there a way to migrate them, or will they have to be re-filed?

Scott




From james.deville at gmail.com  Wed Aug 22 23:53:20 2007
From: james.deville at gmail.com (Jim Deville)
Date: Wed, 22 Aug 2007 20:53:20 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Current
	ExampleSpace	class subclasses Test::Unit::TestCase
In-Reply-To: <46CCCA5F.1040004@jay.fm>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>	<46CC750D.4020408@tastapod.com>	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>	<EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>	<57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>
	<4B624951-90D2-4CDB-B635-D5EEE81E4658@railsnewbie.com>
	<46CCCA5F.1040004@jay.fm>
Message-ID: <A435C3CD-33C5-44CD-B5F4-58564E97243F@gmail.com>


On Aug 22, 2007, at 4:44 PM, Jay Levitt wrote:

> On 8/22/2007 6:06 PM, Scott Taylor wrote:
>>>>> It's more like the ! ruby methods. It's dangerous, there is a non
>>>>> dangerous alternative and you should know precisely what you're
>>>>> doing.
>>>>> (perhaps we should rename it before! to follow that convention).
>>>> I always thought that that was a LISP/Scheme convention - the
>>>> question mark signifying a boolean return value, and the  
>>>> exclamation
>>>> point signifying an "unsafe" function - unsafe in the Haskell/
>>>> functional way of thinking (i.e. change the state of an object).
>>>> Obviously Ruby isn't a functional language, so I've always been a
>>>> little bit curious as to what is considered "dangerous".
>>>

Ruby isn't fully a functional language, but it pulls in from the  
Functional Paradigm, in addition to it's LISPish inspirations.

>>> I don't think of ! as dangerous. To me it means "do this to  
>>> yourself."
>>> When you say list.reject { ... } you get a new list back with the
>>> appropriate items removed. When you say list.reject! { ... }, those
>>> items are actually removed from the list you're sending the message
>>> to. Make sense?
>>
>> So I guess you do understand it as "dangerous" - that is, in the
>> functional sense - of modifying the data your working on.  But this
>> would make most methods in ruby ! methods.
>
> David A. Black posted a great blog entry about this last week:
>
> http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will- 
> rubyist
>
> Jay
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From brian.takita at gmail.com  Wed Aug 22 23:57:23 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 22 Aug 2007 20:57:23 -0700
Subject: [rspec-devel] Describe blocks within a Behaviour class definition
Message-ID: <1d7ddd110708222057t1d7fa223j5ab7ec76334fd7b7@mail.gmail.com>

I created a branch that allows describe blocks within a Behaviour object.
svn+ssh://rubyforge.org/var/svn/rspec/branches/behaviour_subclassing

I'm wondering what everybody thinks of it. Do you think this is a step
in the right direction to make rspec more extendable?

Here is a Behaviour:

module Spec
  module DSL
    class BehaviourSpec < Behaviour
      describe BehaviourSpec, " with a describe block" do
        @@klass_variable_set = true
        CONSTANT = :foobar

        before do
          @instance_variable = :hello
        end

        it "should have access to instance variables" do
          @instance_variable.should == :hello
        end

        it "should have access to class variables" do
          @@klass_variable_set.should == true
        end

        it "should have access to constants" do
          CONSTANT.should == :foobar
        end

        it "should have access to methods defined in the Behaviour" do
          a_method.should == 22
        end

        def a_method
          22
        end
      end
    end
  end
end

I also experimented with:
module Spec
  module DSL
    class BehaviourSpec < Behaviour
        @@klass_variable_set = true
        CONSTANT = :foobar

        before do
          @instance_variable = :hello
        end

        it "should have access to instance variables" do
          @instance_variable.should == :hello
        end

        it "should have access to class variables" do
          @@klass_variable_set.should == true
        end

        it "should have access to constants" do
          CONSTANT.should == :foobar
        end

        it "should have access to methods defined in the Behaviour" do
          a_method.should == 22
        end

        def a_method
          22
        end
      end
    end
  end
end

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

I also experimented with not having a describe block within a class
definition, but there were fairly large implications. For example,
defining a method, does not give the examples access to the method.

Is this syntax better?
module Spec
  module DSL
    class BehaviourSpec < Behaviour
      @@klass_variable_set = true
      CONSTANT = :foobar

      before do
        @instance_variable = :hello
      end

      it "should have access to instance variables" do
        @instance_variable.should == :hello
      end

      it "should have access to class variables" do
        @@klass_variable_set.should == true
      end

      it "should have access to constants" do
        CONSTANT.should == :foobar
      end

      # These methods do not work
#      it "should have access to methods defined in the Behaviour" do
#        a_method.should == 22
#      end
#
#      def a_method
#        22
#      end
    end
  end
end

From brian.takita at gmail.com  Thu Aug 23 00:11:20 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 22 Aug 2007 21:11:20 -0700
Subject: [rspec-devel] Describe blocks within a Behaviour class
	definition
In-Reply-To: <1d7ddd110708222057t1d7fa223j5ab7ec76334fd7b7@mail.gmail.com>
References: <1d7ddd110708222057t1d7fa223j5ab7ec76334fd7b7@mail.gmail.com>
Message-ID: <1d7ddd110708222111t5fda9789n5c3d296fbaf5ed4@mail.gmail.com>

Oops, I meant that email to be:

I created a branch that allows describe blocks within a Behaviour object.
svn+ssh://rubyforge.org/var/svn/rspec/branches/behaviour_subclassing

I'm wondering what everybody thinks of it. Do you think this is a step
in the right direction to make rspec more extendable?

Here is a Behaviour:

module Spec
 module DSL
   class BehaviourSpec < Behaviour
     describe BehaviourSpec, " with a describe block" do
       @@klass_variable_set = true
       CONSTANT = :foobar

       before do
         @instance_variable = :hello
       end

       it "should have access to instance variables" do
         @instance_variable.should == :hello
       end

       it "should have access to class variables" do
         @@klass_variable_set.should == true
       end

       it "should have access to constants" do
         CONSTANT.should == :foobar
       end

       it "should have access to methods defined in the Behaviour" do
         a_method.should == 22
       end

       def a_method
         22
       end
     end
   end
 end
end

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

I also experimented with not having a describe block within a class
definition, but there were fairly large implications. For example,
defining a method, does not give the examples access to the method.

Is this syntax better?
module Spec
 module DSL
   class BehaviourSpec < Behaviour
     @@klass_variable_set = true
     CONSTANT = :foobar

     before do
       @instance_variable = :hello
     end

     it "should have access to instance variables" do
       @instance_variable.should == :hello
     end

     it "should have access to class variables" do
       @@klass_variable_set.should == true
     end

     it "should have access to constants" do
       CONSTANT.should == :foobar
     end

     # These methods do not work
#      it "should have access to methods defined in the Behaviour" do
#        a_method.should == 22
#      end
#
#      def a_method
#        22
#      end
   end
 end
end

From dchelimsky at gmail.com  Thu Aug 23 00:32:39 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Aug 2007 23:32:39 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Current ExampleSpace
	class subclasses Test::Unit::TestCase
In-Reply-To: <8d961d900708221547n76fa5b06y47315e4f573be918@mail.gmail.com>
References: <1d7ddd110708210204n2b9473d0j7f500e23c23cc66f@mail.gmail.com>
	<8d961d900708210228o46118f2cu2a59eebb07eef934@mail.gmail.com>
	<46CC750D.4020408@tastapod.com>
	<8d961d900708221202r35b880d9v7ff995a70196e89b@mail.gmail.com>
	<EE479EE7-7396-46CB-AA8D-088B8C34C2FD@railsnewbie.com>
	<57c63afe0708221500t73adba6cp10b8db02b2915b8e@mail.gmail.com>
	<8d961d900708221547n76fa5b06y47315e4f573be918@mail.gmail.com>
Message-ID: <57c63afe0708222132j510d5863nb43051aa312aeb67@mail.gmail.com>

On 8/22/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/23/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/22/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> > >
> > > On Aug 22, 2007, at 3:02 PM, aslak hellesoy wrote:
> > >
> > > > On 8/22/07, Dan North <dan at tastapod.com> wrote:
> > > >> Hi Aslak.
> > > >>
> > > >> aslak hellesoy wrote:
> > > >>> On 8/21/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > >>>
> > > >>>> This is a way to utilize Test::Unit in rspec.
> > > >>>>
> > > >>>> There are a number of BDD frameworks that utilize Test::Unit to
> > > >>>> create
> > > >>>> a simple implementation.
> > > >>>>
> > > >>>> This could also be a first step to using Test::Unit's runner.
> > > >>>>
> > > >> A similar conversation happened in the early days of jbehave about
> > > >> whether to use junit's runner. We decided to go with our own runner
> > > >> (like rspec did) because we wanted it to do other stuff (mostly
> > > >> lifecycle callbacks).
> > > >>> Using Test::Unit's runner might be compelling, but I don't know how
> > > >>> easy it will be to make it behave like today's RSpec. We have a
> > > >>> lot of
> > > >>> extra command line options, different output and so on. I'm not sure
> > > >>> what it takes to make it happen.
> > > >>>
> > > >> I don't think it would be too difficult to write an adapter to run
> > > >> under
> > > >> test::unit. Right now, the describe method captures a block of code -
> > > >> the description (aka context) - and the it method captures another
> > > >> block
> > > >> of code - the example. You can replace these methods as follows:
> > > >>
> > > >> - describe Sheep dynamically creates a class called SheepTest that
> > > >> extends a subclass of TestCase, then it executes its block to gather
> > > >> examples, by using a modified it() method as follows:
> > > >> - it "should baa" dynamically creates a method in SheepTest called
> > > >> test_should_baa that looks like this:
> > > >> cls.define_method :test_should_baa do
> > > >>     begin
> > > >>        alert_listeners(:starting)
> > > >>        run_describe_block_with_it_method_disabled # so helper methods
> > > >> are defined
> > > >>        run_the_actual_example_block
> > > >>        alert_listeners(:succeeded)
> > > >>     rescue
> > > >>        alert_listeners(:failed)
> > > >>        raise
> > > >>     end
> > > >> end
> > > >>
> > > >> - Any before(:each) or after(:each) blocks get added to lists inside
> > > >> SheepTest to be invoked by  boilerplate SheepTest#set_up/tear_down
> > > >> methods.
> > > >> - before :all and after :all would be more tricky, but they are
> > > >> discouraged anyway.
> > > >>
> > > >
> > > > It's more like the ! ruby methods. It's dangerous, there is a non
> > > > dangerous alternative and you should know precisely what you're doing.
> > > > (perhaps we should rename it before! to follow that convention).
> > >
> > > I always thought that that was a LISP/Scheme convention - the
> > > question mark signifying a boolean return value, and the exclamation
> > > point signifying an "unsafe" function - unsafe in the Haskell/
> > > functional way of thinking (i.e. change the state of an object).
> > > Obviously Ruby isn't a functional language, so I've always been a
> > > little bit curious as to what is considered "dangerous".
> >
> > I don't think of ! as dangerous.
>
> http://blog.segment7.net/articles/2007/08/15/david-black-explains-bang-methods

Guess stub! was a mistake :(

>
> > To me it means "do this to yourself."
> > When you say list.reject { ... } you get a new list back with the
> > appropriate items removed. When you say list.reject! { ... }, those
> > items are actually removed from the list you're sending the message
> > to. Make sense?
> >
> >
> > >
> > > Scott
> > >
> > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brian.takita at gmail.com  Thu Aug 23 03:25:00 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Thu, 23 Aug 2007 00:25:00 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <46CC885A.6050806@tastapod.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<1d7ddd110708210936n4ecdb1bdy87be3b188e0d6a19@mail.gmail.com>
	<46CB68D6.4050305@tastapod.com>
	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
	<46CC831F.9000100@tastapod.com> <46CC885A.6050806@tastapod.com>
Message-ID: <1d7ddd110708230025y44817901k1311b3213048cad2@mail.gmail.com>

I went ahead and renamed Example to ExampleRunner and ExampleSpace to Example.

There is a solid consensus that ExampleSpace should be Example, and it is now.
We are still deciding on when the now ExampleRunner should be called.
I just picked ExampleRunner.

I figure it will be easier to rename ExampleRunner, if we need to, now
that we don't need to do a double rename.

On 8/22/07, Dan North <dan at tastapod.com> wrote:
>
>
>
>  The ExampleRunner invokes the Example, which is the actual block of code
> with some other useful information. The actual instance it invokes it in is
> the ExampleWorld.
>
>  I just realised that I gave the impression Example is just a value object.
> In fact it has a method run_in(world) - which just contains
> world.instance_eval(block) - that the ExampleRunner calls.
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brian.takita at gmail.com  Thu Aug 23 03:35:25 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Thu, 23 Aug 2007 00:35:25 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708230025y44817901k1311b3213048cad2@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<46CB68D6.4050305@tastapod.com>
	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
	<46CC831F.9000100@tastapod.com> <46CC885A.6050806@tastapod.com>
	<1d7ddd110708230025y44817901k1311b3213048cad2@mail.gmail.com>
Message-ID: <1d7ddd110708230035k7307fb69w126e2d8a13b3d562@mail.gmail.com>

> ExampleWrapper
> ExampleProxy
> ExampleDriver
> ExampleConfig
> ExampleContainer
> ExampleLifeCycle

This object is currently responsible for:
* Running the Example (this includes all lifecycle management)
* Storing the Example description
* Determining if the Example description matches another Example description

I think these names encompass the all of the behaviour:
* ExampleWrapper
* ExampleDriver
* ExampleContainer
* ExampleLifeCycle (possibly)

ExampleRunner describes running the example, but not handling of the
description.
The class is mainly focused on running the example, with periphery
behaviour associated with handling the description.

On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> I went ahead and renamed Example to ExampleRunner and ExampleSpace to Example.
>
> There is a solid consensus that ExampleSpace should be Example, and it is now.
> We are still deciding on when the now ExampleRunner should be called.
> I just picked ExampleRunner.
>
> I figure it will be easier to rename ExampleRunner, if we need to, now
> that we don't need to do a double rename.
>
> On 8/22/07, Dan North <dan at tastapod.com> wrote:
> >
> >
> >
> >  The ExampleRunner invokes the Example, which is the actual block of code
> > with some other useful information. The actual instance it invokes it in is
> > the ExampleWorld.
> >
> >  I just realised that I gave the impression Example is just a value object.
> > In fact it has a method run_in(world) - which just contains
> > world.instance_eval(block) - that the ExampleRunner calls.
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>

From aslak.hellesoy at gmail.com  Thu Aug 23 04:28:42 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 23 Aug 2007 10:28:42 +0200
Subject: [rspec-devel] Moved Spec::Distributed
In-Reply-To: <D27B041B-052B-45D0-8F9F-D721F65A1502@railsnewbie.com>
References: <8d961d900708221611kf9f55bau795d3730a300bc4e@mail.gmail.com>
	<D27B041B-052B-45D0-8F9F-D721F65A1502@railsnewbie.com>
Message-ID: <8d961d900708230128q98710d2mf8c8580a004e9462@mail.gmail.com>

On 8/23/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> On Aug 22, 2007, at 7:11 PM, aslak hellesoy wrote:
>
> > It's now gone from the RSpec repo and lives in the rspec-ext project's
> > repo. I have added Bob Cotton (who has done wonders with Moved
> > Spec::Distributed) as a committer there, as well as David (who will
> > move Spec::Mock there).
> >
> > Spec::Ui will follow the same path...
>
> Great news.
>
> Just out of curiosity - what will happen to the bug reports/feature
> requests currently in the Rspec tracker related to these issues?  Is
> there a way to migrate them, or will they have to be re-filed?
>

Manual move. It's not many.

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

From dchelimsky at gmail.com  Thu Aug 23 05:59:51 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 23 Aug 2007 04:59:51 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708230035k7307fb69w126e2d8a13b3d562@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>
	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
	<46CC831F.9000100@tastapod.com> <46CC885A.6050806@tastapod.com>
	<1d7ddd110708230025y44817901k1311b3213048cad2@mail.gmail.com>
	<1d7ddd110708230035k7307fb69w126e2d8a13b3d562@mail.gmail.com>
Message-ID: <57c63afe0708230259x6e67a126p55a0d6b02298eb3c@mail.gmail.com>

On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> > ExampleWrapper
> > ExampleProxy
> > ExampleDriver
> > ExampleConfig
> > ExampleContainer
> > ExampleLifeCycle
>
> This object is currently responsible for:
> * Running the Example (this includes all lifecycle management)
> * Storing the Example description
> * Determining if the Example description matches another Example description
>
> I think these names encompass the all of the behaviour:
> * ExampleWrapper
> * ExampleDriver
> * ExampleContainer
> * ExampleLifeCycle (possibly)

ExampleWrapper and ExampleLifeCycle both express (to me) the
one-to-one mapping to Example that exists. Runner, Driver, and
Container all suggest collections to me, so I'd avoid these.

Of these, I think ExampleLifeCycle is the most interesting, but I'm
not convinced that the best name has appeared yet.

David

>
> ExampleRunner describes running the example, but not handling of the
> description.
> The class is mainly focused on running the example, with periphery
> behaviour associated with handling the description.
>
> On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> > I went ahead and renamed Example to ExampleRunner and ExampleSpace to Example.
> >
> > There is a solid consensus that ExampleSpace should be Example, and it is now.
> > We are still deciding on when the now ExampleRunner should be called.
> > I just picked ExampleRunner.
> >
> > I figure it will be easier to rename ExampleRunner, if we need to, now
> > that we don't need to do a double rename.
> >
> > On 8/22/07, Dan North <dan at tastapod.com> wrote:
> > >
> > >
> > >
> > >  The ExampleRunner invokes the Example, which is the actual block of code
> > > with some other useful information. The actual instance it invokes it in is
> > > the ExampleWorld.
> > >
> > >  I just realised that I gave the impression Example is just a value object.
> > > In fact it has a method run_in(world) - which just contains
> > > world.instance_eval(block) - that the ExampleRunner calls.
> > >
> > > _______________________________________________
> > > 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 lists-rspec at shopwatch.org  Thu Aug 23 07:25:22 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Thu, 23 Aug 2007 07:25:22 -0400
Subject: [rspec-devel] mock framework
In-Reply-To: <ad4f9af90708221630h2c294fa9m87a991c2f99c7b1@mail.gmail.com>
References: <ad4f9af90708221630h2c294fa9m87a991c2f99c7b1@mail.gmail.com>
Message-ID: <46CD6EA2.5000907@shopwatch.org>

On 8/22/2007 7:30 PM, Ian Dees wrote:
> Quoth David:
> 
>> The problem w/ mixing mocking frameworks is that some of them (namely
>> rspec and mocha) add methods to Object, and they use similar methods
>> (like mock()) to create mocks. So you can only safely have one mock
>> framework PER PROCESS, not per file.
> 
> Is the FreakyFreaky Sandbox usable/stable enough to deal with this possibility?
> 
> http://code.whytheluckystiff.net/sandbox

Looks like, until 1.9, that needs a patch to Ruby. :(

Jay


From lists-rspec at shopwatch.org  Thu Aug 23 07:34:16 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Thu, 23 Aug 2007 07:34:16 -0400
Subject: [rspec-devel] [Proposed Refactoring] - Example
 ->	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <57c63afe0708230259x6e67a126p55a0d6b02298eb3c@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>	<9053FA56-FF33-42FD-A564-252C419AF1F0@gmail.com>	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>	<46CC831F.9000100@tastapod.com>
	<46CC885A.6050806@tastapod.com>	<1d7ddd110708230025y44817901k1311b3213048cad2@mail.gmail.com>	<1d7ddd110708230035k7307fb69w126e2d8a13b3d562@mail.gmail.com>
	<57c63afe0708230259x6e67a126p55a0d6b02298eb3c@mail.gmail.com>
Message-ID: <46CD70B8.9070009@shopwatch.org>

On 8/23/2007 5:59 AM, David Chelimsky wrote:
> On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
>> This object is currently responsible for:
>> * Running the Example (this includes all lifecycle management)
>> * Storing the Example description
>> * Determining if the Example description matches another Example description
>>
>> I think these names encompass the all of the behaviour:
>> * ExampleWrapper
>> * ExampleDriver
>> * ExampleContainer
>> * ExampleLifeCycle (possibly)
> 
> ExampleWrapper and ExampleLifeCycle both express (to me) the
> one-to-one mapping to Example that exists. Runner, Driver, and
> Container all suggest collections to me, so I'd avoid these.
> 
> Of these, I think ExampleLifeCycle is the most interesting, but I'm
> not convinced that the best name has appeared yet.

Is ExampleOverseer too much like ExampleManager?
ExampleChaperone?   ExamplePilot?  ExampleBrain?

It's hard to think of things that control/manage a single other thing 
without controlling/managing a collection.

Jay


From dchelimsky at gmail.com  Thu Aug 23 07:55:08 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 23 Aug 2007 06:55:08 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <46CD70B8.9070009@shopwatch.org>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
	<46CC831F.9000100@tastapod.com> <46CC885A.6050806@tastapod.com>
	<1d7ddd110708230025y44817901k1311b3213048cad2@mail.gmail.com>
	<1d7ddd110708230035k7307fb69w126e2d8a13b3d562@mail.gmail.com>
	<57c63afe0708230259x6e67a126p55a0d6b02298eb3c@mail.gmail.com>
	<46CD70B8.9070009@shopwatch.org>
Message-ID: <57c63afe0708230455m2d927f0eq88164cc407175a23@mail.gmail.com>

On 8/23/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> On 8/23/2007 5:59 AM, David Chelimsky wrote:
> > On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> >> This object is currently responsible for:
> >> * Running the Example (this includes all lifecycle management)
> >> * Storing the Example description
> >> * Determining if the Example description matches another Example description
> >>
> >> I think these names encompass the all of the behaviour:
> >> * ExampleWrapper
> >> * ExampleDriver
> >> * ExampleContainer
> >> * ExampleLifeCycle (possibly)
> >
> > ExampleWrapper and ExampleLifeCycle both express (to me) the
> > one-to-one mapping to Example that exists. Runner, Driver, and
> > Container all suggest collections to me, so I'd avoid these.
> >
> > Of these, I think ExampleLifeCycle is the most interesting, but I'm
> > not convinced that the best name has appeared yet.
>
> Is ExampleOverseer too much like ExampleManager?
> ExampleChaperone?   ExamplePilot?  ExampleBrain?
>
> It's hard to think of things that control/manage a single other thing
> without controlling/managing a collection.

ExampleFrame
ExampleBox
ExampleHolder
ExampleHolster
ExampleSheath
ExampleScabbard
ExampleOwner
ExampleHousing
ExampleIntegument (look THAT one up)
ExampleEnvelope
ExampleSleeve
ExampleJacket
ExampleAgent
ExampleProxy
ExampleLaminate
ExampleVeneer

I'm beginning to think Brian's earlier idea ExampleDefinition might make sense.

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

From dchelimsky at gmail.com  Thu Aug 23 08:11:43 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 23 Aug 2007 07:11:43 -0500
Subject: [rspec-devel] another name-fest: story runner and ???? runner
Message-ID: <57c63afe0708230511x1b34cd25u507f5d770f57451c@mail.gmail.com>

So now that we have a Story Runner (the framework formerly known as
rbehave), we need a name for the thing that rspec is w/o the Story
Runner. Two ideas that have come up are:

Behaviour Runner
Example Runner

The problem with both of these is that Story Runner is also about
Examples of Behaviour. We need a word that suggests something
different from Story Runner - something more granular, but avoiding
the ill-fated terms of 'testerday' (ouch - sorry) like "unit."

One thing that occurs to me is that we're not really talking about
Runners at all, but rather Frameworks - so we could have a Story
Framework and an Object Framework. Just a thought.

Another thing is that Story Runner is more customer facing and that
which is yet to be named (TWIYTBN - pronounced 'twit-bin') is more
developer facing - so maybe something like Customer Story Runner and
Developer TWIYTBN Runner.

Thoughts?

David

From noreply at rubyforge.org  Thu Aug 23 11:25:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 23 Aug 2007 11:25:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070823152554.F397AA970004@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-23 15:25

Message:
OK - this has been staring me in the face for a few days but I only just say it through the trees.

The problem is not that the mock is lying, or that the comparison is failing. The mock is telling the truth - the object being passed to can_store? is a Rails association proxy, not the mock @clip that you are telling it to expect.

To get your spec to pass, you need to ensure that @clipping.clip returns the mock @clip:

  @clipping.stub!(:clip).and_return(@clip)

That way, when this gets executed:

  validates_each :clip do |model, attr, value|
    if !model.book.nil? && !model.clip.nil?
      if !model.book.store_with_privacy?( model.clip )
        model.errors.add(:clip, "You can't add this item to this book")
      end
    end
  end

model.clip => your mock (instead of the association proxy, which is lying through its teeth about its identity)

Cheers,
David

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 23:49

Message:
David,

I have been thinking about this a bit more, and I think
checking both ways could be a bad move in 99.9% of cases.

I am thinking that if this happens will the error messages
be around the wrong way as well?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 14:18

Message:
Since this directly involves the rails magic that is
association_proxy, I don't see how it can be gotten around
without checking both ways.

That is unless you wanted to check to make sure it was an
association_proxy first then swap the comparison.  But that
seems the worse course.

I would grudgingly have to say you need to check both ways.
 As weird as it seems to me, it seems it is necessary in
this situation.

My 0.02

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 14:11

Message:
Thanks for the props - but do you have an opinion about modifying the comparison?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 14:08

Message:
I'm glad your on the case David.  I wouldn't have found that!

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 14:05

Message:
OK - Here's the deal:

clip

@mock_clip == association_proxy_clip => false
association_proxy_clip == @mock_clip => true

RSpec happens to be doing the comparison the first way:

expected == actual

I'm not sure of the best way to handle this. We could have rspec try == in both directions:

actual == expected || expected == actual

But that seems slimy to me. Anybody have an opinion about that?

Incidentally, mocha also compares [expected == actual], so the same problem would occur w/ mocha - and I'd bet the same is true of flexmock. In the end, the source of this problem is AssociationProxy, which seems to violate the Principle of Least Surprise in most sinister ways.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 12:35

Message:
I'm on to something, but haven't gotten there yet.

Modifying the example in the pastie, the following passes:

    @book.should_receive(:can_store?) do |clip|
      @clip.object_id.should == clip.object_id
    end

But the following fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should == clip
    end

And this fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should equal(clip)
    end

I added specs for mocks and mock_models:

@mock.should == @mock
@mock.should equal(@mock)

@mock_model.should == @mock_model
@mock_model.should equal(@mock_model)

They all pass.

Here's my theory:

model.book.clip is not actually the clip object, but a Rails Association Proxy and it is not responding as you would expect to == or equal?.

Anybody else paying attention to this thread think that's a reasonable theory?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 07:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 05:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 00:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 00:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-24 15:29

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-24 15:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From aslak.hellesoy at gmail.com  Thu Aug 23 11:25:55 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 23 Aug 2007 17:25:55 +0200
Subject: [rspec-devel] another name-fest: story runner and ???? runner
In-Reply-To: <57c63afe0708230511x1b34cd25u507f5d770f57451c@mail.gmail.com>
References: <57c63afe0708230511x1b34cd25u507f5d770f57451c@mail.gmail.com>
Message-ID: <8d961d900708230825i794cd2a1ldda8261b33573f2@mail.gmail.com>

On 8/23/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> So now that we have a Story Runner (the framework formerly known as
> rbehave), we need a name for the thing that rspec is w/o the Story
> Runner. Two ideas that have come up are:
>
> Behaviour Runner
> Example Runner
>
> The problem with both of these is that Story Runner is also about
> Examples of Behaviour. We need a word that suggests something
> different from Story Runner - something more granular, but avoiding
> the ill-fated terms of 'testerday' (ouch - sorry) like "unit."
>
> One thing that occurs to me is that we're not really talking about
> Runners at all, but rather Frameworks - so we could have a Story
> Framework and an Object Framework. Just a thought.
>
> Another thing is that Story Runner is more customer facing and that
> which is yet to be named (TWIYTBN - pronounced 'twit-bin') is more
> developer facing - so maybe something like Customer Story Runner and
> Developer TWIYTBN Runner.
>
> Thoughts?
>

StoryRunner and ObjectRunner?

Yes, I know they are not perfect, but I'm too lazy to participate in a
25 email thread about its name =)

Aslak

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

From jim.weirich at gmail.com  Thu Aug 23 13:16:09 2007
From: jim.weirich at gmail.com (Jim Weirich)
Date: Thu, 23 Aug 2007 12:16:09 -0500
Subject: [rspec-devel] mock framework
In-Reply-To: <57c63afe0708221443m45debf22wdb6a80a40dbae9fd@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CC5444.3010102@jay.fm>
	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>
	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
	<46CC80BD.6080705@jay.fm>
	<8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>
	<57c63afe0708221212s7ef41f4cyaa7d2f43fa7dcc40@mail.gmail.com>
	<46CC8DD3.8040302@tastapod.com>
	<C9757665-12F3-422D-BAB4-BC10168CF882@railsnewbie.com>
	<57c63afe0708221443m45debf22wdb6a80a40dbae9fd@mail.gmail.com>
Message-ID: <901FFD0D-CBDB-48F1-B3BC-F8BD21B68385@gmail.com>


On Aug 22, 2007, at 4:43 PM, David Chelimsky wrote:
> The problem w/ mixing mocking frameworks is that some of them (namely
> rspec and mocha) add methods to Object, and they use similar methods
> (like mock()) to create mocks. So you can only safely have one mock
> framework PER PROCESS, not per file.

FlexMock will safely mix with Mocha (under Test::Unit).  I believe  
(without actually trying) that FlexMock will mix with the RSpec Mock  
as well with the restriction you have to explicitly validate the  
FlexMock mocks at the end of the spec.  (Since RSpec doesn't have the  
facility to use two mock frameworks invisibly).

-- 
-- Jim Weirich
-- jim.weirich at gmail.com





From dan at tastapod.com  Thu Aug 23 04:00:43 2007
From: dan at tastapod.com (Dan North)
Date: Thu, 23 Aug 2007 09:00:43 +0100
Subject: [rspec-devel] mock framework
In-Reply-To: <57c63afe0708221443m45debf22wdb6a80a40dbae9fd@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>	<46CC5444.3010102@jay.fm>	<9AE6B7B6-B9F2-4B49-B2A0-50CF45C29C8B@gmail.com>	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>	<46CC80BD.6080705@jay.fm>	<8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>	<57c63afe0708221212s7ef41f4cyaa7d2f43fa7dcc40@mail.gmail.com>	<46CC8DD3.8040302@tastapod.com>	<C9757665-12F3-422D-BAB4-BC10168CF882@railsnewbie.com>
	<57c63afe0708221443m45debf22wdb6a80a40dbae9fd@mail.gmail.com>
Message-ID: <46CD3EAB.6040303@tastapod.com>

David Chelimsky wrote:
> On 8/22/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>   
>> On Aug 22, 2007, at 3:26 PM, Dan North wrote:
>>
>>     
>>> One potential issue is the one-mocking-framework-per-run
>>> constraint. In other words, any future development of rspec would
>>> have to continue to use the rspec mocking framework because we
>>> couldn't suddenly start using mocha mocks (say) in new examples.
>>>
>>> This isn't a big deal for now, but it would be if we started
>>> wanting to mock things that rspec's built-in mocking framework
>>> couldn't handle.
>>>
>>> However it pans out, we will be implicitly "preferring" whichever
>>> framework rspec itself uses for describing its own behaviour. Of
>>> course this would become moot if we could choose a mocking
>>> framework per describe block (maybe using a stack that gets popped
>>> at the end of the describe block).
>>>       
>> I believe it's a good option to factor out the mocking framework.
>> Why couldn't it just be a dependency on the rspec gem, and use it as
>> the default, as it is now? If one wants to use another mocking
>> framework, they can - that is the state of things right now (AFAIK).
>>
>> But I think the docs should be clear about this - that doing bdd w/
>> out mocks & stubs shouldn't be an option.
>>
>> As for using multiple mock frameworks on one project - is that
>> currently an option?  Couldn't different spec_helper.rb files be
>> included for different mocking frameworks?
>>     
>
> The problem w/ mixing mocking frameworks is that some of them (namely
> rspec and mocha) add methods to Object, and they use similar methods
> (like mock()) to create mocks. So you can only safely have one mock
> framework PER PROCESS, not per file.
>   
I would suggest that you only want one mocking framework /per project/ 
anyway, for the sake of sanity. Surely that comes under common coding 
conventions?!

Cheers,
Dan

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

From noreply at rubyforge.org  Thu Aug 23 18:44:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 23 Aug 2007 18:44:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12547 ] validates_each issue in rails
	with mocking and stubbing
Message-ID: <20070823224426.7F4975240BC5@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Daniel Neighman (hassox)
Assigned to: Nobody (None)
Summary: validates_each issue in rails with mocking and stubbing

Initial Comment:
I've been trying some code that checks for a validates_each call in an AR model.

The spec:
http://pastie.caboo.se/81744

This produces the following error:

does not detect that two responses are equal

Mock 'Book_1027' expected :store_with_privacy? with (#<Clip:0x1a9139c @name="Clip_1025">) but received it with (#<Clip:0x1a9139c @name="Clip_1025">)

and

stub overwrites mock

Mock 'Book_1026' expected :store_with_privacy? with (#<Clip:0x1a91b1c @name="Clip_1025">) once, but received it 0 times

The Model is:
http://pastie.caboo.se/81745


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

>Comment By: Daniel Neighman (hassox)
Date: 2007-08-24 08:44

Message:
Thanx David.  It's good to get the spec working. 

That's a simple bit of trickery for this very strange problem.

That's certainly doesn't fit into my view of least surprise
from rails in this instance ;)



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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-24 01:25

Message:
OK - this has been staring me in the face for a few days but I only just say it through the trees.

The problem is not that the mock is lying, or that the comparison is failing. The mock is telling the truth - the object being passed to can_store? is a Rails association proxy, not the mock @clip that you are telling it to expect.

To get your spec to pass, you need to ensure that @clipping.clip returns the mock @clip:

  @clipping.stub!(:clip).and_return(@clip)

That way, when this gets executed:

  validates_each :clip do |model, attr, value|
    if !model.book.nil? && !model.clip.nil?
      if !model.book.store_with_privacy?( model.clip )
        model.errors.add(:clip, "You can't add this item to this book")
      end
    end
  end

model.clip => your mock (instead of the association proxy, which is lying through its teeth about its identity)

Cheers,
David

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 09:49

Message:
David,

I have been thinking about this a bit more, and I think
checking both ways could be a bad move in 99.9% of cases.

I am thinking that if this happens will the error messages
be around the wrong way as well?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 00:18

Message:
Since this directly involves the rails magic that is
association_proxy, I don't see how it can be gotten around
without checking both ways.

That is unless you wanted to check to make sure it was an
association_proxy first then swap the comparison.  But that
seems the worse course.

I would grudgingly have to say you need to check both ways.
 As weird as it seems to me, it seems it is necessary in
this situation.

My 0.02

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-23 00:11

Message:
Thanks for the props - but do you have an opinion about modifying the comparison?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-23 00:08

Message:
I'm glad your on the case David.  I wouldn't have found that!

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-23 00:05

Message:
OK - Here's the deal:

clip

@mock_clip == association_proxy_clip => false
association_proxy_clip == @mock_clip => true

RSpec happens to be doing the comparison the first way:

expected == actual

I'm not sure of the best way to handle this. We could have rspec try == in both directions:

actual == expected || expected == actual

But that seems slimy to me. Anybody have an opinion about that?

Incidentally, mocha also compares [expected == actual], so the same problem would occur w/ mocha - and I'd bet the same is true of flexmock. In the end, the source of this problem is AssociationProxy, which seems to violate the Principle of Least Surprise in most sinister ways.


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

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

Message:
I'm on to something, but haven't gotten there yet.

Modifying the example in the pastie, the following passes:

    @book.should_receive(:can_store?) do |clip|
      @clip.object_id.should == clip.object_id
    end

But the following fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should == clip
    end

And this fails:

    @book.should_receive(:can_store?) do |clip|
      @clip.should equal(clip)
    end

I added specs for mocks and mock_models:

@mock.should == @mock
@mock.should equal(@mock)

@mock_model.should == @mock_model
@mock_model.should equal(@mock_model)

They all pass.

Here's my theory:

model.book.clip is not actually the clip object, but a Rails Association Proxy and it is not responding as you would expect to == or equal?.

Anybody else paying attention to this thread think that's a reasonable theory?

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

Comment By: Daniel Neighman (hassox)
Date: 2007-08-22 17:24

Message:
Hi,

Thanx for looking at this David.  I've been away from my
machine.  I will zip it up and email it to you.

-Daniel

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 15:38

Message:
Michael - The issue you described was specific to the way expect_render and stub_render delegated to a mock proxy (or to the the real method).

I've fixed that (see http://rubyforge.org/tracker/index.php?func=detail&aid=13271&group_id=797&atid=3149),
but I don't think it's related to this problem, which Daniel is seeing in model specs.

Daniel - I'll throw my request to you again - I'm having trouble reproducing the original problem in this report - it would help if you could give me a patch or a failing spec or an entire project that I can just apply, unzip, whatever, and go.

Cheers,
David

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

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

Message:
Thanks Michael - patching rspec's own specs definitely makes it easy for me to see the problem you're trying to convey.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:51

Message:
I just added an expectation in rspec_on_rails that shows the problem, here the diff: http://pastie.caboo.se/89880 - I hope that is enough and helps.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:41

Message:
Daniel - I started to look at this, but due to the dependencies on other models couldn't really get anything going w/o making some assumptions.

If you would wrap up your project in a zip and either post it here or email me directly, I'll be glad to take a look at it. I just need to be able to unzip a file, create a db, run migrations and go.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 10:28

Message:
Michael - would you mind posting your spec please? Maybe a pastie.

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

Comment By: Michael Hamann (michitux)
Date: 2007-08-22 10:19

Message:
The problem that stub overwrites should_receive/expect occurs also in view-specs with template.stub_render and template.expect_render. Example: I have a partial that is rendered in a template. I test several things where I don't want to pay any attention to this partial. But then I want to test that the partial is actually rendered. Unfortunately this doesn't work. I am using rspec_on_rails revision 2419.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:38

Message:
The migrations are here
http://pastie.caboo.se/81756

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

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

Message:
Would you mind posting the relevant migrations as well? Then I can build a subset of your app and see the error happen.

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

Comment By: Daniel Neighman (hassox)
Date: 2007-07-25 01:23

Message:
A bit more information

I have rspec installed as plugins in rails

rspec 2174
rspec_on_rails 2174

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

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

From deanwampler at gmail.com  Thu Aug 23 21:16:30 2007
From: deanwampler at gmail.com (Dean Wampler)
Date: Thu, 23 Aug 2007 20:16:30 -0500
Subject: [rspec-devel] another name-fest: story runner and ???? runner
In-Reply-To: <57c63afe0708230511x1b34cd25u507f5d770f57451c@mail.gmail.com>
References: <57c63afe0708230511x1b34cd25u507f5d770f57451c@mail.gmail.com>
Message-ID: <6cf2a94f0708231816g4e1b1032s3349954cc7b1f6c7@mail.gmail.com>

On 8/23/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> So now that we have a Story Runner (the framework formerly known as
> rbehave), we need a name for the thing that rspec is w/o the Story
> Runner. Two ideas that have come up are:
>
> Behaviour Runner
> Example Runner
>
> ...


Description Runner?
It Runner? ;)

Or dispense with "Runner":

Descriptionator
Iterator ;)

Seriously, how about "verifier", "validator", or something along those
lines?
dean

-- 
Dean Wampler
http://www.objectmentor.com
http://www.aspectprogramming.com
http://www.contract4j.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070823/bfbe4e01/attachment.html 

From brian.takita at gmail.com  Thu Aug 23 22:05:25 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Thu, 23 Aug 2007 19:05:25 -0700
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <57c63afe0708230259x6e67a126p55a0d6b02298eb3c@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<8d961d900708211638h7a5eba77o5b0e6f0ba0314f08@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
	<46CC831F.9000100@tastapod.com> <46CC885A.6050806@tastapod.com>
	<1d7ddd110708230025y44817901k1311b3213048cad2@mail.gmail.com>
	<1d7ddd110708230035k7307fb69w126e2d8a13b3d562@mail.gmail.com>
	<57c63afe0708230259x6e67a126p55a0d6b02298eb3c@mail.gmail.com>
Message-ID: <1d7ddd110708231905k396ac52fxc1e0c4f9f1f02e4b@mail.gmail.com>

On 8/23/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > ExampleWrapper
> > > ExampleProxy
> > > ExampleDriver
> > > ExampleConfig
> > > ExampleContainer
> > > ExampleLifeCycle
> >
> > This object is currently responsible for:
> > * Running the Example (this includes all lifecycle management)
> > * Storing the Example description
> > * Determining if the Example description matches another Example description
> >
> > I think these names encompass the all of the behaviour:
> > * ExampleWrapper
> > * ExampleDriver
> > * ExampleContainer
> > * ExampleLifeCycle (possibly)
>
> ExampleWrapper and ExampleLifeCycle both express (to me) the
> one-to-one mapping to Example that exists. Runner, Driver, and
> Container all suggest collections to me, so I'd avoid these.

One thing we could do is to put the description into Example (since it
describes an example), and have one instance of ExampleRunner run all
of the examples in Behaviour.
That would separate concerns of running the Example from describing
the Example.

>
> Of these, I think ExampleLifeCycle is the most interesting, but I'm
> not convinced that the best name has appeared yet.
>
> David
>
> >
> > ExampleRunner describes running the example, but not handling of the
> > description.
> > The class is mainly focused on running the example, with periphery
> > behaviour associated with handling the description.
> >
> > On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > I went ahead and renamed Example to ExampleRunner and ExampleSpace to Example.
> > >
> > > There is a solid consensus that ExampleSpace should be Example, and it is now.
> > > We are still deciding on when the now ExampleRunner should be called.
> > > I just picked ExampleRunner.
> > >
> > > I figure it will be easier to rename ExampleRunner, if we need to, now
> > > that we don't need to do a double rename.
> > >
> > > On 8/22/07, Dan North <dan at tastapod.com> wrote:
> > > >
> > > >
> > > >
> > > >  The ExampleRunner invokes the Example, which is the actual block of code
> > > > with some other useful information. The actual instance it invokes it in is
> > > > the ExampleWorld.
> > > >
> > > >  I just realised that I gave the impression Example is just a value object.
> > > > In fact it has a method run_in(world) - which just contains
> > > > world.instance_eval(block) - that the ExampleRunner calls.
> > > >
> > > > _______________________________________________
> > > > 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 zach.dennis at gmail.com  Thu Aug 23 23:00:20 2007
From: zach.dennis at gmail.com (Zach Dennis)
Date: Thu, 23 Aug 2007 23:00:20 -0400
Subject: [rspec-devel] mock framework
In-Reply-To: <46CD3EAB.6040303@tastapod.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<84C24ACC-D5EF-4852-B65C-6E17A9FFFF5E@gmail.com>
	<8d961d900708221100v749055dfife944928c969ecaa@mail.gmail.com>
	<46CC80BD.6080705@jay.fm>
	<8d961d900708221153p29c402cbw6a0383395848eec6@mail.gmail.com>
	<57c63afe0708221212s7ef41f4cyaa7d2f43fa7dcc40@mail.gmail.com>
	<46CC8DD3.8040302@tastapod.com>
	<C9757665-12F3-422D-BAB4-BC10168CF882@railsnewbie.com>
	<57c63afe0708221443m45debf22wdb6a80a40dbae9fd@mail.gmail.com>
	<46CD3EAB.6040303@tastapod.com>
Message-ID: <85d99afe0708232000ic13c9ddlc05076468d3cea0e@mail.gmail.com>

On 8/23/07, Dan North <dan at tastapod.com> wrote:
>
>  David Chelimsky wrote:
>  On 8/22/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
>
>  On Aug 22, 2007, at 3:26 PM, Dan North wrote:
>
>
>
>  One potential issue is the one-mocking-framework-per-run
> constraint. In other words, any future development of rspec would
> have to continue to use the rspec mocking framework because we
> couldn't suddenly start using mocha mocks (say) in new examples.
>
> This isn't a big deal for now, but it would be if we started
> wanting to mock things that rspec's built-in mocking framework
> couldn't handle.
>
> However it pans out, we will be implicitly "preferring" whichever
> framework rspec itself uses for describing its own behaviour. Of
> course this would become moot if we could choose a mocking
> framework per describe block (maybe using a stack that gets popped
> at the end of the describe block).
>
>  I believe it's a good option to factor out the mocking framework.
> Why couldn't it just be a dependency on the rspec gem, and use it as
> the default, as it is now? If one wants to use another mocking
> framework, they can - that is the state of things right now (AFAIK).
>
> But I think the docs should be clear about this - that doing bdd w/
> out mocks & stubs shouldn't be an option.
>
> As for using multiple mock frameworks on one project - is that
> currently an option? Couldn't different spec_helper.rb files be
> included for different mocking frameworks?
>
>  The problem w/ mixing mocking frameworks is that some of them (namely
> rspec and mocha) add methods to Object, and they use similar methods
> (like mock()) to create mocks. So you can only safely have one mock
> framework PER PROCESS, not per file.
>
>  I would suggest that you only want one mocking framework per project
> anyway, for the sake of sanity. Surely that comes under common coding
> conventions?!
>
>  Cheers,
>  Dan
>
>

We use two mocking frameworks. Hardmock and Mocha. In some places we
want strict ordered mocks. In other places we don't care and we want
stubbing (which Mocha has and Hardmock doesn't).

They place nice together.

Zach

From dchelimsky at gmail.com  Thu Aug 23 23:34:56 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 23 Aug 2007 22:34:56 -0500
Subject: [rspec-devel] [Proposed Refactoring] - Example ->
	ExampleDefinition && ExampleSpace -> Example
In-Reply-To: <1d7ddd110708231905k396ac52fxc1e0c4f9f1f02e4b@mail.gmail.com>
References: <1d7ddd110708210201t25c32e9gc3f727a05774b83c@mail.gmail.com>
	<1d7ddd110708211817q4f20708n9b397bb531986fa6@mail.gmail.com>
	<57c63afe0708212035i4dd622efgb2ea5ed6a8a0a2dd@mail.gmail.com>
	<1d7ddd110708212348ma2ff11ck6837ed39d6d3d32b@mail.gmail.com>
	<46CC831F.9000100@tastapod.com> <46CC885A.6050806@tastapod.com>
	<1d7ddd110708230025y44817901k1311b3213048cad2@mail.gmail.com>
	<1d7ddd110708230035k7307fb69w126e2d8a13b3d562@mail.gmail.com>
	<57c63afe0708230259x6e67a126p55a0d6b02298eb3c@mail.gmail.com>
	<1d7ddd110708231905k396ac52fxc1e0c4f9f1f02e4b@mail.gmail.com>
Message-ID: <57c63afe0708232034g1247c998w5be3717fa52673b1@mail.gmail.com>

On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 8/23/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > > ExampleWrapper
> > > > ExampleProxy
> > > > ExampleDriver
> > > > ExampleConfig
> > > > ExampleContainer
> > > > ExampleLifeCycle
> > >
> > > This object is currently responsible for:
> > > * Running the Example (this includes all lifecycle management)
> > > * Storing the Example description
> > > * Determining if the Example description matches another Example description
> > >
> > > I think these names encompass the all of the behaviour:
> > > * ExampleWrapper
> > > * ExampleDriver
> > > * ExampleContainer
> > > * ExampleLifeCycle (possibly)
> >
> > ExampleWrapper and ExampleLifeCycle both express (to me) the
> > one-to-one mapping to Example that exists. Runner, Driver, and
> > Container all suggest collections to me, so I'd avoid these.
>
> One thing we could do is to put the description into Example (since it
> describes an example), and have one instance of ExampleRunner run all
> of the examples in Behaviour.
> That would separate concerns of running the Example from describing
> the Example.

If that's workable that makes good sense.

>
> >
> > Of these, I think ExampleLifeCycle is the most interesting, but I'm
> > not convinced that the best name has appeared yet.
> >
> > David
> >
> > >
> > > ExampleRunner describes running the example, but not handling of the
> > > description.
> > > The class is mainly focused on running the example, with periphery
> > > behaviour associated with handling the description.
> > >
> > > On 8/23/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > > I went ahead and renamed Example to ExampleRunner and ExampleSpace to Example.
> > > >
> > > > There is a solid consensus that ExampleSpace should be Example, and it is now.
> > > > We are still deciding on when the now ExampleRunner should be called.
> > > > I just picked ExampleRunner.
> > > >
> > > > I figure it will be easier to rename ExampleRunner, if we need to, now
> > > > that we don't need to do a double rename.
> > > >
> > > > On 8/22/07, Dan North <dan at tastapod.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >  The ExampleRunner invokes the Example, which is the actual block of code
> > > > > with some other useful information. The actual instance it invokes it in is
> > > > > the ExampleWorld.
> > > > >
> > > > >  I just realised that I gave the impression Example is just a value object.
> > > > > In fact it has a method run_in(world) - which just contains
> > > > > world.instance_eval(block) - that the ExampleRunner calls.
> > > > >
> > > > > _______________________________________________
> > > > > 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  Fri Aug 24 05:39:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 24 Aug 2007 05:39:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13326 ] add a parameter will be more
	convenient
Message-ID: <20070824093905.DB2B85240A1D@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: xiaoming lin (linxiaoming)
Assigned to: Nobody (None)
Summary: add a parameter will be more convenient  

Initial Comment:
Spec::Runner::Formatter::HtmlFormatter

class WebTestHtmlFormatter < Spec::Runner::Formatter::HtmlFormatter
  def extra_failure_content(failure)
    #print "aaa"
    #print failure.to_s
    #@output.puts "HTML source1" 
    @behaviour_red = true
    move_progress
    @output.puts "    <dd class=\spec failed\>"
    @output.puts "      <span class=\failed_spec_name\>abcdefg</span>"
 end
end

...

But I want to use the example object in WebTestHtmlFormatter?
but I can't accept the example object?

Is this a good idea?
#####def extra_failure_content(failure,example)####

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

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

From michael.s.klishin.lists at gmail.com  Fri Aug 24 09:52:10 2007
From: michael.s.klishin.lists at gmail.com (Michael Klishin)
Date: Fri, 24 Aug 2007 17:52:10 +0400
Subject: [rspec-devel] mock framework
In-Reply-To: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
Message-ID: <46CEE28A.90100@gmail.com>

Most people use what is by default. Others do not care whether there is 
a default framework, they use what they like or need. So I find process 
of making decision on this endless.

You may add an option to rspec generator and raise an exception if user 
do not specify what mocking framework to use. You may extract current 
one that RSpec uses. All these efforts will be confusing for most of 
RSpec users who just want stuff work, not be "vendor neutral".

The only benefit I see is that you can end up using the same framework 
Test::Unit does. And yes, you still have to use something by default 
(people will be telling you you prefer it, think about it). This will 
make a transition from T::U to RSpec a bit easier.

In the long run this is a useless move to me. We're better concentrate 
on RBehave merging and so forth.

David Chelimsky wrote:
> One thing I do NOT want to do is have RSpec prefer one framework over
> another.
> 
> Thoughts?

--
MK

From dchelimsky at gmail.com  Fri Aug 24 10:14:40 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 24 Aug 2007 09:14:40 -0500
Subject: [rspec-devel] mock framework
In-Reply-To: <46CEE28A.90100@gmail.com>
References: <57c63afe0708220755k23510f1bv40e213a698ffe829@mail.gmail.com>
	<46CEE28A.90100@gmail.com>
Message-ID: <57c63afe0708240714j62bd6981k7e0ba40e0468a9b9@mail.gmail.com>

On 8/24/07, Michael Klishin <michael.s.klishin.lists at gmail.com> wrote:
> Most people use what is by default. Others do not care whether there is
> a default framework, they use what they like or need. So I find process
> of making decision on this endless.
>
> You may add an option to rspec generator and raise an exception if user
> do not specify what mocking framework to use. You may extract current
> one that RSpec uses. All these efforts will be confusing for most of
> RSpec users who just want stuff work, not be "vendor neutral".
>
> The only benefit I see is that you can end up using the same framework
> Test::Unit does.

Huh? Test::Unit does not use any mock framework that I'm aware of.

> And yes, you still have to use something by default
> (people will be telling you you prefer it, think about it). This will
> make a transition from T::U to RSpec a bit easier.
>
> In the long run this is a useless move to me.

For me, maintaining RSpec's mocking framework, which does have feature
requests and bug reports from time to time, is more burden on the
project over the long haul than a bit of pain right now. And it really
doesn't add any value over mocha or flexmock. If it did, that would be
a different story. But I'd rather see our efforts focused on improving
things that are unique to RSpec.

So I don't see this as a useless exercise at all.

> We're better concentrate
> on RBehave merging and so forth.

That's certainly higher priority. Good point. But that doesn't mean it
has to be exclusive of other initiatives.

Cheers,
David


>
> David Chelimsky wrote:
> > One thing I do NOT want to do is have RSpec prefer one framework over
> > another.
> >
> > Thoughts?
>
> --
> MK
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Fri Aug 24 14:54:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 24 Aug 2007 14:54:47 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13336 ] Helper directory incorrect
	for rake stats in statsetup task
Message-ID: <20070824185447.AA65FA97001E@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Curtis Miller (curtm95)
Assigned to: Nobody (None)
Summary: Helper directory incorrect for rake stats in statsetup task

Initial Comment:
The helper directory specified in the statsetup task expects helpers to reside in the spec/views subdirectory.  It should be the spec/helpers subdirectory.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13336&group_id=797

From noreply at rubyforge.org  Fri Aug 24 15:52:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 24 Aug 2007 15:52:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13339 ] Add the ability for
	spec_parser to parse describes with :behaviour_type set
Message-ID: <20070824195222.17CD25240C97@rubyforge.org>

Patches item #13339, was opened at 2007-08-24 14:52
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13339&group_id=797

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Will Leinweber (leinweber)
Assigned to: Nobody (None)
Summary: Add the ability for spec_parser to parse describes with :behaviour_type set

Initial Comment:
This patch was pair-programmed between Dav Yaginuma and me.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13339&group_id=797

From noreply at rubyforge.org  Fri Aug 24 17:11:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 24 Aug 2007 17:11:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13339 ] Add the ability for
	spec_parser to parse describes with :behaviour_type set
Message-ID: <20070824211101.100725240D66@rubyforge.org>

Patches item #13339, was opened at 2007-08-24 19:52
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13339&group_id=797

Category: runner module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Will Leinweber (leinweber)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Add the ability for spec_parser to parse describes with :behaviour_type set

Initial Comment:
This patch was pair-programmed between Dav Yaginuma and me.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-24 21:11

Message:
Applied to r2430.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13339&group_id=797

From noreply at rubyforge.org  Fri Aug 24 17:18:45 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 24 Aug 2007 17:18:45 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13336 ] Helper directory incorrect
	for rake stats in statsetup task
Message-ID: <20070824211845.3924D5240D6F@rubyforge.org>

Patches item #13336, was opened at 2007-08-24 18:54
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13336&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Curtis Miller (curtm95)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Helper directory incorrect for rake stats in statsetup task

Initial Comment:
The helper directory specified in the statsetup task expects helpers to reside in the spec/views subdirectory.  It should be the spec/helpers subdirectory.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-24 21:18

Message:
Applied to r2431

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13336&group_id=797

From noreply at rubyforge.org  Sat Aug 25 15:01:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 25 Aug 2007 15:01:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13370 ] Weird mock expectation error
Message-ID: <20070825190154.144925240BCA@rubyforge.org>

Bugs item #13370, was opened at 2007-08-25 22:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Weird mock expectation error

Initial Comment:
While running code that contains

@user.should_receive(:assigned_to?).with(@issue).any_number_of_times.and_return true

# @issue is a mock as well

I'm getting weird failure:

Mock 'User_1263' expected :assigned_to? with (#<Issue:0x18b79b8 @name="Issue_1261">) but received it with (#<Issue:0x18b79b8 @name="Issue_1261">)

Any ideas?

P.S. trunk rspec

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

From noreply at rubyforge.org  Sat Aug 25 15:05:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 25 Aug 2007 15:05:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13370 ] Weird mock expectation error
Message-ID: <20070825190558.013895240D86@rubyforge.org>

Bugs item #13370, was opened at 2007-08-25 19:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Weird mock expectation error

Initial Comment:
While running code that contains

@user.should_receive(:assigned_to?).with(@issue).any_number_of_times.and_return true

# @issue is a mock as well

I'm getting weird failure:

Mock 'User_1263' expected :assigned_to? with (#<Issue:0x18b79b8 @name="Issue_1261">) but received it with (#<Issue:0x18b79b8 @name="Issue_1261">)

Any ideas?

P.S. trunk rspec

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-25 19:05

Message:
This has come up recently. If @issue is a mock, then make sure that the object it is being compared to is not a rails AssociationProxy, which will tell you that it is the model object even though it is not.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

From noreply at rubyforge.org  Sat Aug 25 15:12:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 25 Aug 2007 15:12:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13370 ] Weird mock expectation error
Message-ID: <20070825191228.6C13B5240D8B@rubyforge.org>

Bugs item #13370, was opened at 2007-08-25 22:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Weird mock expectation error

Initial Comment:
While running code that contains

@user.should_receive(:assigned_to?).with(@issue).any_number_of_times.and_return true

# @issue is a mock as well

I'm getting weird failure:

Mock 'User_1263' expected :assigned_to? with (#<Issue:0x18b79b8 @name="Issue_1261">) but received it with (#<Issue:0x18b79b8 @name="Issue_1261">)

Any ideas?

P.S. trunk rspec

----------------------------------------------------------------------

>Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-08-25 22:12

Message:
Any chance this will be fixed? Could I help? I urgently need to get this fixed or 
workarounded :)

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-25 22:05

Message:
This has come up recently. If @issue is a mock, then make sure that the object it is being compared to is not a rails AssociationProxy, which will tell you that it is the model object even though it is not.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

From noreply at rubyforge.org  Sat Aug 25 15:31:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 25 Aug 2007 15:31:33 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13370 ] Weird mock expectation error
Message-ID: <20070825193133.6A14D5240D8B@rubyforge.org>

Bugs item #13370, was opened at 2007-08-25 19:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Weird mock expectation error

Initial Comment:
While running code that contains

@user.should_receive(:assigned_to?).with(@issue).any_number_of_times.and_return true

# @issue is a mock as well

I'm getting weird failure:

Mock 'User_1263' expected :assigned_to? with (#<Issue:0x18b79b8 @name="Issue_1261">) but received it with (#<Issue:0x18b79b8 @name="Issue_1261">)

Any ideas?

P.S. trunk rspec

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-25 19:31

Message:
Hey Yurii: there is no plan, so feel free to submit a patch if you can figure something out that makes sense.

The problem is that Rails assoc proxy objects lie about who they are and ActiveRecord does type checking on associated collections. RSpec's mock_model creates an object that, similar to Rails, lies about its identity in order to pass Rails' type checking.

So you're getting two DIFFERENT OBJECTS that are both lying about their identity. RSpec is doing its job correctly (they really are two different objects and your spec *should* fail), but because both objects are impersonating something else, you get confusing/misleading feedback.

FYI - you'd get the same feedback from any mock framework (try it w/ mocha and/or flexmock).

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-08-25 19:12

Message:
Any chance this will be fixed? Could I help? I urgently need to get this fixed or 
workarounded :)

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-25 19:05

Message:
This has come up recently. If @issue is a mock, then make sure that the object it is being compared to is not a rails AssociationProxy, which will tell you that it is the model object even though it is not.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

From noreply at rubyforge.org  Sun Aug 26 08:07:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 26 Aug 2007 08:07:11 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13370 ] Weird mock expectation error
Message-ID: <20070826120711.AEBD75240A4E@rubyforge.org>

Bugs item #13370, was opened at 2007-08-25 22:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

Category: mock module
Group: None
Status: Open
>Resolution: Rejected
Priority: 3
Submitted By: Yurii Rashkovskii (yrashk)
Assigned to: Nobody (None)
Summary: Weird mock expectation error

Initial Comment:
While running code that contains

@user.should_receive(:assigned_to?).with(@issue).any_number_of_times.and_return true

# @issue is a mock as well

I'm getting weird failure:

Mock 'User_1263' expected :assigned_to? with (#<Issue:0x18b79b8 @name="Issue_1261">) but received it with (#<Issue:0x18b79b8 @name="Issue_1261">)

Any ideas?

P.S. trunk rspec

----------------------------------------------------------------------

>Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-08-26 15:07

Message:



----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-25 22:31

Message:
Hey Yurii: there is no plan, so feel free to submit a patch if you can figure something out that makes sense.

The problem is that Rails assoc proxy objects lie about who they are and ActiveRecord does type checking on associated collections. RSpec's mock_model creates an object that, similar to Rails, lies about its identity in order to pass Rails' type checking.

So you're getting two DIFFERENT OBJECTS that are both lying about their identity. RSpec is doing its job correctly (they really are two different objects and your spec *should* fail), but because both objects are impersonating something else, you get confusing/misleading feedback.

FYI - you'd get the same feedback from any mock framework (try it w/ mocha and/or flexmock).

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-08-25 22:12

Message:
Any chance this will be fixed? Could I help? I urgently need to get this fixed or 
workarounded :)

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-25 22:05

Message:
This has come up recently. If @issue is a mock, then make sure that the object it is being compared to is not a rails AssociationProxy, which will tell you that it is the model object even though it is not.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13370&group_id=797

From noreply at rubyforge.org  Sun Aug 26 22:30:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 26 Aug 2007 22:30:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13411 ] "./script/generate rspec" is
	freezing
Message-ID: <20070827023058.35063A970010@rubyforge.org>

Bugs item #13411, was opened at 2007-08-27 02:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13411&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: "./script/generate rspec" is freezing

Initial Comment:

Setup: 

Rails project (version 1.2.3), checked out in vendor/rails
Rspec + rspec_on_rails trunk (rev 2537) checked out in vendor/plugins
rspec gem, version 1.0.8
Mac OS X.4.10
(Am I missing anything else?)

Bug:

running "./script/generate rspec" first checks for the existence of the spec dir (which it finds), and then freezes.  

Oddly enough, running "rdebug ./script/generate rspec" allows the rest of the files to be created (after prompting), as usual.

I've uploaded a screencast of the bug here:

http://railsnewbie.com/files/script_generate_rspec.mov

I would try debugging this myself, but obviously my debugger has an effect on the debugging!



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13411&group_id=797

From noreply at rubyforge.org  Sun Aug 26 22:38:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 26 Aug 2007 22:38:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13412 ] Stop generating
	previous_failures.txt
Message-ID: <20070827023841.AD18CA970013@rubyforge.org>

Feature Requests item #13412, was opened at 2007-08-27 02:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13412&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Stop generating previous_failures.txt

Initial Comment:

Could we stop generating the file "previous_failures.txt" when running ./script/generate rspec ?  The use of that has been largely superceded by autotest, and I don't use it at all.  For those of us running on trunk, it gets annoying to constantly have to delete that file.  Plus, the file will be automatically generated with the appropriate switch (--format failing_examples:previous_failures.txt). 

I'll submit a patch for this, if anyone (else) thinks it's a good idea.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13412&group_id=797

From noreply at rubyforge.org  Sun Aug 26 22:41:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 26 Aug 2007 22:41:08 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13412 ] Stop generating
	previous_failures.txt
Message-ID: <20070827024108.349AFA970010@rubyforge.org>

Feature Requests item #13412, was opened at 2007-08-27 02:38
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13412&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Stop generating previous_failures.txt

Initial Comment:

Could we stop generating the file "previous_failures.txt" when running ./script/generate rspec ?  The use of that has been largely superceded by autotest, and I don't use it at all.  For those of us running on trunk, it gets annoying to constantly have to delete that file.  Plus, the file will be automatically generated with the appropriate switch (--format failing_examples:previous_failures.txt). 

I'll submit a patch for this, if anyone (else) thinks it's a good idea.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-27 02:41

Message:
I think its a good idea. Patch away.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13412&group_id=797

From mailing_lists at railsnewbie.com  Sun Aug 26 22:55:31 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Sun, 26 Aug 2007 22:55:31 -0400
Subject: [rspec-devel] rake install_dependencies
Message-ID: <F5C7C072-53E1-45E1-BE19-15368E73365D@railsnewbie.com>


Is there some reason we need to run this rake task (or  
update_dependencies) every time we submit a patch?  Why not just link  
the different rails versions via subversion's svn:externals?

Scott


From noreply at rubyforge.org  Mon Aug 27 02:54:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 02:54:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13411 ] "./script/generate rspec" is
	freezing
Message-ID: <20070827065458.4B338A97000A@rubyforge.org>

Bugs item #13411, was opened at 2007-08-26 22:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13411&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
>Summary: "./script/generate rspec" is freezing

Initial Comment:

Setup: 

Rails project (version 1.2.3), checked out in vendor/rails
Rspec + rspec_on_rails trunk (rev 2537) checked out in vendor/plugins
rspec gem, version 1.0.8
Mac OS X.4.10
(Am I missing anything else?)

Bug:

running "./script/generate rspec" first checks for the existence of the spec dir (which it finds), and then freezes.  

Oddly enough, running "rdebug ./script/generate rspec" allows the rest of the files to be created (after prompting), as usual.

I've uploaded a screencast of the bug here:

http://railsnewbie.com/files/script_generate_rspec.mov

I would try debugging this myself, but obviously my debugger has an effect on the debugging!



----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-27 02:54

Message:
Can you confirm that this only happens for the rspec generator and none of the others?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13411&group_id=797

From dchelimsky at gmail.com  Mon Aug 27 05:26:33 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 27 Aug 2007 04:26:33 -0500
Subject: [rspec-devel] rake install_dependencies
In-Reply-To: <F5C7C072-53E1-45E1-BE19-15368E73365D@railsnewbie.com>
References: <F5C7C072-53E1-45E1-BE19-15368E73365D@railsnewbie.com>
Message-ID: <57c63afe0708270226vfbd5afdi431e5706afa03e96@mail.gmail.com>

On 8/26/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> Is there some reason we need to run this rake task (or
> update_dependencies) every time we submit a patch?

Mostly because we want to make sure we're running against the latest edge rails.

> Why not just link
> the different rails versions via subversion's svn:externals?

We did that originally and it was problematic.

>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Mon Aug 27 08:10:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 08:10:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-6523 ] Run rspec on rails
	without a db
Message-ID: <20070827121058.2B628A97000B@rubyforge.org>

Feature Requests item #6523, was opened at 2006-11-06 21:07
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797

Category: None
Group: None
>Status: Open
Priority: 3
Submitted By: Paul Pagel (paulwpagel)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Run rspec on rails without a db

Initial Comment:
We need to be able to run the specs without the database.  We have no model objects in some of our projects, therefore, no use for the db.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-27 12:10

Message:
I'm reopening this because it's currently broken.

I think we should support unit_record by sensing for DisconnectedModel and not running all the Rails setup commands if it is found.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-04-04 09:49

Message:
Fixed in /branches/0.9-dev#1689

If you remove config/database.yml from your Rails project, the various spec:* rake tasks will no longer depend on db:test:prepare.

Further, you should tell Rails not to use AR in your config/environment.rb file



----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-04-01 14:08

Message:
Now that we have a cleaner configuration model, we should add a configuration option to do this:

Spec::Runner.configure do |config|
  config.use_database = false
end

(or something like that)

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2006-11-07 01:28

Message:
How do I reproduce this missing feature? How would you like it to work exactly? Code please.

http://rspec.rubyforge.org/contribute.html

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=6523&group_id=797

From noreply at rubyforge.org  Mon Aug 27 11:12:44 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 11:12:44 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13411 ] &quot;
	./script/generate rspec&quot; is freezing
Message-ID: <20070827151244.9C90D5240BB6@rubyforge.org>

Bugs item #13411, was opened at 2007-08-27 02:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13411&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
>Summary: &quot;./script/generate rspec&quot; is freezing

Initial Comment:

Setup: 

Rails project (version 1.2.3), checked out in vendor/rails
Rspec + rspec_on_rails trunk (rev 2537) checked out in vendor/plugins
rspec gem, version 1.0.8
Mac OS X.4.10
(Am I missing anything else?)

Bug:

running "./script/generate rspec" first checks for the existence of the spec dir (which it finds), and then freezes.  

Oddly enough, running "rdebug ./script/generate rspec" allows the rest of the files to be created (after prompting), as usual.

I've uploaded a screencast of the bug here:

http://railsnewbie.com/files/script_generate_rspec.mov

I would try debugging this myself, but obviously my debugger has an effect on the debugging!



----------------------------------------------------------------------

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-27 15:12

Message:
I wasn't sure which generators you were speaking of, so I
tried a bunch (all of them seemed to work):

euclid% ./script/generate model HelloWorld
      exists  app/models/
      exists  test/unit/
      exists  test/fixtures/
      create  app/models/hello_world.rb
      create  test/unit/hello_world_test.rb
      create  test/fixtures/hello_worlds.yml
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
euclid% ./script/destroy model HelloWorld
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  test/fixtures/hello_worlds.yml
          rm  test/unit/hello_world_test.rb
          rm  app/models/hello_world.rb
    notempty  test/fixtures
    notempty  test
    notempty  test/unit
    notempty  test
    notempty  app/models
    notempty  app
euclid% ./script/generate rspec_model HelloWorld
      exists  app/models/
      exists  spec/models/
      exists  spec/fixtures/
      create  app/models/hello_world.rb
      create  spec/fixtures/hello_worlds.yml
      create  spec/models/hello_world_spec.rb
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
euclid% ./script/generate rspec_controller HelloWorld
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/hello_world
      exists  spec/controllers/
      exists  spec/helpers/
      create  spec/views/hello_world
      create  spec/controllers/hello_world_controller_spec.rb
      create  spec/helpers/hello_world_helper_spec.rb
      create  app/controllers/hello_world_controller.rb
      create  app/helpers/hello_world_helper.rb
euclid% ./script/destroy rspec_model HelloWorld
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  spec/models/hello_world_spec.rb
          rm  spec/fixtures/hello_worlds.yml
          rm  app/models/hello_world.rb
    notempty  spec/fixtures
    notempty  spec
    notempty  spec/models
    notempty  spec
    notempty  app/models
    notempty  app
euclid% ./script/destroy rspec_controller HelloWorld
          rm  app/helpers/hello_world_helper.rb
          rm  app/controllers/hello_world_controller.rb
          rm  spec/helpers/hello_world_helper_spec.rb
          rm  spec/controllers/hello_world_controller_spec.rb
       rmdir  spec/views/hello_world
       rmdir  spec/views
Directory not empty - script/../config/../spec/views
euclid% ./script/generate rspec_scaffold HelloWorld
      exists  app/models/
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/hello_worlds
      exists  spec/controllers/
      exists  spec/models/
      exists  spec/helpers/
      exists  spec/fixtures/
      create  spec/views/hello_worlds
      create  spec/controllers/hello_worlds_controller_spec.rb
      create  app/controllers/hello_worlds_controller.rb
      create  spec/helpers/hello_worlds_helper_spec.rb
      create  app/helpers/hello_worlds_helper.rb
      create  app/views/hello_worlds/index.rhtml
      create  app/views/hello_worlds/show.rhtml
      create  app/views/hello_worlds/new.rhtml
      create  app/views/hello_worlds/edit.rhtml
      create  app/models/hello_world.rb
      create  spec/fixtures/hello_worlds.yml
      create  spec/models/hello_world_spec.rb
      create  spec/views/hello_worlds/edit.rhtml_spec.rb
      create  spec/views/hello_worlds/index.rhtml_spec.rb
      create  spec/views/hello_worlds/new.rhtml_spec.rb
      create  spec/views/hello_worlds/show.rhtml_spec.rb
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
       route  map.resources :hello_worlds
euclid% ./script/destroy rspec_scaffold HelloWorld
       route  map.resources :hello_worlds
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  spec/views/hello_worlds/show.rhtml_spec.rb
          rm  spec/views/hello_worlds/new.rhtml_spec.rb
          rm  spec/views/hello_worlds/index.rhtml_spec.rb
          rm  spec/views/hello_worlds/edit.rhtml_spec.rb
          rm  spec/models/hello_world_spec.rb
          rm  spec/fixtures/hello_worlds.yml
          rm  app/models/hello_world.rb
          rm  app/views/hello_worlds/edit.rhtml
          rm  app/views/hello_worlds/new.rhtml
          rm  app/views/hello_worlds/show.rhtml
          rm  app/views/hello_worlds/index.rhtml
          rm  app/helpers/hello_worlds_helper.rb
          rm  spec/helpers/hello_worlds_helper_spec.rb
          rm  app/controllers/hello_worlds_controller.rb
          rm  spec/controllers/hello_worlds_controller_spec.rb
       rmdir  spec/views/hello_worlds
       rmdir  spec/views
Directory not empty - script/../config/../spec/views
euclid% 

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-27 06:54

Message:
Can you confirm that this only happens for the rspec generator and none of the others?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13411&group_id=797

From noreply at rubyforge.org  Mon Aug 27 15:30:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 15:30:43 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13433 ] RSpec hangs when used with QtRuby
Message-ID: <20070827193043.7C71B5240DB5@rubyforge.org>

Bugs item #13433, was opened at 27/08/2007 21:30
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13433&group_id=797

Category: mock module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stefano Crocco (stcrocco)
Assigned to: Nobody (None)
Summary: RSpec hangs when used with QtRuby

Initial Comment:
Creating mocks/stubs for a method called 'type' and requiring (even if not actually using) QtRuby makes spec (or rake, when using the Spec task) hang indefinitly. This doesn't happen when mocking any other method or when using a mocking framework different from RSpec's default framework (at least, it works using flexmock).

This is the smallest piece of code which causes the problem:

require 'Qt4'

describe 'something' do

  it 'should work passing the :type parameter' do
    m = mock('test')
    m.should_receive(:type)
  end

end

The attached file contains the backtrace obtained running spec -b on the file prova.rb containing the above code (obtained after using Ctrl+C to stop spec after it hangs).

System description:

gentoo linux (kernel 2.6.21-gentoo-r3)
ruby: ruby 1.8.6 (2007-06-07 patchlevel 36)
rspec: RSpec-1.0.8 (r2338) (gem) (RSpec 1.0.5 didn't cause this problem)
Qt: 4.3.1 open source or Qt 3.3.8 (the problem happens with both qt3 and qt4)
QtRuby: 1.4.9 (for Qt4) and Korundum 3.5.5 (for KDE/Qt3)



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13433&group_id=797

From noreply at rubyforge.org  Mon Aug 27 15:54:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 15:54:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13437 ] "rake spec" always runs in
	development mode
Message-ID: <20070827195427.C12BF5240E3A@rubyforge.org>

Bugs item #13437, was opened at 2007-08-27 15:54
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13437&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: "rake spec" always runs in development mode

Initial Comment:

"rake spec" runs in development mode, not test!

railties/helpers/test_helper.rb has the line:
  ENV["RAILS_ENV"] = "test"

But #{MYAPP}/spec/spec_helper.rb has:
  ENV["RAILS_ENV"] ||= "test"

A little flexibility is always good, right?  Not really.  Because the first line of a Rails Rakefile is:
  require(File.join(File.dirname(__FILE__), 'config', 'boot'))

And that ends up calling railties/lib/initializer.rb, which says:
  RAILS_ENV = (ENV['RAILS_ENV'] || 'development').dup unless 
    defined?(RAILS_ENV)

So spec_helper.rb -always- has RAILS_ENV predefined when running under Rake.

I'd assume the solution is to change spec_helper.rb to act like test_helper.rb and always set RAILS_ENV, but if that affects someone else's non-Rake workflow, maybe there's a better way?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13437&group_id=797

From noreply at rubyforge.org  Mon Aug 27 16:30:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 16:30:03 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12722 ] the alternate file command
	does not work in rails views due to scope
Message-ID: <20070827203003.8AB0A5240DBB@rubyforge.org>

Patches item #12722, was opened at 2007-07-31 20:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797

Category: RSpec.tmbundle
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Carl Porth (badcarl)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: the alternate file command does not work in rails views due to scope

Initial Comment:
Here is a tiny patch to add the text.html.ruby scope to the Alternate File comand so it works in rails views.

----------------------------------------------------------------------

>Comment By: Carl Porth (badcarl)
Date: 2007-08-27 20:30

Message:
More specifically: when in an .html.erb suffixed view, the Alternate File 
command only works when your caret is in an erb tag (due to scope).  The patch 
adds scope so the command works wherever the caret happens to be in the 
view file.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797

From noreply at rubyforge.org  Mon Aug 27 16:39:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 16:39:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13437 ] "rake spec" always runs in
	development mode
Message-ID: <20070827203910.1423C5240DBB@rubyforge.org>

Bugs item #13437, was opened at 2007-08-27 19:54
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13437&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Jay Levitt (jaylev)
>Assigned to: David Chelimsky (dchelimsky)
>Summary: "rake spec" always runs in development mode

Initial Comment:

"rake spec" runs in development mode, not test!

railties/helpers/test_helper.rb has the line:
  ENV["RAILS_ENV"] = "test"

But #{MYAPP}/spec/spec_helper.rb has:
  ENV["RAILS_ENV"] ||= "test"

A little flexibility is always good, right?  Not really.  Because the first line of a Rails Rakefile is:
  require(File.join(File.dirname(__FILE__), 'config', 'boot'))

And that ends up calling railties/lib/initializer.rb, which says:
  RAILS_ENV = (ENV['RAILS_ENV'] || 'development').dup unless 
    defined?(RAILS_ENV)

So spec_helper.rb -always- has RAILS_ENV predefined when running under Rake.

I'd assume the solution is to change spec_helper.rb to act like test_helper.rb and always set RAILS_ENV, but if that affects someone else's non-Rake workflow, maybe there's a better way?

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-27 20:39

Message:
This was fixed a few releases back. Make sure to follow all the upgrade directions on http://rspec.rubyforge.org/upgrade.html, including running:

script/generate rspec

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13437&group_id=797

From noreply at rubyforge.org  Mon Aug 27 17:58:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 17:58:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12628 ] Integrate rbehave
	into rspec
Message-ID: <20070827215805.75EC15240E5C@rubyforge.org>

Feature Requests item #12628, was opened at 2007-07-27 13:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Dan North (tastapod)
>Assigned to: Dan North (tastapod)
Summary: Integrate rbehave into rspec

Initial Comment:
rbehave is a story/scenario description framework that describes behaviour for an application in the same way that rspec describes behaviour for objects.

It would make sense for rspec to contain rbehave in a "story" module (spec/story) so that rspec becomes a "full stack" BDD framework.

This initial feature request is simply to bring rbehave into the rspec project. Further work (ie. further feature requests) would create closer integration between the two, and providing a way to describe Rails behaviour at a story/scenario level.

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-07-28 16:48

Message:
I like the idea.  As long as it doesn't invalidate all those GUI tests I've written in RSpec....  ;-)

----------------------------------------------------------------------

Comment By: Michael Klishin (michaelklishin)
Date: 2007-07-28 12:14

Message:
RBehave is great, plus one for it. The only problem is that it is poorly documented. And yes, I'd like to submit a patch when I get deep enough in the source.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-07-28 11:59

Message:
First of all, thank you for your nice DSL

Then, here is a draft version of code that isolates scenarios into ActiveRecord transactions (extract from my project)

class ActiveRecordSafetyListener
  include Singleton
  def scenario_started(*args)
    unless Rails::VERSION::STRING == "1.1.6"
      ActiveRecord::Base.send :increment_open_transactions
    end
    ActiveRecord::Base.connection.begin_db_transaction
  end
  def scenario_succeeded(*args)
    ActiveRecord::Base.connection.rollback_db_transaction
    unless Rails::VERSION::STRING == "1.1.6"
      ActiveRecord::Base.send :decrement_open_transactions
    end
  end
  alias :scenario_pending :scenario_succeeded
  alias :scenario_failed :scenario_succeeded
end


class RBehave::Runner::ScenarioRunner
  def initialize
    @listeners = [ActiveRecordSafetyListener.instance]
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797

From noreply at rubyforge.org  Mon Aug 27 18:28:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 27 Aug 2007 18:28:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-12628 ] Integrate rbehave
	into rspec
Message-ID: <20070827222829.2A8975240E75@rubyforge.org>

Feature Requests item #12628, was opened at 2007-07-27 12:33
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Dan North (tastapod)
Assigned to: Dan North (tastapod)
Summary: Integrate rbehave into rspec

Initial Comment:
rbehave is a story/scenario description framework that describes behaviour for an application in the same way that rspec describes behaviour for objects.

It would make sense for rspec to contain rbehave in a "story" module (spec/story) so that rspec becomes a "full stack" BDD framework.

This initial feature request is simply to bring rbehave into the rspec project. Further work (ie. further feature requests) would create closer integration between the two, and providing a way to describe Rails behaviour at a story/scenario level.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-27 22:28

Message:
Committed to trunk in rev 2470

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-07-28 15:48

Message:
I like the idea.  As long as it doesn't invalidate all those GUI tests I've written in RSpec....  ;-)

----------------------------------------------------------------------

Comment By: Michael Klishin (michaelklishin)
Date: 2007-07-28 11:14

Message:
RBehave is great, plus one for it. The only problem is that it is poorly documented. And yes, I'd like to submit a patch when I get deep enough in the source.

----------------------------------------------------------------------

Comment By: Yurii Rashkovskii (yrashk)
Date: 2007-07-28 10:59

Message:
First of all, thank you for your nice DSL

Then, here is a draft version of code that isolates scenarios into ActiveRecord transactions (extract from my project)

class ActiveRecordSafetyListener
  include Singleton
  def scenario_started(*args)
    unless Rails::VERSION::STRING == "1.1.6"
      ActiveRecord::Base.send :increment_open_transactions
    end
    ActiveRecord::Base.connection.begin_db_transaction
  end
  def scenario_succeeded(*args)
    ActiveRecord::Base.connection.rollback_db_transaction
    unless Rails::VERSION::STRING == "1.1.6"
      ActiveRecord::Base.send :decrement_open_transactions
    end
  end
  alias :scenario_pending :scenario_succeeded
  alias :scenario_failed :scenario_succeeded
end


class RBehave::Runner::ScenarioRunner
  def initialize
    @listeners = [ActiveRecordSafetyListener.instance]
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=12628&group_id=797

From noreply at rubyforge.org  Tue Aug 28 01:56:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 01:56:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13186 ] Fix for
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	and url helpers
Message-ID: <20070828055626.92AA55240F9D@rubyforge.org>

Patches item #13186, was opened at 2007-08-18 18:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13186&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Timothy Bennett (lanaer)
Assigned to: Nobody (None)
Summary: Fix for ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods and url helpers

Initial Comment:
This fixes a nil.<< exception raised when the Rails REST url helpers are invoked from within a HelperEvalContext.

----------------------------------------------------------------------

Comment By: James Deville (parcelbrat)
Date: 2007-08-28 05:56

Message:
I believe this has been fixed on edge.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-19 03:20

Message:
Would you please resubmit with a failing spec?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13186&group_id=797

From noreply at rubyforge.org  Tue Aug 28 01:58:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 01:58:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-11919 ] Making non-implemented specs
	easy in textmate
Message-ID: <20070828055820.382595240F9D@rubyforge.org>

Patches item #11919, was opened at 2007-06-29 09:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11919&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Making non-implemented specs easy in textmate

Initial Comment:

Small modification to the 'it' textmate snippet.  The third tab trigger will allow the removal of the block, so that one can list a series of it "should ..." specifications, one after another.  

Two things:
1. I'm not exactly sure if anyone finds this useful, so please reject it if it isn't.
2. I couldn't figure out if this thing has specs to go along with it, and exactly how to add it to subversion, so I've attached the full bundle.

----------------------------------------------------------------------

Comment By: James Deville (parcelbrat)
Date: 2007-08-28 05:58

Message:
I've usually added a xit snippet which gives a pending spec. Anyone else like that idea?



----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 13:56

Message:
Disregard the last diff.  I figured out how to do it via.
subversion's diff.

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 13:41

Message:
No, actually I did check the checkbox, but for whatever
reason it wouldn't upload.  The svn diff also didn't
work...I had to do it manually.  Here is the diff of the
"it" snippet (I'll also attach it)

6c6
<       <string>it "${2:should ${1:description}}" ${3:do
---
>       <string>it "${2:should ${1:description}}" do
8c8
< end}</string>
---
> end</string>


----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-29 09:57

Message:
You forgot to check the attachment checkbox.
Can you attach a diff instead so I can see what you have changed? (Just svn add it locally before doing svn diff).


----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 09:46

Message:
the bundle...

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11919&group_id=797

From noreply at rubyforge.org  Tue Aug 28 02:01:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 02:01:31 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13451 ] Add a null_object option to
	mock_model
Message-ID: <20070828060131.96D445240F9D@rubyforge.org>

Patches item #13451, was opened at 2007-08-28 06:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13451&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: James Deville (parcelbrat)
Assigned to: Nobody (None)
Summary: Add a null_object option to mock_model

Initial Comment:
RSpec's (now old) mocking framework allows a :null_object => true. However, the mock_model method does not. This patch allows you to pass in a :null_object => true along with your other stubs, to get a null_object. 

I have found this very useful in controller tests, so that I don't have to add extra un-needed stubs to my setup block every time my controller's action changes.




----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13451&group_id=797

From noreply at rubyforge.org  Tue Aug 28 03:45:00 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 03:45:00 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13453 ] disabled specs
Message-ID: <20070828074500.59E9A5240F2C@rubyforge.org>

Feature Requests item #13453, was opened at 2007-08-28 00:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13453&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in

I'm open to names other than xit, such as disabled_it.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13453&group_id=797

From noreply at rubyforge.org  Tue Aug 28 03:51:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 03:51:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g.
	xit)
Message-ID: <20070828075120.CB2585240F35@rubyforge.org>

Feature Requests item #13454, was opened at 2007-08-28 00:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

From noreply at rubyforge.org  Tue Aug 28 10:25:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 10:25:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13186 ] Fix for
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	and url helpers
Message-ID: <20070828142521.6360B5240ACE@rubyforge.org>

Patches item #13186, was opened at 2007-08-18 18:25
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13186&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Timothy Bennett (lanaer)
Assigned to: Nobody (None)
Summary: Fix for ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods and url helpers

Initial Comment:
This fixes a nil.<< exception raised when the Rails REST url helpers are invoked from within a HelperEvalContext.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 14:25

Message:
This was fixed by http://rubyforge.org/tracker/?func=detail&group_id=797&aid=13065&atid=3149

----------------------------------------------------------------------

Comment By: James Deville (parcelbrat)
Date: 2007-08-28 05:56

Message:
I believe this has been fixed on edge.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-19 03:20

Message:
Would you please resubmit with a failing spec?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13186&group_id=797

From noreply at rubyforge.org  Tue Aug 28 10:30:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 10:30:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13020 ]
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	should not be included in helper specs?
Message-ID: <20070828143006.1767F5240ACE@rubyforge.org>

Bugs item #13020, was opened at 2007-08-12 22:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13020&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Mike Vincent (agile)
Assigned to: Nobody (None)
Summary: ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods should not be included in helper specs?

Initial Comment:
1.0.6+ includes additional modules into the helper specs. 

including ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods

causes conflicts in helpers as it redefines several methods, such as << 

def simple_example(name)
  markup = ''
  markup << content_tag(:h1, "hello #{name}")
  markup
end

simple_example('foo').should have_tag('h1', 'foo')


will throw a confusing method missing error from nil about the << method.








----------------------------------------------------------------------

Comment By: Jay Levitt (jaylev)
Date: 2007-08-28 10:30

Message:
I -think- this is fixed by http://rubyforge.org/tracker/?func=detail&group_id=797&aid=13065&atid=3149 instead.  Right?

----------------------------------------------------------------------

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 14:54

Message:
+1

I had this problem which led to a lot of confusion since the error message is not very helpful. Commenting out the include statement fixed it, although it makes me wonder if I'm breaking something else by doing this. Why are the generator methods included in the first place?

At least my specs are passing again...

----------------------------------------------------------------------

Comment By: Mike Vincent (agile)
Date: 2007-08-20 21:26

Message:
I think maybe I wasn't clear in the original message. I
don't believe the GeneratorMethods module is intended to be
mixed into the helper context and breaks things while it is
included. 

Not much clearer, I know. Someday me speak gooder.

Index:
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
===================================================================
---
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
       (revision 2411)
+++
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
       (working copy)
@@ -32,7 +32,7 @@
           include ActionView::Helpers::NumberHelper
           include ActionView::Helpers::PaginationHelper
rescue nil #removed after 1.2.3
           include ActionView::Helpers::PrototypeHelper
-          include
ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
+          #include
ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
           include ActionView::Helpers::ScriptaculousHelper
           include ActionView::Helpers::TagHelper
           include ActionView::Helpers::TextHelper


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13020&group_id=797

From noreply at rubyforge.org  Tue Aug 28 11:34:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 11:34:30 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13461 ] spec_ui ScreenshotFormatter
	selenium examples don't work
Message-ID: <20070828153430.B169A5240B8B@rubyforge.org>

Bugs item #13461, was opened at 2007-08-28 17:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: spec_ui ScreenshotFormatter selenium examples don't work

Initial Comment:
The selenium examples in rspec/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb
don't work anymore since the upgrade to 1.0.8

Stacktrace:

NoMethodError in 'Google's search page I should find rspec's home page when I search for rspec'
undefined method `take_screenshot_of' for nil:NilClass
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb:21:
/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb:18:

This is due to the fact that Spec::Ui::ScreenshotFormatter is now a Singleton and should be initialized.

I have attached a patch which adds the initialization of Spec::Ui::ScreenshotFormatter:

Spec::Ui::ScreenshotFormatter.new(File.dirname(__FILE__) + '/../specs.html')

 in the before :all of spec_helper because it seemed like a logical place.

Since this bug happens in the examples, I haven't written any spec. However, I can write some if necessary.

I am not using Watir since I am on Ubuntu but I guess there is the same problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

From noreply at rubyforge.org  Tue Aug 28 11:56:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 11:56:53 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13461 ] spec_ui ScreenshotFormatter
	selenium examples don't work
Message-ID: <20070828155653.D2CE35240AF0@rubyforge.org>

Bugs item #13461, was opened at 2007-08-28 17:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: spec_ui ScreenshotFormatter selenium examples don't work

Initial Comment:
The selenium examples in rspec/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb
don't work anymore since the upgrade to 1.0.8

Stacktrace:

NoMethodError in 'Google's search page I should find rspec's home page when I search for rspec'
undefined method `take_screenshot_of' for nil:NilClass
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb:21:
/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb:18:

This is due to the fact that Spec::Ui::ScreenshotFormatter is now a Singleton and should be initialized.

I have attached a patch which adds the initialization of Spec::Ui::ScreenshotFormatter:

Spec::Ui::ScreenshotFormatter.new(File.dirname(__FILE__) + '/../specs.html')

 in the before :all of spec_helper because it seemed like a logical place.

Since this bug happens in the examples, I haven't written any spec. However, I can write some if necessary.

I am not using Watir since I am on Ubuntu but I guess there is the same problem.

----------------------------------------------------------------------

>Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-28 17:56

Message:
The patch is the for
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb
and has been generated with netbeans 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

From noreply at rubyforge.org  Tue Aug 28 12:04:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 12:04:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g.
	xit)
Message-ID: <20070828160429.C755C5240B8D@rubyforge.org>

Feature Requests item #13454, was opened at 2007-08-28 00:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-28 09:04

Message:
Just playing devil's advocate here, but couldn't you accomplish the same by just pasting "; pending 'x'" at the end of the "it" line, like this?

describe Foo
  it 'should be baz' do; pending 'x'
    @foo.should == 'baz'
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

From noreply at rubyforge.org  Tue Aug 28 13:06:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 13:06:46 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g.
	xit)
Message-ID: <20070828170646.CA75B5240BDC@rubyforge.org>

Feature Requests item #13454, was opened at 2007-08-28 07:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 17:06

Message:
For me, RSpec is all about process. So even though I was originally resistant to this, the more I think about it the more I can see using it. I comment specs out all the time in practice and I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing.

I say go for it - but the docs should be very specific about intent (i.e. recommend that xit should not be committed).

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-28 16:04

Message:
Just playing devil's advocate here, but couldn't you accomplish the same by just pasting "; pending 'x'" at the end of the "it" line, like this?

describe Foo
  it 'should be baz' do; pending 'x'
    @foo.should == 'baz'
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

From aslak.hellesoy at gmail.com  Tue Aug 28 13:52:29 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 28 Aug 2007 19:52:29 +0200
Subject: [rspec-devel] Game of Life questions
Message-ID: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>

First of all, big kudos to Dan and David for making RBehave part of
RSpec. This kicks ass.

I'm finally taking a closer look at the new story runner and the
examples. These are my observations as a newcomer. I'm not complaining
- just pointing out things I think should be fixed - before I go ahead
and fix some of it myself:

1) It was hard to figure out how to run the game of life example.
First I looked for a Rake task and found none. Then I looked for
instructions in a README and found none. Then I went online and David
told me I had to run the everything.rb file. That works ok, but I
think we should come up with a more idiomatic way to run things.

2) I stumbled across .story files. Because of the special file
extension my initial hunch was that these are special files that the
behaviour runner knows how to parse and "execute". Then I realised
this is not the case. So I assume it's just leftovers, in which case I
think it should be moved to a different directory (docs?), given a new
file extension or deleted altogether. Same goes for the stores.txt
file.

3) The file structure feels a little unusual. For example, it's common
practice to have foo.rb as a sibling to the foo/ directory, but the
stories.rb file is a child, not a sibling. Further, there is no lib
folder for the code. Small things, but we should fix it. I think the
best is to move the game of life up under trunk or at least make it a
sibling of examples, not a child.

Let me know what you think,

Aslak

From dchelimsky at gmail.com  Tue Aug 28 14:05:42 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 28 Aug 2007 13:05:42 -0500
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
Message-ID: <57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>

On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> First of all, big kudos to Dan and David for making RBehave part of
> RSpec. This kicks ass.

Mostly Dan - I just helped when he got stuck.

> I'm finally taking a closer look at the new story runner and the
> examples. These are my observations as a newcomer. I'm not complaining
> - just pointing out things I think should be fixed - before I go ahead
> and fix some of it myself:
>
> 1) It was hard to figure out how to run the game of life example.
> First I looked for a Rake task and found none. Then I looked for
> instructions in a README and found none.

This is all stuff we need to do, but keep in mind this is not a release yet.

> Then I went online and David
> told me I had to run the everything.rb file. That works ok, but I
> think we should come up with a more idiomatic way to run things.

Agree. Given the discussions we've been having recently about bridging
the RSpec/Test::Unit gap, we should have a single command that can
field stories, specs and tests.

>
> 2) I stumbled across .story files. Because of the special file
> extension my initial hunch was that these are special files that the
> behaviour runner knows how to parse and "execute". Then I realised
> this is not the case. So I assume it's just leftovers, in which case I
> think it should be moved to a different directory (docs?), given a new
> file extension or deleted altogether. Same goes for the stores.txt
> file.
>
> 3) The file structure feels a little unusual. For example, it's common
> practice to have foo.rb as a sibling to the foo/ directory, but the
> stories.rb file is a child, not a sibling. Further, there is no lib
> folder for the code. Small things, but we should fix it. I think the
> best is to move the game of life up under trunk or at least make it a
> sibling of examples, not a child.

+1 for cleaning this up. Not sure about where the example should go. I
think it's going to take some playing around for us to figure out how
projects should be structured now that we've got the two tool sets
merged. In the game-of-life example, we've got:

project/behaviour/examples
project/behaviour/stories

I like that, though we still need to get the name right for what we've
called specs and examples. Thinking about how this stuff works
together, one idea is:

project/behaviour/objects
project/behaviour/stories

I kind of like that, but I'm not sold. Thoughts?

David

>
> Let me know what you think,
>
> Aslak
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Tue Aug 28 14:18:02 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 28 Aug 2007 20:18:02 +0200
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
Message-ID: <8d961d900708281118v674afd89i40a62ab1bf249073@mail.gmail.com>

On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > First of all, big kudos to Dan and David for making RBehave part of
> > RSpec. This kicks ass.
>
> Mostly Dan - I just helped when he got stuck.
>
> > I'm finally taking a closer look at the new story runner and the
> > examples. These are my observations as a newcomer. I'm not complaining
> > - just pointing out things I think should be fixed - before I go ahead
> > and fix some of it myself:
> >
> > 1) It was hard to figure out how to run the game of life example.
> > First I looked for a Rake task and found none. Then I looked for
> > instructions in a README and found none.
>
> This is all stuff we need to do, but keep in mind this is not a release yet.
>
> > Then I went online and David
> > told me I had to run the everything.rb file. That works ok, but I
> > think we should come up with a more idiomatic way to run things.
>
> Agree. Given the discussions we've been having recently about bridging
> the RSpec/Test::Unit gap, we should have a single command that can
> field stories, specs and tests.
>
> >
> > 2) I stumbled across .story files. Because of the special file
> > extension my initial hunch was that these are special files that the
> > behaviour runner knows how to parse and "execute". Then I realised
> > this is not the case. So I assume it's just leftovers, in which case I
> > think it should be moved to a different directory (docs?), given a new
> > file extension or deleted altogether. Same goes for the stores.txt
> > file.
> >
> > 3) The file structure feels a little unusual. For example, it's common
> > practice to have foo.rb as a sibling to the foo/ directory, but the
> > stories.rb file is a child, not a sibling. Further, there is no lib
> > folder for the code. Small things, but we should fix it. I think the
> > best is to move the game of life up under trunk or at least make it a
> > sibling of examples, not a child.
>
> +1 for cleaning this up. Not sure about where the example should go. I
> think it's going to take some playing around for us to figure out how
> projects should be structured now that we've got the two tool sets
> merged. In the game-of-life example, we've got:
>
> project/behaviour/examples
> project/behaviour/stories
>
> I like that, though we still need to get the name right for what we've
> called specs and examples. Thinking about how this stuff works
> together, one idea is:
>
> project/behaviour/objects
> project/behaviour/stories

I assume that is for a gem/regular ruby app. I like that structure.

But what would the structure be in a Rails app?

project/behaviour/models
project/behaviour/controllers
project/behaviour/views
project/behaviour/helpers
project/behaviour/objects # this is for lib - following same naming
convention as for "gems"
project/behaviour/stories
?
>
> I kind of like that, but I'm not sold. Thoughts?
>

It's good enough for me, but I'm cheap

Aslak

> David
>
> >
> > Let me know what you think,
> >
> > Aslak
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Tue Aug 28 14:25:00 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 28 Aug 2007 13:25:00 -0500
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <8d961d900708281118v674afd89i40a62ab1bf249073@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
	<8d961d900708281118v674afd89i40a62ab1bf249073@mail.gmail.com>
Message-ID: <57c63afe0708281125v415b7896r174dd4e0358014c4@mail.gmail.com>

On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > First of all, big kudos to Dan and David for making RBehave part of
> > > RSpec. This kicks ass.
> >
> > Mostly Dan - I just helped when he got stuck.
> >
> > > I'm finally taking a closer look at the new story runner and the
> > > examples. These are my observations as a newcomer. I'm not complaining
> > > - just pointing out things I think should be fixed - before I go ahead
> > > and fix some of it myself:
> > >
> > > 1) It was hard to figure out how to run the game of life example.
> > > First I looked for a Rake task and found none. Then I looked for
> > > instructions in a README and found none.
> >
> > This is all stuff we need to do, but keep in mind this is not a release yet.
> >
> > > Then I went online and David
> > > told me I had to run the everything.rb file. That works ok, but I
> > > think we should come up with a more idiomatic way to run things.
> >
> > Agree. Given the discussions we've been having recently about bridging
> > the RSpec/Test::Unit gap, we should have a single command that can
> > field stories, specs and tests.
> >
> > >
> > > 2) I stumbled across .story files. Because of the special file
> > > extension my initial hunch was that these are special files that the
> > > behaviour runner knows how to parse and "execute". Then I realised
> > > this is not the case. So I assume it's just leftovers, in which case I
> > > think it should be moved to a different directory (docs?), given a new
> > > file extension or deleted altogether. Same goes for the stores.txt
> > > file.
> > >
> > > 3) The file structure feels a little unusual. For example, it's common
> > > practice to have foo.rb as a sibling to the foo/ directory, but the
> > > stories.rb file is a child, not a sibling. Further, there is no lib
> > > folder for the code. Small things, but we should fix it. I think the
> > > best is to move the game of life up under trunk or at least make it a
> > > sibling of examples, not a child.
> >
> > +1 for cleaning this up. Not sure about where the example should go. I
> > think it's going to take some playing around for us to figure out how
> > projects should be structured now that we've got the two tool sets
> > merged. In the game-of-life example, we've got:
> >
> > project/behaviour/examples
> > project/behaviour/stories
> >
> > I like that, though we still need to get the name right for what we've
> > called specs and examples. Thinking about how this stuff works
> > together, one idea is:
> >
> > project/behaviour/objects
> > project/behaviour/stories
>
> I assume that is for a gem/regular ruby app. I like that structure.
>
> But what would the structure be in a Rails app?
>
> project/behaviour/models
> project/behaviour/controllers
> project/behaviour/views
> project/behaviour/helpers
> project/behaviour/objects # this is for lib - following same naming
> convention as for "gems"
> project/behaviour/stories

For me, models, controllers, views, and helpers roll up under objects.
There's always two levels of examples: story and everything else - I'm
saying everything else is objects, but it could be something else.
How's that for clarification?

> ?
> >
> > I kind of like that, but I'm not sold. Thoughts?
> >
>
> It's good enough for me, but I'm cheap
>
> Aslak
>
> > David
> >
> > >
> > > Let me know what you think,
> > >
> > > Aslak
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Tue Aug 28 14:40:20 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 28 Aug 2007 20:40:20 +0200
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <57c63afe0708281125v415b7896r174dd4e0358014c4@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
	<8d961d900708281118v674afd89i40a62ab1bf249073@mail.gmail.com>
	<57c63afe0708281125v415b7896r174dd4e0358014c4@mail.gmail.com>
Message-ID: <8d961d900708281140y9f3b44epfa9b29b67788e704@mail.gmail.com>

On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > First of all, big kudos to Dan and David for making RBehave part of
> > > > RSpec. This kicks ass.
> > >
> > > Mostly Dan - I just helped when he got stuck.
> > >
> > > > I'm finally taking a closer look at the new story runner and the
> > > > examples. These are my observations as a newcomer. I'm not complaining
> > > > - just pointing out things I think should be fixed - before I go ahead
> > > > and fix some of it myself:
> > > >
> > > > 1) It was hard to figure out how to run the game of life example.
> > > > First I looked for a Rake task and found none. Then I looked for
> > > > instructions in a README and found none.
> > >
> > > This is all stuff we need to do, but keep in mind this is not a release yet.
> > >
> > > > Then I went online and David
> > > > told me I had to run the everything.rb file. That works ok, but I
> > > > think we should come up with a more idiomatic way to run things.
> > >
> > > Agree. Given the discussions we've been having recently about bridging
> > > the RSpec/Test::Unit gap, we should have a single command that can
> > > field stories, specs and tests.
> > >
> > > >
> > > > 2) I stumbled across .story files. Because of the special file
> > > > extension my initial hunch was that these are special files that the
> > > > behaviour runner knows how to parse and "execute". Then I realised
> > > > this is not the case. So I assume it's just leftovers, in which case I
> > > > think it should be moved to a different directory (docs?), given a new
> > > > file extension or deleted altogether. Same goes for the stores.txt
> > > > file.
> > > >
> > > > 3) The file structure feels a little unusual. For example, it's common
> > > > practice to have foo.rb as a sibling to the foo/ directory, but the
> > > > stories.rb file is a child, not a sibling. Further, there is no lib
> > > > folder for the code. Small things, but we should fix it. I think the
> > > > best is to move the game of life up under trunk or at least make it a
> > > > sibling of examples, not a child.
> > >
> > > +1 for cleaning this up. Not sure about where the example should go. I
> > > think it's going to take some playing around for us to figure out how
> > > projects should be structured now that we've got the two tool sets
> > > merged. In the game-of-life example, we've got:
> > >
> > > project/behaviour/examples
> > > project/behaviour/stories
> > >
> > > I like that, though we still need to get the name right for what we've
> > > called specs and examples. Thinking about how this stuff works
> > > together, one idea is:
> > >
> > > project/behaviour/objects
> > > project/behaviour/stories
> >
> > I assume that is for a gem/regular ruby app. I like that structure.
> >
> > But what would the structure be in a Rails app?
> >
> > project/behaviour/models
> > project/behaviour/controllers
> > project/behaviour/views
> > project/behaviour/helpers
> > project/behaviour/objects # this is for lib - following same naming
> > convention as for "gems"
> > project/behaviour/stories
>
> For me, models, controllers, views, and helpers roll up under objects.

I agree, but I don't want to have RAILS_ROOT/behaviour/objects/models
- because that's too deep...

Aslak

> There's always two levels of examples: story and everything else - I'm
> saying everything else is objects, but it could be something else.
> How's that for clarification?
>
> > ?
> > >
> > > I kind of like that, but I'm not sold. Thoughts?
> > >
> >
> > It's good enough for me, but I'm cheap
> >
> > Aslak
> >
> > > David
> > >
> > > >
> > > > Let me know what you think,
> > > >
> > > > Aslak
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Tue Aug 28 14:47:42 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 28 Aug 2007 13:47:42 -0500
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <8d961d900708281140y9f3b44epfa9b29b67788e704@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
	<8d961d900708281118v674afd89i40a62ab1bf249073@mail.gmail.com>
	<57c63afe0708281125v415b7896r174dd4e0358014c4@mail.gmail.com>
	<8d961d900708281140y9f3b44epfa9b29b67788e704@mail.gmail.com>
Message-ID: <57c63afe0708281147k30dabfe5odecf6a578b42c2c4@mail.gmail.com>

On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > On 8/28/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > > First of all, big kudos to Dan and David for making RBehave part of
> > > > > RSpec. This kicks ass.
> > > >
> > > > Mostly Dan - I just helped when he got stuck.
> > > >
> > > > > I'm finally taking a closer look at the new story runner and the
> > > > > examples. These are my observations as a newcomer. I'm not complaining
> > > > > - just pointing out things I think should be fixed - before I go ahead
> > > > > and fix some of it myself:
> > > > >
> > > > > 1) It was hard to figure out how to run the game of life example.
> > > > > First I looked for a Rake task and found none. Then I looked for
> > > > > instructions in a README and found none.
> > > >
> > > > This is all stuff we need to do, but keep in mind this is not a release yet.
> > > >
> > > > > Then I went online and David
> > > > > told me I had to run the everything.rb file. That works ok, but I
> > > > > think we should come up with a more idiomatic way to run things.
> > > >
> > > > Agree. Given the discussions we've been having recently about bridging
> > > > the RSpec/Test::Unit gap, we should have a single command that can
> > > > field stories, specs and tests.
> > > >
> > > > >
> > > > > 2) I stumbled across .story files. Because of the special file
> > > > > extension my initial hunch was that these are special files that the
> > > > > behaviour runner knows how to parse and "execute". Then I realised
> > > > > this is not the case. So I assume it's just leftovers, in which case I
> > > > > think it should be moved to a different directory (docs?), given a new
> > > > > file extension or deleted altogether. Same goes for the stores.txt
> > > > > file.
> > > > >
> > > > > 3) The file structure feels a little unusual. For example, it's common
> > > > > practice to have foo.rb as a sibling to the foo/ directory, but the
> > > > > stories.rb file is a child, not a sibling. Further, there is no lib
> > > > > folder for the code. Small things, but we should fix it. I think the
> > > > > best is to move the game of life up under trunk or at least make it a
> > > > > sibling of examples, not a child.
> > > >
> > > > +1 for cleaning this up. Not sure about where the example should go. I
> > > > think it's going to take some playing around for us to figure out how
> > > > projects should be structured now that we've got the two tool sets
> > > > merged. In the game-of-life example, we've got:
> > > >
> > > > project/behaviour/examples
> > > > project/behaviour/stories
> > > >
> > > > I like that, though we still need to get the name right for what we've
> > > > called specs and examples. Thinking about how this stuff works
> > > > together, one idea is:
> > > >
> > > > project/behaviour/objects
> > > > project/behaviour/stories
> > >
> > > I assume that is for a gem/regular ruby app. I like that structure.
> > >
> > > But what would the structure be in a Rails app?
> > >
> > > project/behaviour/models
> > > project/behaviour/controllers
> > > project/behaviour/views
> > > project/behaviour/helpers
> > > project/behaviour/objects # this is for lib - following same naming
> > > convention as for "gems"
> > > project/behaviour/stories
> >
> > For me, models, controllers, views, and helpers roll up under objects.
>
> I agree, but I don't want to have RAILS_ROOT/behaviour/objects/models
> - because that's too deep...

I agree, though then we should abandon the name objects in this case:

project/behaviour/controllers
project/behaviour/helpers
project/behaviour/lib
project/behaviour/models
project/behaviour/stories
project/behaviour/views

I think that's a bit confusing. It also doesn't map well w/ the rails
structure because it implies everything is at one level, but models
are below app, while lib is at the root. And then the stories
directory becomes confusing as well - it doesn't map to anything
specific in the app. So maybe we should do something like:

project/behaviour/controllers
project/behaviour/helpers
project/behaviour/lib
project/behaviour/models
project/behaviour/views

project/stories

WDYT?

>
> Aslak
>
> > There's always two levels of examples: story and everything else - I'm
> > saying everything else is objects, but it could be something else.
> > How's that for clarification?
> >
> > > ?
> > > >
> > > > I kind of like that, but I'm not sold. Thoughts?
> > > >
> > >
> > > It's good enough for me, but I'm cheap
> > >
> > > Aslak
> > >
> > > > David
> > > >
> > > > >
> > > > > Let me know what you think,
> > > > >
> > > > > Aslak
> > > > > _______________________________________________
> > > > > rspec-devel mailing list
> > > > > rspec-devel at rubyforge.org
> > > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > > >
> > > > _______________________________________________
> > > > rspec-devel mailing list
> > > > rspec-devel at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > 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 28 14:54:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 14:54:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-12722 ] the alternate file command
	does not work in rails views due to scope
Message-ID: <20070828185415.379355240C1E@rubyforge.org>

Patches item #12722, was opened at 2007-07-31 16:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797

Category: RSpec.tmbundle
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Carl Porth (badcarl)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: the alternate file command does not work in rails views due to scope

Initial Comment:
Here is a tiny patch to add the text.html.ruby scope to the Alternate File comand so it works in rails views.

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-28 14:54

Message:
Fixed in r2476

----------------------------------------------------------------------

Comment By: Carl Porth (badcarl)
Date: 2007-08-27 16:30

Message:
More specifically: when in an .html.erb suffixed view, the Alternate File 
command only works when your caret is in an erb tag (due to scope).  The patch 
adds scope so the command works wherever the caret happens to be in the 
view file.


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=12722&group_id=797

From undees at gmail.com  Tue Aug 28 14:56:35 2007
From: undees at gmail.com (Ian Dees)
Date: Tue, 28 Aug 2007 11:56:35 -0700
Subject: [rspec-devel] Game of Life questions
Message-ID: <ad4f9af90708281156u2ac1121ev99358d8390ed3afa@mail.gmail.com>

What a coincidence!  It was this very morning that I took the plunge
and switched from my stock 1.0.8 install to a gem built from Dan's
branch, and I had some of the exact same questions.

> > > > 1) It was hard to figure out how to run the game of life example.
> > > > First I looked for a Rake task and found none. Then I looked for
> > > > instructions in a README and found none.

I stumbled here, too, trying to figure out how to run my own story
file.  I spent a little while playing with spec's -U option and
StoryRunner before realizing that the right way is just to use plain
ol' ruby and require 'spec/story' in my story file.

> > > This is all stuff we need to do, but keep in mind this is not a release yet.

Want me to take a first stab at a really short README for the RBehave
examples?  (Finally, something I might be semi-qualified to do for the
story effort!  ;-)

> > > Agree. Given the discussions we've been having recently about bridging
> > > the RSpec/Test::Unit gap, we should have a single command that can
> > > field stories, specs and tests.

As a RSpec user, I'd say either a "bin/spec" that runs stories without
needing too many flags/options, or a separate "bin/story" would feel
fine.

> > > project/behaviour/objects
> > > project/behaviour/stories

So if I understand correctly, "objects" is the catch-all for things
that aren't models, views, or controllers.  What about for non-Rails
apps?  When I have my GUI testing hat on, "stories" and "examples"
seem clearer than "stories" and "objects."

--Ian

From dchelimsky at gmail.com  Tue Aug 28 15:08:02 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 28 Aug 2007 14:08:02 -0500
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <ad4f9af90708281156u2ac1121ev99358d8390ed3afa@mail.gmail.com>
References: <ad4f9af90708281156u2ac1121ev99358d8390ed3afa@mail.gmail.com>
Message-ID: <57c63afe0708281208y44276b05j51833a71f724371@mail.gmail.com>

On 8/28/07, Ian Dees <undees at gmail.com> wrote:
> What a coincidence!  It was this very morning that I took the plunge
> and switched from my stock 1.0.8 install to a gem built from Dan's
> branch, and I had some of the exact same questions.

That's merged into trunk now, so feel free to work from there.

> > > > > 1) It was hard to figure out how to run the game of life example.
> > > > > First I looked for a Rake task and found none. Then I looked for
> > > > > instructions in a README and found none.
>
> I stumbled here, too, trying to figure out how to run my own story
> file.  I spent a little while playing with spec's -U option and
> StoryRunner before realizing that the right way is just to use plain
> ol' ruby and require 'spec/story' in my story file.
>
> > > > This is all stuff we need to do, but keep in mind this is not a release yet.
>
> Want me to take a first stab at a really short README for the RBehave
> examples?  (Finally, something I might be semi-qualified to do for the
> story effort!  ;-)

Let's get this part of the lingo straight: we're talking about the
Story Runner, not RBehave (even though it's the story runner from
RBehave).

By all means, please do up some docs. Thanks!

>
> > > > Agree. Given the discussions we've been having recently about bridging
> > > > the RSpec/Test::Unit gap, we should have a single command that can
> > > > field stories, specs and tests.
>
> As a RSpec user, I'd say either a "bin/spec" that runs stories without
> needing too many flags/options, or a separate "bin/story" would feel
> fine.

How about bin/behave that knows how to deal w/ everything spec does
already PLUS stories. So, given:

project/lib
project/behaviour/stories
project/behaviour/not_stories ('objects' may be the wrong name here -
we need something that means 'everything else besides stories')

>behave behaviour
=> runs everything
>behave behaviour/stories
=> runs stories
>behave behaviour/not_stories (or objects, specs, examples, etc)
=> runs object-level examples

>
> > > > project/behaviour/objects
> > > > project/behaviour/stories
>
> So if I understand correctly, "objects" is the catch-all for things
> that aren't models, views, or controllers.

No, no, no. Little be it known there IS a world of ruby outside rails.
'objects' is everything besides stories. We just need a good name for
it.

> What about for non-Rails
> apps?  When I have my GUI testing hat on, "stories" and "examples"
> seem clearer than "stories" and "objects."

I agree that 'objects' is the wrong name, but 'examples' doesn't
really work either when sitting next to 'stories' because Stories are
Examples too. So what are the examples examples of? I'm not saying I
have a better name - I'm really struggling w/ this - but we need to
land on a name that makes sense alongside 'stories'.

Cheers,
David

>
> --Ian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Tue Aug 28 15:10:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 15:10:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13274 ] ThrowSymbol recognized a
	NameError triggered by Kernel#method_missing as a thrown Symbol
Message-ID: <20070828191057.F3F6E5240B70@rubyforge.org>

Patches item #13274, was opened at 2007-08-22 06:10
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13274&group_id=797

Category: expectation module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jay Phillips (jicksta)
>Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: ThrowSymbol recognized a NameError triggered by Kernel#method_missing as a thrown Symbol

Initial Comment:
Without my patch, the following spec fails:

#############################################################
describe ThrowSymbol, "(constructed with a Symbol)" do
  
  before(:each) { @matcher = ThrowSymbol.new(:sym) }
  
  it "should only match NameErrors raised by uncaught throws" do
    @matcher.matches?(lambda{ sym }).should be_false
  end
  
end
#############################################################

Though nothing is throw()n here, it still finds a thrown symbol by taking the NameError raised from the sym method that didn't exist and calling name.to_sym on it.

The problem existed in the matches?() method of ThrowSymbol. Since an uncaught throw() returns a NameError, normal name errors were being caught as well as a thrown symbol. In the example above, "sym" gets raised as a NameError (like a throw() does) assigned to variable "e" and e.name.to_sym evaluates to :sym. Since this NameError isn't a thrown Symbol, it should not match a *normal* NameError.

Attached is my patch for this issue.

Thanks,

Jay Phillips



----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-28 15:10

Message:
Applied in r2477 (minor changes)

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-22 11:11

Message:
It was Wendy's

----------------------------------------------------------------------

Comment By: Jay Phillips (jicksta)
Date: 2007-08-22 07:33

Message:
Pesky checkbox!

Patch uploaded. Sorry.  :)

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-22 07:30

Message:
Anybody remember those commercials for McDonalds or Burger King in the 80s w/ this elderly woman opening up a sandwich and asking "where's the beef?"?

Where's the patch?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13274&group_id=797

From michael.s.klishin.lists at gmail.com  Tue Aug 28 15:12:25 2007
From: michael.s.klishin.lists at gmail.com (Michael Klishin)
Date: Tue, 28 Aug 2007 23:12:25 +0400
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
Message-ID: <46D47399.6020405@gmail.com>

Hooray.

Given the fact we are on dev list could Dan or you David explain what is 
the best way to get up and running with current implementation of RBehave?

I hope many of us eager to try it out and submit something that looks 
like documentation ;)

Thanks.

David Chelimsky wrote:

>> 1) It was hard to figure out how to run the game of life example.
>> First I looked for a Rake task and found none. Then I looked for
>> instructions in a README and found none.
> 
> This is all stuff we need to do, but keep in mind this is not a release yet.

--
MK

From noreply at rubyforge.org  Tue Aug 28 15:14:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 15:14:22 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13461 ] spec_ui ScreenshotFormatter
	selenium examples don't work
Message-ID: <20070828191422.884B85240C6E@rubyforge.org>

Bugs item #13461, was opened at 2007-08-28 11:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: spec_ui ScreenshotFormatter selenium examples don't work

Initial Comment:
The selenium examples in rspec/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb
don't work anymore since the upgrade to 1.0.8

Stacktrace:

NoMethodError in 'Google's search page I should find rspec's home page when I search for rspec'
undefined method `take_screenshot_of' for nil:NilClass
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb:21:
/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb:18:

This is due to the fact that Spec::Ui::ScreenshotFormatter is now a Singleton and should be initialized.

I have attached a patch which adds the initialization of Spec::Ui::ScreenshotFormatter:

Spec::Ui::ScreenshotFormatter.new(File.dirname(__FILE__) + '/../specs.html')

 in the before :all of spec_helper because it seemed like a logical place.

Since this bug happens in the examples, I haven't written any spec. However, I can write some if necessary.

I am not using Watir since I am on Ubuntu but I guess there is the same problem.

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-28 15:14

Message:
Where's the patch? Don't forget to check the checkbox. For the future, please submit patches against the patches tracker - we  keep a closer eye on that than bugs.

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-28 11:56

Message:
The patch is the for
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb
and has been generated with netbeans 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

From michael.s.klishin.lists at gmail.com  Tue Aug 28 15:25:39 2007
From: michael.s.klishin.lists at gmail.com (Michael Klishin)
Date: Tue, 28 Aug 2007 23:25:39 +0400
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <ad4f9af90708281156u2ac1121ev99358d8390ed3afa@mail.gmail.com>
References: <ad4f9af90708281156u2ac1121ev99358d8390ed3afa@mail.gmail.com>
Message-ID: <46D476B3.1080208@gmail.com>

+1, and /script/spec for Rails applications.

Ian Dees wrote:

> As a RSpec user, I'd say either a "bin/spec" that runs stories without
> needing too many flags/options, or a separate "bin/story" would feel
> fine.

--
MK

From ivey at gweezlebur.com  Tue Aug 28 14:57:20 2007
From: ivey at gweezlebur.com (Michael D. Ivey)
Date: Tue, 28 Aug 2007 13:57:20 -0500
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <57c63afe0708281147k30dabfe5odecf6a578b42c2c4@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
	<8d961d900708281118v674afd89i40a62ab1bf249073@mail.gmail.com>
	<57c63afe0708281125v415b7896r174dd4e0358014c4@mail.gmail.com>
	<8d961d900708281140y9f3b44epfa9b29b67788e704@mail.gmail.com>
	<57c63afe0708281147k30dabfe5odecf6a578b42c2c4@mail.gmail.com>
Message-ID: <557BED59-DF34-4FBB-B4E4-5D890DB62806@gweezlebur.com>

On Aug 28, 2007, at 1:47 PM, David Chelimsky wrote:
> project/behaviour/controllers
> project/behaviour/helpers
> project/behaviour/lib
> project/behaviour/models
> project/behaviour/views
>
> project/stories

I love the emphasis on stories by putting it in the top level.

From undees at gmail.com  Tue Aug 28 15:51:07 2007
From: undees at gmail.com (Ian Dees)
Date: Tue, 28 Aug 2007 12:51:07 -0700
Subject: [rspec-devel] Game of Life questions
Message-ID: <ad4f9af90708281251n1f8f093bmd4778e6e1ef3e2df@mail.gmail.com>

Quoth Dave et al:

> That's merged into trunk now, so feel free to work from there.

That's good news!  Will do.

> > Want me to take a first stab at a really short README for the RBehave
> > examples?  (Finally, something I might be semi-qualified to do for the
> > story effort!  ;-)
>
> Let's get this part of the lingo straight: we're talking about the
> Story Runner, not RBehave (even though it's the story runner from
> RBehave).

I think my head just exploded.  ;-)

Indeed, the intended sense of "README for the RBehave examples" above
was "how to run these Story thingies from RSpec."  And it's in that
spirit that I'll submit a patch.

But since we're talking about it now, what's the difference between
RBehave and RSpec+StoryRunner?  I thought the projects were
merging....

> How about bin/behave that knows how to deal w/ everything spec does
> already PLUS stories.

That'd be fine by me.  I really don't have strong feelings over
whether one "spec" executable, or one "spec" and one "behave" is
better, just so long as there's _some_ executable to get the job done.
 (I do love the idea of instructing my software to behave, though!)

> So, given:
> ....
I read through that whole description of directory layouts
half-expecting a When and a Then clause.  Guess I'm infected....

> I agree that 'objects' is the wrong name, but 'examples' doesn't
> really work either when sitting next to 'stories' because Stories are
> Examples too.

My two cents is that the connotation of Stories and Examples are
different enough that those names could stand as they are.  When
someone tells me, "Lemme give you an example of what I'm talking
about," I know he's going to dash off a couple of sentences, and then
I can be on my way.  On the other hand, when I hear, "Let me tell you
a story," I know I'm gonna be there for a while.

But YMMV....

--Ian

From dchelimsky at gmail.com  Tue Aug 28 16:11:23 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 28 Aug 2007 15:11:23 -0500
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <ad4f9af90708281251n1f8f093bmd4778e6e1ef3e2df@mail.gmail.com>
References: <ad4f9af90708281251n1f8f093bmd4778e6e1ef3e2df@mail.gmail.com>
Message-ID: <57c63afe0708281311s2033a99cof396fb5aa8ce6563@mail.gmail.com>

On 8/28/07, Ian Dees <undees at gmail.com> wrote:
> Quoth Dave et al:
>
> > That's merged into trunk now, so feel free to work from there.
>
> That's good news!  Will do.
>
> > > Want me to take a first stab at a really short README for the RBehave
> > > examples?  (Finally, something I might be semi-qualified to do for the
> > > story effort!  ;-)
> >
> > Let's get this part of the lingo straight: we're talking about the
> > Story Runner, not RBehave (even though it's the story runner from
> > RBehave).
>
> I think my head just exploded.  ;-)
>
> Indeed, the intended sense of "README for the RBehave examples" above
> was "how to run these Story thingies from RSpec."  And it's in that
> spirit that I'll submit a patch.
>
> But since we're talking about it now, what's the difference between
> RBehave and RSpec+StoryRunner?  I thought the projects were
> merging....

When's the last time you saw a merger that ended up with one company
with two names? In reality, they are buy-outs :) In this case, rspec
just bought out rbehave - not because one is more or less important
than the other, but because one has more public awareness and users
than the other. Simple.

>
> > How about bin/behave that knows how to deal w/ everything spec does
> > already PLUS stories.
>
> That'd be fine by me.  I really don't have strong feelings over
> whether one "spec" executable, or one "spec" and one "behave" is
> better, just so long as there's _some_ executable to get the job done.
>  (I do love the idea of instructing my software to behave, though!)
>
> > So, given:
> > ....
> I read through that whole description of directory layouts
> half-expecting a When and a Then clause.  Guess I'm infected....
>
> > I agree that 'objects' is the wrong name, but 'examples' doesn't
> > really work either when sitting next to 'stories' because Stories are
> > Examples too.
>
> My two cents is that the connotation of Stories and Examples are
> different enough that those names could stand as they are.  When
> someone tells me, "Lemme give you an example of what I'm talking
> about," I know he's going to dash off a couple of sentences, and then
> I can be on my way.  On the other hand, when I hear, "Let me tell you
> a story," I know I'm gonna be there for a while.

Actually, that's the first time anybody put forth an argument for that
which actually makes sense to me!

+1 for stories/examples

>
> But YMMV....
>
> --Ian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Tue Aug 28 16:24:27 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 28 Aug 2007 22:24:27 +0200
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <57c63afe0708281311s2033a99cof396fb5aa8ce6563@mail.gmail.com>
References: <ad4f9af90708281251n1f8f093bmd4778e6e1ef3e2df@mail.gmail.com>
	<57c63afe0708281311s2033a99cof396fb5aa8ce6563@mail.gmail.com>
Message-ID: <8d961d900708281324i594fcab6nb2bccf9c4f4af59a@mail.gmail.com>

On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/28/07, Ian Dees <undees at gmail.com> wrote:
> > Quoth Dave et al:
> >
> > > That's merged into trunk now, so feel free to work from there.
> >
> > That's good news!  Will do.
> >
> > > > Want me to take a first stab at a really short README for the RBehave
> > > > examples?  (Finally, something I might be semi-qualified to do for the
> > > > story effort!  ;-)
> > >
> > > Let's get this part of the lingo straight: we're talking about the
> > > Story Runner, not RBehave (even though it's the story runner from
> > > RBehave).
> >
> > I think my head just exploded.  ;-)
> >
> > Indeed, the intended sense of "README for the RBehave examples" above
> > was "how to run these Story thingies from RSpec."  And it's in that
> > spirit that I'll submit a patch.
> >
> > But since we're talking about it now, what's the difference between
> > RBehave and RSpec+StoryRunner?  I thought the projects were
> > merging....
>
> When's the last time you saw a merger that ended up with one company
> with two names? In reality, they are buy-outs :) In this case, rspec
> just bought out rbehave - not because one is more or less important
> than the other, but because one has more public awareness and users
> than the other. Simple.
>
> >
> > > How about bin/behave that knows how to deal w/ everything spec does
> > > already PLUS stories.
> >
> > That'd be fine by me.  I really don't have strong feelings over
> > whether one "spec" executable, or one "spec" and one "behave" is
> > better, just so long as there's _some_ executable to get the job done.
> >  (I do love the idea of instructing my software to behave, though!)
> >
> > > So, given:
> > > ....
> > I read through that whole description of directory layouts
> > half-expecting a When and a Then clause.  Guess I'm infected....
> >
> > > I agree that 'objects' is the wrong name, but 'examples' doesn't
> > > really work either when sitting next to 'stories' because Stories are
> > > Examples too.
> >
> > My two cents is that the connotation of Stories and Examples are
> > different enough that those names could stand as they are.  When
> > someone tells me, "Lemme give you an example of what I'm talking
> > about," I know he's going to dash off a couple of sentences, and then
> > I can be on my way.  On the other hand, when I hear, "Let me tell you
> > a story," I know I'm gonna be there for a while.
>
> Actually, that's the first time anybody put forth an argument for that
> which actually makes sense to me!
>
> +1 for stories/examples

Hear hear!

+1

Aslak

>
> >
> > But YMMV....
> >
> > --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 noreply at rubyforge.org  Tue Aug 28 16:28:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 16:28:51 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g.
	xit)
Message-ID: <20070828202852.08D1B5240BC8@rubyforge.org>

Feature Requests item #13454, was opened at 2007-08-28 08:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.

----------------------------------------------------------------------

>Comment By: Dan North (tastapod)
Date: 2007-08-28 21:28

Message:
David said: "I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing."

The problem is, it doesn't keep it on the radar. I've found literally tens of tests commented out (or x-ed out) in a codebase, which once they were re-enabled all failed because the code no longer did what it was supposed to.

The intent behind pending() is to keep them on the radar, nagging away with every build, but without actually failing the build. You can put a pending in a describe (specify) block and it should Just Work (ie. mark the whole section and any of its examples as pending). If not this is a bug.

I'd like to challenge two of the comments in the original description. Firstly pending is exactly intended to temporarily disable examples or scenarios - that's the point! Secondly, it isn't a convention from xunit, it's a convention from jbehave - the java bdd framework - that I introduced because I didn't like the binary nature of red/green (I guess I wanted yellow!). Pending behaviour is very much a BDD initiative, although it's made its way back into the xunit world (nunit has it as an Ignore attribute on a Test).

Then I brought it into rbehave because I found it so useful - and because scenarios tend to spend longer in a "pending" state than code-level examples. Then one of the rspec devs (I think it was Brian) brought it into rspec and improved it by allowing it to wrap a block.

I would strongly encourage using pending() for exactly this use case. Ideally with a message saying what needs to be done to make it work.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 18:06

Message:
For me, RSpec is all about process. So even though I was originally resistant to this, the more I think about it the more I can see using it. I comment specs out all the time in practice and I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing.

I say go for it - but the docs should be very specific about intent (i.e. recommend that xit should not be committed).

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-28 17:04

Message:
Just playing devil's advocate here, but couldn't you accomplish the same by just pasting "; pending 'x'" at the end of the "it" line, like this?

describe Foo
  it 'should be baz' do; pending 'x'
    @foo.should == 'baz'
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

From noreply at rubyforge.org  Tue Aug 28 16:40:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 16:40:53 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g.
	xit)
Message-ID: <20070828204053.EB4DC5240BAB@rubyforge.org>

Feature Requests item #13454, was opened at 2007-08-28 07:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 20:40

Message:
Maybe I misunderstood the goal here. My thinking is that xit is a shortcut for pending - it should work exactly like pending does, providing its own message - so that it does keep it on the radar. I agree w/ Brian's goal of being able to swiftly switch the state of each "it" by preceding it w/ an 'x', but only if it makes sure you know about it.

----------------------------------------------------------------------

Comment By: Dan North (tastapod)
Date: 2007-08-28 20:28

Message:
David said: "I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing."

The problem is, it doesn't keep it on the radar. I've found literally tens of tests commented out (or x-ed out) in a codebase, which once they were re-enabled all failed because the code no longer did what it was supposed to.

The intent behind pending() is to keep them on the radar, nagging away with every build, but without actually failing the build. You can put a pending in a describe (specify) block and it should Just Work (ie. mark the whole section and any of its examples as pending). If not this is a bug.

I'd like to challenge two of the comments in the original description. Firstly pending is exactly intended to temporarily disable examples or scenarios - that's the point! Secondly, it isn't a convention from xunit, it's a convention from jbehave - the java bdd framework - that I introduced because I didn't like the binary nature of red/green (I guess I wanted yellow!). Pending behaviour is very much a BDD initiative, although it's made its way back into the xunit world (nunit has it as an Ignore attribute on a Test).

Then I brought it into rbehave because I found it so useful - and because scenarios tend to spend longer in a "pending" state than code-level examples. Then one of the rspec devs (I think it was Brian) brought it into rspec and improved it by allowing it to wrap a block.

I would strongly encourage using pending() for exactly this use case. Ideally with a message saying what needs to be done to make it work.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 17:06

Message:
For me, RSpec is all about process. So even though I was originally resistant to this, the more I think about it the more I can see using it. I comment specs out all the time in practice and I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing.

I say go for it - but the docs should be very specific about intent (i.e. recommend that xit should not be committed).

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-28 16:04

Message:
Just playing devil's advocate here, but couldn't you accomplish the same by just pasting "; pending 'x'" at the end of the "it" line, like this?

describe Foo
  it 'should be baz' do; pending 'x'
    @foo.should == 'baz'
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

From dan at tastapod.com  Tue Aug 28 16:46:26 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 28 Aug 2007 21:46:26 +0100
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
Message-ID: <46D489A2.1000005@tastapod.com>

aslak hellesoy wrote:
> First of all, big kudos to Dan and David for making RBehave part of
> RSpec. This kicks ass.
>   
Thanks. It's been a busy few days :)
> I'm finally taking a closer look at the new story runner and the
> examples. These are my observations as a newcomer. I'm not complaining
> - just pointing out things I think should be fixed - before I go ahead
> and fix some of it myself:
>   
Please do - it's a bit of a mess right now.
> 1) It was hard to figure out how to run the game of life example.
> First I looked for a Rake task and found none. Then I looked for
> instructions in a README and found none. Then I went online and David
> told me I had to run the everything.rb file. That works ok, but I
> think we should come up with a more idiomatic way to run things.
>   
The story runner adds itself as an at_exit hook when you define your 
first Story, so you should be able to just run it using rspec. (In fact 
the game-of-life runs during the full build because it runs all the 
example code - as I discovered when it didn't work!)

require 'spec/story' should be all you need.

To run game-of-life in situ you should be able to run any of the files 
under the behaviour directory. everything.rb just includes, um, everything.
> 2) I stumbled across .story files. Because of the special file
> extension my initial hunch was that these are special files that the
> behaviour runner knows how to parse and "execute". Then I realised
> this is not the case. So I assume it's just leftovers, in which case I
> think it should be moved to a different directory (docs?), given a new
> file extension or deleted altogether. Same goes for the stores.txt
> file.
>   
Nope, no magic! They're just dumb text files. Feel free to rename, 
consolidate, remove, translate into Norwegian ;)
> 3) The file structure feels a little unusual. For example, it's common
> practice to have foo.rb as a sibling to the foo/ directory, but the
> stories.rb file is a child, not a sibling. Further, there is no lib
> folder for the code. Small things, but we should fix it. I think the
> best is to move the game of life up under trunk or at least make it a
> sibling of examples, not a child.
>   
So, the game-of-life was my proof-of-concept project to drive out the 
behaviour for rbehave. It's just there as an example. Yesterday someone 
who runs a coding dojo sent me an rspec/rbehave-driven poker app he 
produced at a coding dojo. It's really nice because it shows the split 
between story-level and code-level behaviour. I'll add it into the 
examples once we decide how best to lay them out.
> Let me know what you think,
>
> Aslak
>   
Great observations Aslak. We definitely need to tidy up the example and 
get some docs together ahead of a release.

Cheers,
Dan

From dchelimsky at gmail.com  Tue Aug 28 16:53:55 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 28 Aug 2007 15:53:55 -0500
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <46D489A2.1000005@tastapod.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<46D489A2.1000005@tastapod.com>
Message-ID: <57c63afe0708281353r7ad6e069s7350f8943daafa7b@mail.gmail.com>

On 8/28/07, Dan North <dan at tastapod.com> wrote:
> It's really nice because it shows the split
> between story-level and code-level behaviour.

HAZAAAAAAAAH

behaviour/stories
behaviour/code

Any takers?

From dan at tastapod.com  Tue Aug 28 17:13:52 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 28 Aug 2007 22:13:52 +0100
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
Message-ID: <46D49010.8030901@tastapod.com>

David Chelimsky wrote:
> This is all stuff we need to do, but keep in mind this is not a release yet.
>   
What David said :)
> Agree. Given the discussions we've been having recently about bridging
> the RSpec/Test::Unit gap, we should have a single command that can
> field stories, specs and tests.
>   
Spec::Story uses the same Config as the core runner, and loads itself on 
demand, so it should all Just Work (subject to a few outstanding tasks 
that I'll post on a separate thread).
> +1 for cleaning this up. Not sure about where the example should go. I
> think it's going to take some playing around for us to figure out how
> projects should be structured now that we've got the two tool sets
> merged. In the game-of-life example, we've got:
> [snip]
>
> project/behaviour/objects
> project/behaviour/stories
>
> I kind of like that, but I'm not sold. Thoughts?
>   
I've been struggling to articulate this recently, and then suddenly 
someone made a throwaway comment that made a little lightbulb go on.

BDD works at two levels: stories and objecty-stuff. We're stuck for a 
word for objecty-stuff.

Let's turn the question round. Who is the /audience/ for each of these 
levels of description?  In other words, who cares about the words? For 
stories and scenarios, it's a user (or tester or analyst). They care 
about the /stories/ (or /features/). They don't care what it's made of. 
If you can deliver their web app using hamsters and string, that's fine 
by them - it's a black box that "does stuff".

The current rspec core is aimed at developers. They care about the 
/code/. It's all behaviour, but at the higher level it's examples of 
what the /application/ does, and at the lower level it's examples of 
what the /code/ does. So I propose something like this:

*project/behaviour/code*    [contains examples at the code level for 
developers]
*project/behaviour/stories* [contains examples at the story level for 
testers/analysts]

Objects is only one aspect of the code-level behaviour, and it 
underplays how powerful those code-level descriptions can be. They are 
more often descriptions of interactions /between/ objects, so the 
interactions themselves become the first-class citizens. The objects are 
just there to represent domain concepts. Plus when you get on to 
describing behaviour of mixins or meta-programming, "objects" just 
doesn't do it justice. But it is all code, and it is all interesting to 
the developers.

(I'll respond to the rails layout discussion inline in the thread.)

Whatever we decide - and I'm not particularly wedded to "stories" as 
opposed to "application", say, we need to stay focused on who the 
audience is for the vocabulary - that's the only way we're going to get 
the words right.

I hope that makes sense.

Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070828/15e0fe02/attachment.html 

From dan at tastapod.com  Tue Aug 28 17:24:19 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 28 Aug 2007 22:24:19 +0100
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <557BED59-DF34-4FBB-B4E4-5D890DB62806@gweezlebur.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>	<8d961d900708281118v674afd89i40a62ab1bf249073@mail.gmail.com>	<57c63afe0708281125v415b7896r174dd4e0358014c4@mail.gmail.com>	<8d961d900708281140y9f3b44epfa9b29b67788e704@mail.gmail.com>	<57c63afe0708281147k30dabfe5odecf6a578b42c2c4@mail.gmail.com>
	<557BED59-DF34-4FBB-B4E4-5D890DB62806@gweezlebur.com>
Message-ID: <46D49283.3060408@tastapod.com>

Michael D. Ivey wrote:
> On Aug 28, 2007, at 1:47 PM, David Chelimsky wrote:
>   
>> project/behaviour/controllers
>> project/behaviour/helpers
>> project/behaviour/lib
>> project/behaviour/models
>> project/behaviour/views
>>
>> project/stories
>>     
>
> I love the emphasis on stories by putting it in the top level.
>   
Me too. Following my previous mail (I hope it's turned up by now!) I 
would propose something like this:

*project/behaviour
    - code
        - controllers
        - models
        - helpers*    [yuk - do we really have to encourage this 
antipattern? :) ]
*        - other*      [other behaviour that isn't part of the rails mvc 
world]
*    - stories*        [application level behaviour]

Cheers,
Dan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070828/8422b2e9/attachment.html 

From aslak.hellesoy at gmail.com  Tue Aug 28 17:25:44 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 28 Aug 2007 23:25:44 +0200
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <57c63afe0708281353r7ad6e069s7350f8943daafa7b@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<46D489A2.1000005@tastapod.com>
	<57c63afe0708281353r7ad6e069s7350f8943daafa7b@mail.gmail.com>
Message-ID: <8d961d900708281425j4697dd0aoe3e370c984f4e88d@mail.gmail.com>

On 8/28/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/28/07, Dan North <dan at tastapod.com> wrote:
> > It's really nice because it shows the split
> > between story-level and code-level behaviour.
>
> HAZAAAAAAAAH
>
> behaviour/stories
> behaviour/code
>

Hmmm. I think it will lead to nomenclature confusion again. Too many
words: (behaviour+story+example+code). In order to reduce the number
of words I suggest:

GEM:
ROOT/lib
ROOT/stories # RBehave stuff
ROOT/examples # Classic RSpec stuff

RAILS:
ROOT/app
ROOT/lib
ROOT/stories # RBehave stuff
ROOT/examples # Classic RSpec stuff
ROOT/examples/models
ROOT/examples/controllers
ROOT/examples/views
ROOT/examples/helpers
ROOT/examples/lib

This makes the directory convention more similar between gems and
rails, and we only have "stories and examples" (not behaviour, code
and specs). Less is more.

A
> Any takers?
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dan at tastapod.com  Tue Aug 28 17:28:51 2007
From: dan at tastapod.com (Dan North)
Date: Tue, 28 Aug 2007 22:28:51 +0100
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <46D47399.6020405@gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>	<57c63afe0708281105v408d48f6u63e161db48ba2b55@mail.gmail.com>
	<46D47399.6020405@gmail.com>
Message-ID: <46D49393.3020700@tastapod.com>

Hi Michael.

The example I wrote up at 
http://dannorth.net/2007/06/introducing-rbehave will work exactly as-is 
with Spec::Story.

The only difference is that now you require 'spec/story' rather than 
'rbehave'.

Having written a story/scenarios, you can just run them (and any 
code-level examples you want to include) with the regular rspec 
command-line runner.

It's a bit of a cheat at the moment - spec::story only has one kind of 
output, which is plain text (specdoc-ish) - so it lies :)

Take a read of that example and let me know how you get on.

Cheers,
Dan

Michael Klishin wrote:
> Hooray.
>
> Given the fact we are on dev list could Dan or you David explain what is 
> the best way to get up and running with current implementation of RBehave?
>
> I hope many of us eager to try it out and submit something that looks 
> like documentation ;)
>
> Thanks.
>
> David Chelimsky wrote:
>
>   
>>> 1) It was hard to figure out how to run the game of life example.
>>> First I looked for a Rake task and found none. Then I looked for
>>> instructions in a README and found none.
>>>       
>> This is all stuff we need to do, but keep in mind this is not a release yet.
>>     
>
> --
> MK
> _______________________________________________
> 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/20070828/cd4ada49/attachment.html 

From rupert_apsc at rupespad.com  Tue Aug 28 17:44:26 2007
From: rupert_apsc at rupespad.com (rupert)
Date: Tue, 28 Aug 2007 22:44:26 +0100
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <8d961d900708281425j4697dd0aoe3e370c984f4e88d@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<46D489A2.1000005@tastapod.com>
	<57c63afe0708281353r7ad6e069s7350f8943daafa7b@mail.gmail.com>
	<8d961d900708281425j4697dd0aoe3e370c984f4e88d@mail.gmail.com>
Message-ID: <E9B236C4-0671-4C8E-A26B-7D62E647FFE0@rupespad.com>


On 28 Aug 2007, at 22:25, aslak hellesoy wrote:
> GEM:
> ROOT/lib
> ROOT/stories # RBehave stuff
> ROOT/examples # Classic RSpec stuff
>
> RAILS:
> ROOT/app
> ROOT/lib
> ROOT/stories # RBehave stuff
> ROOT/examples # Classic RSpec stuff
> ROOT/examples/models
> ROOT/examples/controllers
> ROOT/examples/views
> ROOT/examples/helpers
> ROOT/examples/lib

How about implementation(s) instead of examples, as it contains the  
specs that show how the stories have been implemented.  Examples to  
me sounds more like a 'this is how it might be done' rather than a  
'this is how it has been done'.

Cheers

Rupert



From noreply at rubyforge.org  Tue Aug 28 20:34:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 20:34:50 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-11919 ] Making non-implemented specs
	easy in textmate
Message-ID: <20070829003450.454155240E3E@rubyforge.org>

Patches item #11919, was opened at 2007-06-29 09:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11919&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: Making non-implemented specs easy in textmate

Initial Comment:

Small modification to the 'it' textmate snippet.  The third tab trigger will allow the removal of the block, so that one can list a series of it "should ..." specifications, one after another.  

Two things:
1. I'm not exactly sure if anyone finds this useful, so please reject it if it isn't.
2. I couldn't figure out if this thing has specs to go along with it, and exactly how to add it to subversion, so I've attached the full bundle.

----------------------------------------------------------------------

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-29 00:34

Message:
I heard Brian Takita talk about this on the mailing list. 
What is it's origins, and why does it appeal to you?  xit
sounds like "exit."  Do you like that for the reason that
the spec is "exited" - i.e., not implemented?

Personally, I like the tab trigger as the option after your
write the spec.  I've attached a little screencast to show
how it could be used to rapidly spec out some functionality:

http://railsnewbie.com/files/pending_textmate.mov
 

----------------------------------------------------------------------

Comment By: James Deville (parcelbrat)
Date: 2007-08-28 05:58

Message:
I've usually added a xit snippet which gives a pending spec. Anyone else like that idea?



----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 13:56

Message:
Disregard the last diff.  I figured out how to do it via.
subversion's diff.

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 13:41

Message:
No, actually I did check the checkbox, but for whatever
reason it wouldn't upload.  The svn diff also didn't
work...I had to do it manually.  Here is the diff of the
"it" snippet (I'll also attach it)

6c6
<       <string>it "${2:should ${1:description}}" ${3:do
---
>       <string>it "${2:should ${1:description}}" do
8c8
< end}</string>
---
> end</string>


----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-29 09:57

Message:
You forgot to check the attachment checkbox.
Can you attach a diff instead so I can see what you have changed? (Just svn add it locally before doing svn diff).


----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 09:46

Message:
the bundle...

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11919&group_id=797

From noreply at rubyforge.org  Tue Aug 28 23:51:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 28 Aug 2007 23:51:34 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13020 ]
	ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
	should not be included in helper specs?
Message-ID: <20070829035134.D00AE5240CF0@rubyforge.org>

Bugs item #13020, was opened at 2007-08-13 02:39
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13020&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Mike Vincent (agile)
Assigned to: Nobody (None)
Summary: ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods should not be included in helper specs?

Initial Comment:
1.0.6+ includes additional modules into the helper specs. 

including ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods

causes conflicts in helpers as it redefines several methods, such as << 

def simple_example(name)
  markup = ''
  markup << content_tag(:h1, "hello #{name}")
  markup
end

simple_example('foo').should have_tag('h1', 'foo')


will throw a confusing method missing error from nil about the << method.








----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 03:51

Message:
Yes Jay - fixed w/ 13065.

Cheers,
David

----------------------------------------------------------------------

Comment By: Jay Levitt (jaylev)
Date: 2007-08-28 14:30

Message:
I -think- this is fixed by http://rubyforge.org/tracker/?func=detail&group_id=797&aid=13065&atid=3149 instead.  Right?

----------------------------------------------------------------------

Comment By: Ryan Bates (ryanb)
Date: 2007-08-21 18:54

Message:
+1

I had this problem which led to a lot of confusion since the error message is not very helpful. Commenting out the include statement fixed it, although it makes me wonder if I'm breaking something else by doing this. Why are the generator methods included in the first place?

At least my specs are passing again...

----------------------------------------------------------------------

Comment By: Mike Vincent (agile)
Date: 2007-08-21 01:26

Message:
I think maybe I wasn't clear in the original message. I
don't believe the GeneratorMethods module is intended to be
mixed into the helper context and breaks things while it is
included. 

Not much clearer, I know. Someday me speak gooder.

Index:
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
===================================================================
---
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
       (revision 2411)
+++
vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/helper.rb
       (working copy)
@@ -32,7 +32,7 @@
           include ActionView::Helpers::NumberHelper
           include ActionView::Helpers::PaginationHelper
rescue nil #removed after 1.2.3
           include ActionView::Helpers::PrototypeHelper
-          include
ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
+          #include
ActionView::Helpers::PrototypeHelper::JavaScriptGenerator::GeneratorMethods
           include ActionView::Helpers::ScriptaculousHelper
           include ActionView::Helpers::TagHelper
           include ActionView::Helpers::TextHelper


----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13020&group_id=797

From noreply at rubyforge.org  Wed Aug 29 00:42:07 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 00:42:07 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-11919 ] Making non-implemented specs
	easy in textmate
Message-ID: <20070829044208.2B19F5240FBA@rubyforge.org>

Patches item #11919, was opened at 2007-06-29 09:43
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11919&group_id=797

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Making non-implemented specs easy in textmate

Initial Comment:

Small modification to the 'it' textmate snippet.  The third tab trigger will allow the removal of the block, so that one can list a series of it "should ..." specifications, one after another.  

Two things:
1. I'm not exactly sure if anyone finds this useful, so please reject it if it isn't.
2. I couldn't figure out if this thing has specs to go along with it, and exactly how to add it to subversion, so I've attached the full bundle.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 04:42

Message:
applied: r2478

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-29 00:34

Message:
I heard Brian Takita talk about this on the mailing list. 
What is it's origins, and why does it appeal to you?  xit
sounds like "exit."  Do you like that for the reason that
the spec is "exited" - i.e., not implemented?

Personally, I like the tab trigger as the option after your
write the spec.  I've attached a little screencast to show
how it could be used to rapidly spec out some functionality:

http://railsnewbie.com/files/pending_textmate.mov
 

----------------------------------------------------------------------

Comment By: James Deville (parcelbrat)
Date: 2007-08-28 05:58

Message:
I've usually added a xit snippet which gives a pending spec. Anyone else like that idea?



----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 13:56

Message:
Disregard the last diff.  I figured out how to do it via.
subversion's diff.

----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 13:41

Message:
No, actually I did check the checkbox, but for whatever
reason it wouldn't upload.  The svn diff also didn't
work...I had to do it manually.  Here is the diff of the
"it" snippet (I'll also attach it)

6c6
<       <string>it "${2:should ${1:description}}" ${3:do
---
>       <string>it "${2:should ${1:description}}" do
8c8
< end}</string>
---
> end</string>


----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-06-29 09:57

Message:
You forgot to check the attachment checkbox.
Can you attach a diff instead so I can see what you have changed? (Just svn add it locally before doing svn diff).


----------------------------------------------------------------------

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-06-29 09:46

Message:
the bundle...

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=11919&group_id=797

From dchelimsky at gmail.com  Wed Aug 29 02:13:19 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 29 Aug 2007 01:13:19 -0500
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
Message-ID: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>

Take a look at this (cr|h)ack:

http://pastie.caboo.se/91971

It works!

There are some bugs, but it is actually interacting w/ the story
runner, matchers and rails!

From aslak.hellesoy at gmail.com  Wed Aug 29 02:36:38 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 29 Aug 2007 08:36:38 +0200
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
Message-ID: <8d961d900708282336y298d273cl6aaf9f0613da1971@mail.gmail.com>

On 8/29/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> Take a look at this (cr|h)ack:
>
> http://pastie.caboo.se/91971
>
> It works!
>
> There are some bugs, but it is actually interacting w/ the story
> runner, matchers and rails!

Finally!!

> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Aug 29 09:42:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 09:42:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared
	Behaviours
Message-ID: <20070829134219.BC1975240AB5@rubyforge.org>

Feature Requests item #13487, was opened at 2007-08-29 13:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Parameterize Shared Behaviours

Initial Comment:
There has been discussion of parameterized shared behaviours, but t

The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic:

describe "a RESTful controller", :shared => true do
  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  before(:each) do
    @model_class = Foo
  end
  it_should_behave_like "a RESTful controller"
end

The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. 

I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this:

#DOES NOT EXIST YET
describe "a RESTful controller" do |model_class|
  it "should find all instances of the resource" do
    model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  #DOES NOT EXIST YET
  it_should_behave_like "a RESTful controller", Foo
end

We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share.

Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash:

  it_should_behave_like "a RESTful controller", :model_class => Foo

But that starts to get ugly pretty quickly as well.

Thoughts?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

From dchelimsky at gmail.com  Wed Aug 29 09:50:27 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 29 Aug 2007 08:50:27 -0500
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <8d961d900708282336y298d273cl6aaf9f0613da1971@mail.gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<8d961d900708282336y298d273cl6aaf9f0613da1971@mail.gmail.com>
Message-ID: <57c63afe0708290650l48f23d72p284b1f86f33f2053@mail.gmail.com>

On 8/29/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/29/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > Take a look at this (cr|h)ack:
> >
> > http://pastie.caboo.se/91971
> >
> > It works!
> >
> > There are some bugs, but it is actually interacting w/ the story
> > runner, matchers and rails!
>
> Finally!!

Brian cleaned that up a bit - check out just the stuff in #helper.rb:
http://pastie.caboo.se/91968

I've done up a bunch of these in a project I'm working on and it works
great except that it doesn't honor the configuration args. As soon as
we get that working and can do transactional stories, I think we can
release it.

>
> > _______________________________________________
> > 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  Wed Aug 29 10:03:41 2007
From: yrashk at gmail.com (Yurii Rashkovskii)
Date: Wed, 29 Aug 2007 17:03:41 +0300
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <57c63afe0708290650l48f23d72p284b1f86f33f2053@mail.gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<8d961d900708282336y298d273cl6aaf9f0613da1971@mail.gmail.com>
	<57c63afe0708290650l48f23d72p284b1f86f33f2053@mail.gmail.com>
Message-ID: <9991A1AB-B2B9-4DE2-95DD-D5854B191BF4@gmail.com>

David,

here is a quick-hack support for transactional stories:

http://pastie.caboo.se/92051

On Aug 29, 2007, at 4:50 PM, David Chelimsky wrote:

> On 8/29/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>> On 8/29/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>>> Take a look at this (cr|h)ack:
>>>
>>> http://pastie.caboo.se/91971
>>>
>>> It works!
>>>
>>> There are some bugs, but it is actually interacting w/ the story
>>> runner, matchers and rails!
>>
>> Finally!!
>
> Brian cleaned that up a bit - check out just the stuff in #helper.rb:
> http://pastie.caboo.se/91968
>
> I've done up a bunch of these in a project I'm working on and it works
> great except that it doesn't honor the configuration args. As soon as
> we get that working and can do transactional stories, I think we can
> release it.
>
>>
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From noreply at rubyforge.org  Wed Aug 29 10:05:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 10:05:22 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13451 ] Add a null_object option to
	mock_model
Message-ID: <20070829140522.E245AA97001B@rubyforge.org>

Patches item #13451, was opened at 2007-08-28 06:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13451&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: James Deville (parcelbrat)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Add a null_object option to mock_model

Initial Comment:
RSpec's (now old) mocking framework allows a :null_object => true. However, the mock_model method does not. This patch allows you to pass in a :null_object => true along with your other stubs, to get a null_object. 

I have found this very useful in controller tests, so that I don't have to add extra un-needed stubs to my setup block every time my controller's action changes.




----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 14:05

Message:
Applied to r2479

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3151&aid=13451&group_id=797

From dchelimsky at gmail.com  Wed Aug 29 10:09:08 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 29 Aug 2007 09:09:08 -0500
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <9991A1AB-B2B9-4DE2-95DD-D5854B191BF4@gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<8d961d900708282336y298d273cl6aaf9f0613da1971@mail.gmail.com>
	<57c63afe0708290650l48f23d72p284b1f86f33f2053@mail.gmail.com>
	<9991A1AB-B2B9-4DE2-95DD-D5854B191BF4@gmail.com>
Message-ID: <57c63afe0708290709r5b97efaagf337b9ba70ef596c@mail.gmail.com>

On 8/29/07, Yurii Rashkovskii <yrashk at gmail.com> wrote:
> David,
>
> here is a quick-hack support for transactional stories:

Thanks Yurii - but I think we want to do the same thing in Story
Runner that we do in what is now called Behaviour Runner - simply call
setup on the TestCase - that allows the user to configure
transactional or non-transactional.

So I don't think we'll add that to RSpec, but I DO think I'll be using
it on my project in the mean time (I ALWAYS want transactional
fixtures :) )

Cheers,
David

>
> http://pastie.caboo.se/92051
>
> On Aug 29, 2007, at 4:50 PM, David Chelimsky wrote:
>
> > On 8/29/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> >> On 8/29/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >>> Take a look at this (cr|h)ack:
> >>>
> >>> http://pastie.caboo.se/91971
> >>>
> >>> It works!
> >>>
> >>> There are some bugs, but it is actually interacting w/ the story
> >>> runner, matchers and rails!
> >>
> >> Finally!!
> >
> > Brian cleaned that up a bit - check out just the stuff in #helper.rb:
> > http://pastie.caboo.se/91968
> >
> > I've done up a bunch of these in a project I'm working on and it works
> > great except that it doesn't honor the configuration args. As soon as
> > we get that working and can do transactional stories, I think we can
> > release it.
> >
> >>
> >>> _______________________________________________
> >>> rspec-devel mailing list
> >>> rspec-devel at rubyforge.org
> >>> http://rubyforge.org/mailman/listinfo/rspec-devel
> >>>
> >> _______________________________________________
> >> rspec-devel mailing list
> >> rspec-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-devel
> >>
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Aug 29 10:35:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 10:35:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared
	Behaviours
Message-ID: <20070829143515.532C55240AED@rubyforge.org>

Feature Requests item #13487, was opened at 2007-08-29 13:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Parameterize Shared Behaviours

Initial Comment:
There has been discussion of parameterized shared behaviours, but t

The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic:

describe "a RESTful controller", :shared => true do
  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  before(:each) do
    @model_class = Foo
  end
  it_should_behave_like "a RESTful controller"
end

The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. 

I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this:

#DOES NOT EXIST YET
describe "a RESTful controller" do |model_class|
  it "should find all instances of the resource" do
    model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  #DOES NOT EXIST YET
  it_should_behave_like "a RESTful controller", Foo
end

We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share.

Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash:

  it_should_behave_like "a RESTful controller", :model_class => Foo

But that starts to get ugly pretty quickly as well.

Thoughts?

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 14:35

Message:
Using a hash looks ugly but arguably is more natural and provides maximum flexibility, particularly in a situation where one has a healthy set of default options and wants to tweak individual values as necessary:

 describe FooController do
   it_should_behave_like "a RESTful controller", options.merge { :model_class => Foo }
 end

Of course, if you do it with block args then this is already available to the user as a special case!

The idea of getting rid of :shared => true in the presence of describe block args is really cool.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

From noreply at rubyforge.org  Wed Aug 29 10:44:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 10:44:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared
	Behaviours
Message-ID: <20070829144410.DD7805240A89@rubyforge.org>

Feature Requests item #13487, was opened at 2007-08-29 13:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Parameterize Shared Behaviours

Initial Comment:
There has been discussion of parameterized shared behaviours, but t

The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic:

describe "a RESTful controller", :shared => true do
  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  before(:each) do
    @model_class = Foo
  end
  it_should_behave_like "a RESTful controller"
end

The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. 

I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this:

#DOES NOT EXIST YET
describe "a RESTful controller" do |model_class|
  it "should find all instances of the resource" do
    model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  #DOES NOT EXIST YET
  it_should_behave_like "a RESTful controller", Foo
end

We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share.

Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash:

  it_should_behave_like "a RESTful controller", :model_class => Foo

But that starts to get ugly pretty quickly as well.

Thoughts?

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 14:44

Message:
This functionality would presumably be used in the presence of inheritance (or mixins etc) in the code being specified, so it'd be nice to support something that behaves like spec inheritance, e.g. the ability to extend or override individual shared behaviors, but it's hard to see how that could work. It's certainly easier to demand that shared behaviors be kept fine-grained enough to be mixed-and-matched as required.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 14:35

Message:
Using a hash looks ugly but arguably is more natural and provides maximum flexibility, particularly in a situation where one has a healthy set of default options and wants to tweak individual values as necessary:

 describe FooController do
   it_should_behave_like "a RESTful controller", options.merge { :model_class => Foo }
 end

Of course, if you do it with block args then this is already available to the user as a special case!

The idea of getting rid of :shared => true in the presence of describe block args is really cool.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

From noreply at rubyforge.org  Wed Aug 29 11:49:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 11:49:46 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13461 ] spec_ui ScreenshotFormatter
	selenium examples don't work
Message-ID: <20070829154946.6E89EA970016@rubyforge.org>

Bugs item #13461, was opened at 2007-08-28 17:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: spec_ui ScreenshotFormatter selenium examples don't work

Initial Comment:
The selenium examples in rspec/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb
don't work anymore since the upgrade to 1.0.8

Stacktrace:

NoMethodError in 'Google's search page I should find rspec's home page when I search for rspec'
undefined method `take_screenshot_of' for nil:NilClass
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb:21:
/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb:18:

This is due to the fact that Spec::Ui::ScreenshotFormatter is now a Singleton and should be initialized.

I have attached a patch which adds the initialization of Spec::Ui::ScreenshotFormatter:

Spec::Ui::ScreenshotFormatter.new(File.dirname(__FILE__) + '/../specs.html')

 in the before :all of spec_helper because it seemed like a logical place.

Since this bug happens in the examples, I haven't written any spec. However, I can write some if necessary.

I am not using Watir since I am on Ubuntu but I guess there is the same problem.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-28 21:14

Message:
Where's the patch? Don't forget to check the checkbox. For the future, please submit patches against the patches tracker - we  keep a closer eye on that than bugs.

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-28 17:56

Message:
The patch is the for
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb
and has been generated with netbeans 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

From noreply at rubyforge.org  Wed Aug 29 11:51:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 11:51:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13461 ] spec_ui ScreenshotFormatter
	selenium examples don't work
Message-ID: <20070829155118.B508B5240A6F@rubyforge.org>

Bugs item #13461, was opened at 2007-08-28 17:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: spec_ui ScreenshotFormatter selenium examples don't work

Initial Comment:
The selenium examples in rspec/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb
don't work anymore since the upgrade to 1.0.8

Stacktrace:

NoMethodError in 'Google's search page I should find rspec's home page when I search for rspec'
undefined method `take_screenshot_of' for nil:NilClass
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb:21:
/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb:18:

This is due to the fact that Spec::Ui::ScreenshotFormatter is now a Singleton and should be initialized.

I have attached a patch which adds the initialization of Spec::Ui::ScreenshotFormatter:

Spec::Ui::ScreenshotFormatter.new(File.dirname(__FILE__) + '/../specs.html')

 in the before :all of spec_helper because it seemed like a logical place.

Since this bug happens in the examples, I haven't written any spec. However, I can write some if necessary.

I am not using Watir since I am on Ubuntu but I guess there is the same problem.

----------------------------------------------------------------------

>Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-29 17:51

Message:
Sorry Asla, I did read the instructions
(http://rspec.rubyforge.org/community/contribute.html) but I
forgot the checkbox ;-)

I am going to submit a couple of patch for spec_ui selenium
today.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-28 21:14

Message:
Where's the patch? Don't forget to check the checkbox. For the future, please submit patches against the patches tracker - we  keep a closer eye on that than bugs.

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-28 17:56

Message:
The patch is the for
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb
and has been generated with netbeans 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

From noreply at rubyforge.org  Wed Aug 29 12:50:55 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 12:50:55 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13492 ] Support
	parameterized Examples ala TestNG's DataProvider
Message-ID: <20070829165055.6DE5CA97001B@rubyforge.org>

Feature Requests item #13492, was opened at 2007-08-29 10:50
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13492&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Bob Cotton (bcotton)
Assigned to: Nobody (None)
Summary: Support parameterized Examples ala TestNG's DataProvider

Initial Comment:
In response to http://rubyforge.org//tracker/index.php?func=detail&aid=13487&group_id=797&atid=3152

While you're thinking of parameterizing things, I was thinking about how to introduce TestNG's concept of data providers. See http://debasishg.blogspot.com/2007/05/parameterizing-test-methods-revisited.html for a discussion.

If the block passed to an Example could be parameterized it might look like this:

it "should be parameterized", :data_provider => my_data_provider_method do |arg1, arg2| 
end

Then the example would be called once each time #my_data_provider_method didn't return nil.


Thoughts?

- Bob

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13492&group_id=797

From noreply at rubyforge.org  Wed Aug 29 13:20:15 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 13:20:15 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13461 ] spec_ui ScreenshotFormatter
	selenium examples don't work
Message-ID: <20070829172015.B0FF85240A6F@rubyforge.org>

Bugs item #13461, was opened at 2007-08-28 17:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: spec_ui ScreenshotFormatter selenium examples don't work

Initial Comment:
The selenium examples in rspec/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb
don't work anymore since the upgrade to 1.0.8

Stacktrace:

NoMethodError in 'Google's search page I should find rspec's home page when I search for rspec'
undefined method `take_screenshot_of' for nil:NilClass
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb:21:
/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb:18:

This is due to the fact that Spec::Ui::ScreenshotFormatter is now a Singleton and should be initialized.

I have attached a patch which adds the initialization of Spec::Ui::ScreenshotFormatter:

Spec::Ui::ScreenshotFormatter.new(File.dirname(__FILE__) + '/../specs.html')

 in the before :all of spec_helper because it seemed like a logical place.

Since this bug happens in the examples, I haven't written any spec. However, I can write some if necessary.

I am not using Watir since I am on Ubuntu but I guess there is the same problem.

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-29 17:51

Message:
Sorry Asla, I did read the instructions
(http://rspec.rubyforge.org/community/contribute.html) but I
forgot the checkbox ;-)

I am going to submit a couple of patch for spec_ui selenium
today.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-28 21:14

Message:
Where's the patch? Don't forget to check the checkbox. For the future, please submit patches against the patches tracker - we  keep a closer eye on that than bugs.

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-28 17:56

Message:
The patch is the for
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb
and has been generated with netbeans 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

From noreply at rubyforge.org  Wed Aug 29 13:23:21 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 13:23:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13461 ] spec_ui ScreenshotFormatter
	selenium examples don't work
Message-ID: <20070829172321.03B76A97001B@rubyforge.org>

Bugs item #13461, was opened at 2007-08-28 17:34
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jean-Michel Garnier (garnierjm)
Assigned to: Nobody (None)
Summary: spec_ui ScreenshotFormatter selenium examples don't work

Initial Comment:
The selenium examples in rspec/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb
don't work anymore since the upgrade to 1.0.8

Stacktrace:

NoMethodError in 'Google's search page I should find rspec's home page when I search for rspec'
undefined method `take_screenshot_of' for nil:NilClass
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb:21:
/spec_ui/examples/selenium/spec/selenium/find_rspecs_homepage_spec.rb:18:

This is due to the fact that Spec::Ui::ScreenshotFormatter is now a Singleton and should be initialized.

I have attached a patch which adds the initialization of Spec::Ui::ScreenshotFormatter:

Spec::Ui::ScreenshotFormatter.new(File.dirname(__FILE__) + '/../specs.html')

 in the before :all of spec_helper because it seemed like a logical place.

Since this bug happens in the examples, I haven't written any spec. However, I can write some if necessary.

I am not using Watir since I am on Ubuntu but I guess there is the same problem.

----------------------------------------------------------------------

>Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-29 19:23

Message:
Sorry AslaK, with a k.

Please ignore the first patch, I had made a stupid mistake :-(

Reading at the code it doesn't look very simple, why not
replacing the initialization by a simple call or by a
default value (with documentation) so it's transparent for
the user

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-29 17:51

Message:
Sorry Asla, I did read the instructions
(http://rspec.rubyforge.org/community/contribute.html) but I
forgot the checkbox ;-)

I am going to submit a couple of patch for spec_ui selenium
today.

----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-28 21:14

Message:
Where's the patch? Don't forget to check the checkbox. For the future, please submit patches against the patches tracker - we  keep a closer eye on that than bugs.

----------------------------------------------------------------------

Comment By: Jean-Michel Garnier (garnierjm)
Date: 2007-08-28 17:56

Message:
The patch is the for
/spec_ui/examples/selenium/spec/selenium/../spec_helper.rb
and has been generated with netbeans 

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13461&group_id=797

From mailing_lists at railsnewbie.com  Wed Aug 29 13:34:40 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 29 Aug 2007 13:34:40 -0400
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
Message-ID: <11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>


On Aug 29, 2007, at 2:13 AM, David Chelimsky wrote:

> Take a look at this (cr|h)ack:
>
> http://pastie.caboo.se/91971
>
> It works!

This is absolutely great!  I just wonder - how is everything going to  
be mixed in (i.e. views, models + controllers)?

Currently I'm working on a project which needs some high level  
functional tests (read: regressions).  Would the rbehave merge be a  
good candidate for this?

Scott


From noreply at rubyforge.org  Wed Aug 29 14:45:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 14:45:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13493 ] routing shortcuts no longer work
	in helper specs (in rspec v1.0.8)
Message-ID: <20070829184510.BF156A97001B@rubyforge.org>

Bugs item #13493, was opened at 2007-08-29 13:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13493&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Stephens (viking415)
Assigned to: Nobody (None)
Summary: routing shortcuts no longer work in helper specs (in rspec v1.0.8)

Initial Comment:
In my helper I have code that calls some *_path methods that are created using resources in my routes config file.  I upgraded rspec from 1.0.5 to 1.0.8., and when I run my helper specs, I get this error:

You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<                                                             
./config/../app/helpers/memberships_helper.rb:8:in `link_to_index'
./spec/helpers/memberships_helper_spec.rb:18:
script/spec:15:

Upon further investigation I found that my call to 'memberships_path' in the helper I'm testing first goes to Spec::Matchers#method_missing, and then to ActionView::Helpers::PrototypeHelper::JavascriptGenerator::GeneratorMethods#method_missing, where it throws the error.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13493&group_id=797

From noreply at rubyforge.org  Wed Aug 29 15:03:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 15:03:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13493 ] routing shortcuts no longer work
	in helper specs (in rspec v1.0.8)
Message-ID: <20070829190305.73C2BA97001D@rubyforge.org>

Bugs item #13493, was opened at 2007-08-29 13:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13493&group_id=797

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Stephens (viking415)
Assigned to: Nobody (None)
Summary: routing shortcuts no longer work in helper specs (in rspec v1.0.8)

Initial Comment:
In my helper I have code that calls some *_path methods that are created using resources in my routes config file.  I upgraded rspec from 1.0.5 to 1.0.8., and when I run my helper specs, I get this error:

You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<                                                             
./config/../app/helpers/memberships_helper.rb:8:in `link_to_index'
./spec/helpers/memberships_helper_spec.rb:18:
script/spec:15:

Upon further investigation I found that my call to 'memberships_path' in the helper I'm testing first goes to Spec::Matchers#method_missing, and then to ActionView::Helpers::PrototypeHelper::JavascriptGenerator::GeneratorMethods#method_missing, where it throws the error.

----------------------------------------------------------------------

>Comment By: Jeremy Stephens (viking415)
Date: 2007-08-29 14:03

Message:
Just to make sure I generated two fresh rails installs, one
with rspec 1.0.5 and the other with 1.0.8, and I generated
rspec_scaffold for each.  I created a simple method in the
helper that did this:

def foo
  bars_path
end

I wrote a test for it, and it passed in the 1.0.5 version,
but failed in the 1.0.8 version with the error I mentioned
in the original post.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13493&group_id=797

From dchelimsky at gmail.com  Wed Aug 29 15:04:54 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 29 Aug 2007 14:04:54 -0500
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
Message-ID: <57c63afe0708291204t312794fdt5d2fb67f69fb7dd3@mail.gmail.com>

On 8/29/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> On Aug 29, 2007, at 2:13 AM, David Chelimsky wrote:
>
> > Take a look at this (cr|h)ack:
> >
> > http://pastie.caboo.se/91971
> >
> > It works!
>
> This is absolutely great!  I just wonder - how is everything going to
> be mixed in (i.e. views, models + controllers)?
>
> Currently I'm working on a project which needs some high level
> functional tests (read: regressions).  Would the rbehave merge be a
> good candidate for this?

There is no plan for that. The idea is that the story runner is for
stories (high level functional) and the example runner is for
individual objects (like controllers and views).

>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Aug 29 15:07:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 15:07:30 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13493 ] routing shortcuts no longer work
	in helper specs (in rspec v1.0.8)
Message-ID: <20070829190731.15C04A970029@rubyforge.org>

Bugs item #13493, was opened at 2007-08-29 18:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13493&group_id=797

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Jeremy Stephens (viking415)
Assigned to: Nobody (None)
Summary: routing shortcuts no longer work in helper specs (in rspec v1.0.8)

Initial Comment:
In my helper I have code that calls some *_path methods that are created using resources in my routes config file.  I upgraded rspec from 1.0.5 to 1.0.8., and when I run my helper specs, I get this error:

You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<                                                             
./config/../app/helpers/memberships_helper.rb:8:in `link_to_index'
./spec/helpers/memberships_helper_spec.rb:18:
script/spec:15:

Upon further investigation I found that my call to 'memberships_path' in the helper I'm testing first goes to Spec::Matchers#method_missing, and then to ActionView::Helpers::PrototypeHelper::JavascriptGenerator::GeneratorMethods#method_missing, where it throws the error.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 19:07

Message:
This is already fixed in trunk:

http://rubyforge.org/tracker/?group_id=797&atid=3149&func=detail&aid=13065

----------------------------------------------------------------------

Comment By: Jeremy Stephens (viking415)
Date: 2007-08-29 19:03

Message:
Just to make sure I generated two fresh rails installs, one
with rspec 1.0.5 and the other with 1.0.8, and I generated
rspec_scaffold for each.  I created a simple method in the
helper that did this:

def foo
  bars_path
end

I wrote a test for it, and it passed in the 1.0.5 version,
but failed in the 1.0.8 version with the error I mentioned
in the original post.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13493&group_id=797

From mailing_lists at railsnewbie.com  Wed Aug 29 15:09:57 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 29 Aug 2007 15:09:57 -0400
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <57c63afe0708291204t312794fdt5d2fb67f69fb7dd3@mail.gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
	<57c63afe0708291204t312794fdt5d2fb67f69fb7dd3@mail.gmail.com>
Message-ID: <E7E681F4-F6EE-4F91-8960-7E8E4EC05CC5@railsnewbie.com>


On Aug 29, 2007, at 3:04 PM, David Chelimsky wrote:

> On 8/29/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>
>> On Aug 29, 2007, at 2:13 AM, David Chelimsky wrote:
>>
>>> Take a look at this (cr|h)ack:
>>>
>>> http://pastie.caboo.se/91971
>>>
>>> It works!
>>
>> This is absolutely great!  I just wonder - how is everything going to
>> be mixed in (i.e. views, models + controllers)?
>>
>> Currently I'm working on a project which needs some high level
>> functional tests (read: regressions).  Would the rbehave merge be a
>> good candidate for this?
>
> There is no plan for that. The idea is that the story runner is for
> stories (high level functional) and the example runner is for
> individual objects (like controllers and views).


Gotcha.  Just out of curiosity - what is your normal method for  
regressions on rails app when given a bug report?  Do you usually  
write the regression on the controller first, or on the models?  Or  
do you write an integration tests in Test::Unit?

Scott


From pergesu at gmail.com  Wed Aug 29 15:16:23 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Wed, 29 Aug 2007 12:16:23 -0700
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <57c63afe0708291204t312794fdt5d2fb67f69fb7dd3@mail.gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
	<57c63afe0708291204t312794fdt5d2fb67f69fb7dd3@mail.gmail.com>
Message-ID: <810a540e0708291216s68804dd7y952f685598cb7d11@mail.gmail.com>

On 8/29/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/29/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >
> > On Aug 29, 2007, at 2:13 AM, David Chelimsky wrote:
> >
> > > Take a look at this (cr|h)ack:
> > >
> > > http://pastie.caboo.se/91971
> > >
> > > It works!
> >
> > This is absolutely great!  I just wonder - how is everything going to
> > be mixed in (i.e. views, models + controllers)?
> >
> > Currently I'm working on a project which needs some high level
> > functional tests (read: regressions).  Would the rbehave merge be a
> > good candidate for this?
>
> There is no plan for that. The idea is that the story runner is for
> stories (high level functional) and the example runner is for
> individual objects (like controllers and views).

This tests the full stack though, just like Rails integration tests,
right?  I'm actually not sure what the difference is between Scott's
question and your answer.  But I'm certainly missing something big.

Pat

From noreply at rubyforge.org  Wed Aug 29 15:17:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 15:17:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13493 ] routing shortcuts no longer work
	in helper specs (in rspec v1.0.8)
Message-ID: <20070829191740.28339A97001D@rubyforge.org>

Bugs item #13493, was opened at 2007-08-29 13:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13493&group_id=797

Category: rails plugin
Group: None
Status: Closed
Resolution: Out of Date
Priority: 3
Submitted By: Jeremy Stephens (viking415)
Assigned to: Nobody (None)
Summary: routing shortcuts no longer work in helper specs (in rspec v1.0.8)

Initial Comment:
In my helper I have code that calls some *_path methods that are created using resources in my routes config file.  I upgraded rspec from 1.0.5 to 1.0.8., and when I run my helper specs, I get this error:

You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.<<                                                             
./config/../app/helpers/memberships_helper.rb:8:in `link_to_index'
./spec/helpers/memberships_helper_spec.rb:18:
script/spec:15:

Upon further investigation I found that my call to 'memberships_path' in the helper I'm testing first goes to Spec::Matchers#method_missing, and then to ActionView::Helpers::PrototypeHelper::JavascriptGenerator::GeneratorMethods#method_missing, where it throws the error.

----------------------------------------------------------------------

>Comment By: Jeremy Stephens (viking415)
Date: 2007-08-29 14:17

Message:
Cool, thanks much.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 14:07

Message:
This is already fixed in trunk:

http://rubyforge.org/tracker/?group_id=797&atid=3149&func=detail&aid=13065

----------------------------------------------------------------------

Comment By: Jeremy Stephens (viking415)
Date: 2007-08-29 14:03

Message:
Just to make sure I generated two fresh rails installs, one
with rspec 1.0.5 and the other with 1.0.8, and I generated
rspec_scaffold for each.  I created a simple method in the
helper that did this:

def foo
  bars_path
end

I wrote a test for it, and it passed in the 1.0.5 version,
but failed in the 1.0.8 version with the error I mentioned
in the original post.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3149&aid=13493&group_id=797

From dchelimsky at gmail.com  Wed Aug 29 15:20:05 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 29 Aug 2007 14:20:05 -0500
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <810a540e0708291216s68804dd7y952f685598cb7d11@mail.gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
	<57c63afe0708291204t312794fdt5d2fb67f69fb7dd3@mail.gmail.com>
	<810a540e0708291216s68804dd7y952f685598cb7d11@mail.gmail.com>
Message-ID: <57c63afe0708291220h7d4973afvf43b073d4b2de193@mail.gmail.com>

On 8/29/07, Pat Maddox <pergesu at gmail.com> wrote:
> On 8/29/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/29/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> > >
> > > On Aug 29, 2007, at 2:13 AM, David Chelimsky wrote:
> > >
> > > > Take a look at this (cr|h)ack:
> > > >
> > > > http://pastie.caboo.se/91971
> > > >
> > > > It works!
> > >
> > > This is absolutely great!  I just wonder - how is everything going to
> > > be mixed in (i.e. views, models + controllers)?
> > >
> > > Currently I'm working on a project which needs some high level
> > > functional tests (read: regressions).  Would the rbehave merge be a
> > > good candidate for this?
> >
> > There is no plan for that. The idea is that the story runner is for
> > stories (high level functional) and the example runner is for
> > individual objects (like controllers and views).
>
> This tests the full stack though, just like Rails integration tests,
> right?  I'm actually not sure what the difference is between Scott's
> question and your answer.  But I'm certainly missing something big.

I misunderstood Scott's question - I thought he was looking to use
Story Runner to do object-level regression testing on controllers,
models, etc. What I'm saying is that Story Runner is not planned to
work the same way as Example Runner, which will continue to support
examples for models, views, controllers and helpers. Story Runner is
just going to wrap Rails Integration Tests. So if you want to do
regressions based on reports from Users, use Story Runner for the high
level and the Example Runner to drive the fix.

>
> Pat
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Wed Aug 29 15:22:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 15:22:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared
	Behaviours
Message-ID: <20070829192209.53419A970033@rubyforge.org>

Feature Requests item #13487, was opened at 2007-08-29 06:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Parameterize Shared Behaviours

Initial Comment:
There has been discussion of parameterized shared behaviours, but t

The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic:

describe "a RESTful controller", :shared => true do
  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  before(:each) do
    @model_class = Foo
  end
  it_should_behave_like "a RESTful controller"
end

The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. 

I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this:

#DOES NOT EXIST YET
describe "a RESTful controller" do |model_class|
  it "should find all instances of the resource" do
    model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  #DOES NOT EXIST YET
  it_should_behave_like "a RESTful controller", Foo
end

We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share.

Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash:

  it_should_behave_like "a RESTful controller", :model_class => Foo

But that starts to get ugly pretty quickly as well.

Thoughts?

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-29 12:22

Message:
+1 on letting the describe block's arity indicate shared-itude.

>From there, the test author can choose whether to put a few block parameters in a row or use a single hash parameter.

If this gets implemented, are you going to revoke shared behaviors' access to the state of the describe block where they're used?  I could see this causing confusion.  After all, shared Given/When/Then blocks definitely have access to their Scenario's state.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 07:44

Message:
This functionality would presumably be used in the presence of inheritance (or mixins etc) in the code being specified, so it'd be nice to support something that behaves like spec inheritance, e.g. the ability to extend or override individual shared behaviors, but it's hard to see how that could work. It's certainly easier to demand that shared behaviors be kept fine-grained enough to be mixed-and-matched as required.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 07:35

Message:
Using a hash looks ugly but arguably is more natural and provides maximum flexibility, particularly in a situation where one has a healthy set of default options and wants to tweak individual values as necessary:

 describe FooController do
   it_should_behave_like "a RESTful controller", options.merge { :model_class => Foo }
 end

Of course, if you do it with block args then this is already available to the user as a special case!

The idea of getting rid of :shared => true in the presence of describe block args is really cool.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

From mailing_lists at railsnewbie.com  Wed Aug 29 15:31:37 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 29 Aug 2007 15:31:37 -0400
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <57c63afe0708291220h7d4973afvf43b073d4b2de193@mail.gmail.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
	<57c63afe0708291204t312794fdt5d2fb67f69fb7dd3@mail.gmail.com>
	<810a540e0708291216s68804dd7y952f685598cb7d11@mail.gmail.com>
	<57c63afe0708291220h7d4973afvf43b073d4b2de193@mail.gmail.com>
Message-ID: <D8EC10F4-6AB5-452F-B52E-D2081CBF1503@railsnewbie.com>


On Aug 29, 2007, at 3:20 PM, David Chelimsky wrote:

> On 8/29/07, Pat Maddox <pergesu at gmail.com> wrote:
>> On 8/29/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>>> On 8/29/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>>>>
>>>> On Aug 29, 2007, at 2:13 AM, David Chelimsky wrote:
>>>>
>>>>> Take a look at this (cr|h)ack:
>>>>>
>>>>> http://pastie.caboo.se/91971
>>>>>
>>>>> It works!
>>>>
>>>> This is absolutely great!  I just wonder - how is everything  
>>>> going to
>>>> be mixed in (i.e. views, models + controllers)?
>>>>
>>>> Currently I'm working on a project which needs some high level
>>>> functional tests (read: regressions).  Would the rbehave merge be a
>>>> good candidate for this?
>>>
>>> There is no plan for that. The idea is that the story runner is for
>>> stories (high level functional) and the example runner is for
>>> individual objects (like controllers and views).
>>
>> This tests the full stack though, just like Rails integration tests,
>> right?  I'm actually not sure what the difference is between Scott's
>> question and your answer.  But I'm certainly missing something big.
>
> I misunderstood Scott's question - I thought he was looking to use
> Story Runner to do object-level regression testing on controllers,
> models, etc. What I'm saying is that Story Runner is not planned to
> work the same way as Example Runner, which will continue to support
> examples for models, views, controllers and helpers. Story Runner is
> just going to wrap Rails Integration Tests. So if you want to do
> regressions based on reports from Users, use Story Runner for the high
> level and the Example Runner to drive the fix.

Thanks to the two of you for clearing this up.  I don't know a thing  
about rails integration tests, so I'll have to look into it.

Scott



From noreply at rubyforge.org  Wed Aug 29 16:18:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 16:18:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared
	Behaviours
Message-ID: <20070829201804.E1395A970029@rubyforge.org>

Feature Requests item #13487, was opened at 2007-08-29 13:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Parameterize Shared Behaviours

Initial Comment:
There has been discussion of parameterized shared behaviours, but t

The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic:

describe "a RESTful controller", :shared => true do
  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  before(:each) do
    @model_class = Foo
  end
  it_should_behave_like "a RESTful controller"
end

The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. 

I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this:

#DOES NOT EXIST YET
describe "a RESTful controller" do |model_class|
  it "should find all instances of the resource" do
    model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  #DOES NOT EXIST YET
  it_should_behave_like "a RESTful controller", Foo
end

We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share.

Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash:

  it_should_behave_like "a RESTful controller", :model_class => Foo

But that starts to get ugly pretty quickly as well.

Thoughts?

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 20:18

Message:
I was thinking it should either be shared state or parameterized, but not both. That strikes me as the least confusing option. But I'm convincable.

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-29 19:22

Message:
+1 on letting the describe block's arity indicate shared-itude.

>From there, the test author can choose whether to put a few block parameters in a row or use a single hash parameter.

If this gets implemented, are you going to revoke shared behaviors' access to the state of the describe block where they're used?  I could see this causing confusion.  After all, shared Given/When/Then blocks definitely have access to their Scenario's state.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 14:44

Message:
This functionality would presumably be used in the presence of inheritance (or mixins etc) in the code being specified, so it'd be nice to support something that behaves like spec inheritance, e.g. the ability to extend or override individual shared behaviors, but it's hard to see how that could work. It's certainly easier to demand that shared behaviors be kept fine-grained enough to be mixed-and-matched as required.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 14:35

Message:
Using a hash looks ugly but arguably is more natural and provides maximum flexibility, particularly in a situation where one has a healthy set of default options and wants to tweak individual values as necessary:

 describe FooController do
   it_should_behave_like "a RESTful controller", options.merge { :model_class => Foo }
 end

Of course, if you do it with block args then this is already available to the user as a special case!

The idea of getting rid of :shared => true in the presence of describe block args is really cool.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

From dan at tastapod.com  Wed Aug 29 19:12:17 2007
From: dan at tastapod.com (Dan North)
Date: Thu, 30 Aug 2007 00:12:17 +0100
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
Message-ID: <46D5FD51.4070100@tastapod.com>

Hi Scott.

The story runner fits anywhere where you would traditionally have 
"functional tests" or "acceptance tests" or "integration tests", i.e. 
end-to-end, user-visible functionality that demonstrates the behaviour 
of the application. Think of it as a replacement (or supplement) for FIT.

My process for fixing a bug reported by a user or tester is usually 
something like this:

- manually try to reproduce the bug. This is the tricky bit!
- once you can reproduce it, add a new scenario in the appropriate story 
definition that says how it /should/ work (so this uses the story runner)
- now you have an automated way to prove the bug, use code-level BDD to 
drive the solution (as David suggested)

The reason I write an automated scenario to prove the bug is that the 
person who reported it - the user or tester - is thinking at the 
application level, and they are the person I want to demonstrate the fix 
to. I can "sell" them code-level examples to show I've fixed it, but 
often it won't make any sense to them. "You can log in now because the 
backing juju is setting the flibby properly - it was an off-by-one [show 
some ruby code and/or rspec output]" versus "Look, here you can see it 
logging in [watch browser doing stuff]"

If I find a bug during development, I prefer to write a new code-level 
example rather than a whole scenario, because in general it's better to 
"prove" the bug as near to the source of the problem as possible. This 
reduces the complexity and number of your behaviours (whether they are 
code examples or scenarios) and leads to a faster-running build and a 
codebase that is easier to change.

There's probably a blog post in here somewhere :)

Cheers,
Dan


Scott Taylor wrote:
> On Aug 29, 2007, at 2:13 AM, David Chelimsky wrote:
>
>   
>> Take a look at this (cr|h)ack:
>>
>> http://pastie.caboo.se/91971
>>
>> It works!
>>     
>
> This is absolutely great!  I just wonder - how is everything going to  
> be mixed in (i.e. views, models + controllers)?
>
> Currently I'm working on a project which needs some high level  
> functional tests (read: regressions).  Would the rbehave merge be a  
> good candidate for this?
>
> Scott
>
> _______________________________________________
> 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/20070830/17fd23af/attachment.html 

From noreply at rubyforge.org  Wed Aug 29 19:27:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 29 Aug 2007 19:27:46 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared
	Behaviours
Message-ID: <20070829232746.87AE35240A1D@rubyforge.org>

Feature Requests item #13487, was opened at 2007-08-29 14:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Parameterize Shared Behaviours

Initial Comment:
There has been discussion of parameterized shared behaviours, but t

The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic:

describe "a RESTful controller", :shared => true do
  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  before(:each) do
    @model_class = Foo
  end
  it_should_behave_like "a RESTful controller"
end

The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. 

I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this:

#DOES NOT EXIST YET
describe "a RESTful controller" do |model_class|
  it "should find all instances of the resource" do
    model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  #DOES NOT EXIST YET
  it_should_behave_like "a RESTful controller", Foo
end

We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share.

Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash:

  it_should_behave_like "a RESTful controller", :model_class => Foo

But that starts to get ugly pretty quickly as well.

Thoughts?

----------------------------------------------------------------------

>Comment By: Dan North (tastapod)
Date: 2007-08-30 00:27

Message:
I'm  missing something here. Can't all this shared behaviour just be achieved using mixins?

module BehavesLikeARestfulController
  # expects @model_class to be defined

  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  @model_class = Foo
  include BehavesLikeARestfulController
end

The example runner will re-initialise @model_class for each example (it-block) in the mixin because each one runs in a separate object instance.

Also, you can put before(:each) code in the module to make it self-contained, and the runner should Do The Right Thing (i.e. add it to any additional before(:each) in the specific describe block).

How does this help me? I wasn't around for the original conversations that led to :shared behaviours in the first place, so apologies if I'm going over old ground.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 21:18

Message:
I was thinking it should either be shared state or parameterized, but not both. That strikes me as the least confusing option. But I'm convincable.

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-29 20:22

Message:
+1 on letting the describe block's arity indicate shared-itude.

>From there, the test author can choose whether to put a few block parameters in a row or use a single hash parameter.

If this gets implemented, are you going to revoke shared behaviors' access to the state of the describe block where they're used?  I could see this causing confusion.  After all, shared Given/When/Then blocks definitely have access to their Scenario's state.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 15:44

Message:
This functionality would presumably be used in the presence of inheritance (or mixins etc) in the code being specified, so it'd be nice to support something that behaves like spec inheritance, e.g. the ability to extend or override individual shared behaviors, but it's hard to see how that could work. It's certainly easier to demand that shared behaviors be kept fine-grained enough to be mixed-and-matched as required.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 15:35

Message:
Using a hash looks ugly but arguably is more natural and provides maximum flexibility, particularly in a situation where one has a healthy set of default options and wants to tweak individual values as necessary:

 describe FooController do
   it_should_behave_like "a RESTful controller", options.merge { :model_class => Foo }
 end

Of course, if you do it with block args then this is already available to the user as a special case!

The idea of getting rid of :shared => true in the presence of describe block args is really cool.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

From dchelimsky at gmail.com  Thu Aug 30 00:47:30 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 29 Aug 2007 23:47:30 -0500
Subject: [rspec-devel] experimental rails story adapter in trunk
Message-ID: <57c63afe0708292147k58ab553ag68b064c3fa8d1351@mail.gmail.com>

For those of you interested in getting a jump on learning about and
using the new Story Runner in a Rails app, I've added an experimental
Rails-Story adapter to trunk.

You can see how to use it here:

http://pastie.caboo.se/92320

This is PURELY EXPERIMENTAL, however it actually works and will likely
not change much in the way that it does work.

Happy hacking!

David

From noreply at rubyforge.org  Thu Aug 30 03:33:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 03:33:49 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13487 ] Parameterize Shared
	Behaviours
Message-ID: <20070830073349.ADE345240D7E@rubyforge.org>

Feature Requests item #13487, was opened at 2007-08-29 13:42
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: Parameterize Shared Behaviours

Initial Comment:
There has been discussion of parameterized shared behaviours, but t

The current implementation of shared behaviours copies examples into the execution scope of the including behaviour. This gives the examples access to state defined in before(:each) in the including example. This works well, but does some a bit like black magic:

describe "a RESTful controller", :shared => true do
  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  before(:each) do
    @model_class = Foo
  end
  it_should_behave_like "a RESTful controller"
end

The steps in the new Story Runner (Given, When, Then) all take arguments, supporting reusable blocks. We should do the same thing with shared behaviours. 

I think that parameterizing these would be a cleaner solution, but I think it would require a separate construct (internally) than the one we have - if parameterized it should not share state with the including behaviour. But I can imagine something like this:

#DOES NOT EXIST YET
describe "a RESTful controller" do |model_class|
  it "should find all instances of the resource" do
    model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  #DOES NOT EXIST YET
  it_should_behave_like "a RESTful controller", Foo
end

We might not even need the :shared => true flag if the describe block has block args - arity > 0 could be the indicator to share.

Now this approach has it's drawbacks as well. If you end up w/ a long list of block args, you'd best get them in the right order. Sharing instance variables is its own brand of voodoo, but at least you can name them well. I guess we could add a hash:

  it_should_behave_like "a RESTful controller", :model_class => Foo

But that starts to get ugly pretty quickly as well.

Thoughts?

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-30 07:33

Message:
David: in the vaguely-analogous case of Rails partials, controller state is shared (i.e. access to the instance variables still works) even when the partial is parameterised (i.e. render :partial => ..., :locals => { ... }), so the combination of both in shared behaviours may feel familiar to Rails users at least.

----------------------------------------------------------------------

Comment By: Dan North (tastapod)
Date: 2007-08-29 23:27

Message:
I'm  missing something here. Can't all this shared behaviour just be achieved using mixins?

module BehavesLikeARestfulController
  # expects @model_class to be defined

  it "should find all instances of the resource" do
    @model_class.should_receive(:find).with(:all)
    get 'index'
  end
end

describe FooController do
  @model_class = Foo
  include BehavesLikeARestfulController
end

The example runner will re-initialise @model_class for each example (it-block) in the mixin because each one runs in a separate object instance.

Also, you can put before(:each) code in the module to make it self-contained, and the runner should Do The Right Thing (i.e. add it to any additional before(:each) in the specific describe block).

How does this help me? I wasn't around for the original conversations that led to :shared behaviours in the first place, so apologies if I'm going over old ground.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-29 20:18

Message:
I was thinking it should either be shared state or parameterized, but not both. That strikes me as the least confusing option. But I'm convincable.

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-29 19:22

Message:
+1 on letting the describe block's arity indicate shared-itude.

>From there, the test author can choose whether to put a few block parameters in a row or use a single hash parameter.

If this gets implemented, are you going to revoke shared behaviors' access to the state of the describe block where they're used?  I could see this causing confusion.  After all, shared Given/When/Then blocks definitely have access to their Scenario's state.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 14:44

Message:
This functionality would presumably be used in the presence of inheritance (or mixins etc) in the code being specified, so it'd be nice to support something that behaves like spec inheritance, e.g. the ability to extend or override individual shared behaviors, but it's hard to see how that could work. It's certainly easier to demand that shared behaviors be kept fine-grained enough to be mixed-and-matched as required.

----------------------------------------------------------------------

Comment By: Tom Stuart (tstuart)
Date: 2007-08-29 14:35

Message:
Using a hash looks ugly but arguably is more natural and provides maximum flexibility, particularly in a situation where one has a healthy set of default options and wants to tweak individual values as necessary:

 describe FooController do
   it_should_behave_like "a RESTful controller", options.merge { :model_class => Foo }
 end

Of course, if you do it with block args then this is already available to the user as a special case!

The idea of getting rid of :shared => true in the presence of describe block args is really cool.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13487&group_id=797

From mailing_lists at railsnewbie.com  Thu Aug 30 09:23:07 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Thu, 30 Aug 2007 09:23:07 -0400
Subject: [rspec-devel] first (cr|h)ack at rails integration stories
In-Reply-To: <46D5FD51.4070100@tastapod.com>
References: <57c63afe0708282313o6c89aa40idca90ae769af005e@mail.gmail.com>
	<11C26864-DAF1-43D5-9962-0DE1B406F9C0@railsnewbie.com>
	<46D5FD51.4070100@tastapod.com>
Message-ID: <4368A4E1-3184-430D-8231-6616860065C8@railsnewbie.com>


On Aug 29, 2007, at 7:12 PM, Dan North wrote:

> Hi Scott.
>
> The story runner fits anywhere where you would traditionally have  
> "functional tests" or "acceptance tests" or "integration tests",  
> i.e. end-to-end, user-visible functionality that demonstrates the  
> behaviour of the application. Think of it as a replacement (or  
> supplement) for FIT.
>
> My process for fixing a bug reported by a user or tester is usually  
> something like this:
>
> - manually try to reproduce the bug. This is the tricky bit!
> - once you can reproduce it, add a new scenario in the appropriate  
> story definition that says how it should work (so this uses the  
> story runner)
> - now you have an automated way to prove the bug, use code-level  
> BDD to drive the solution (as David suggested)
>
> The reason I write an automated scenario to prove the bug is that  
> the person who reported it - the user or tester - is thinking at  
> the application level, and they are the person I want to  
> demonstrate the fix to. I can "sell" them code-level examples to  
> show I've fixed it, but often it won't make any sense to them. "You  
> can log in now because the backing juju is setting the flibby  
> properly - it was an off-by-one [show some ruby code and/or rspec  
> output]" versus "Look, here you can see it logging in [watch  
> browser doing stuff]"

This sounds about right.  Yesterday I had a pretty good bug report  
for the social networking site that I work for it (it's a rails  
app).  I knew the general behaviour, and it went something like this:

given: user x, who has posted an item,
and user y, who has reviewed that item,

when: user x rejects the review for the item
and an admin rewards back his credit

then: user x should get back the amount of credits he spent on the  
review,
and user y should lose the amount of credits he received from  
reviewing the item + 30%

There is clearly a lot of model/database setup data here - three  
users (x, y, and the admin), an item, credits/debits, a refund  
request, and a review for a refund request.  And notice that the  
setup goes through three or four controllers (mainly to setup the  
data).  So: what's the best way to test this sort of bug report?  Is  
this still in the stage of "manually reproducing the bug"?  It seems  
like I already have a scenario (maybe two or three).

I wonder if this is the *real* place for fixtures in a rails app -  
get the setup from the fixtures, and then just test the part at the  
end - if this page is hit under this user, then these models should  
look like this - etc.

But, as it were, we ended up starting the development server,  
spending lots of time populating the development database manually,  
not finding the bug from the logs, and rinsing and repeating.  I  
finally suggested we should just use ruby-debug and step through it  
line by line, which of course isn't very popular in the rails world  
for obvious reasons (have you ever tried to step into an association?  
- what hell!).

All and all, the process took 4.5 man-hours, and after that, I  
believe we fixed the bug, but yet I don't have a test to confirm it.   
There's obviously a better way.

> If I find a bug during development, I prefer to write a new code- 
> level example rather than a whole scenario, because in general it's  
> better to "prove" the bug as near to the source of the problem as  
> possible. This reduces the complexity and number of your behaviours  
> (whether they are code examples or scenarios) and leads to a faster- 
> running build and a codebase that is easier to change.

Well - sure, if you can find something like the method which creates  
the bug (this usually occurs during test/behaviour first  
development).  I would tend to agree that the way you mentioned seems  
to be valid on any other ruby project.  But a rails project just  
seems entirely different because of how coupled every thing is.  Plus  
- you can't be sure it's a bug in your app.  Working with rails for  
the last few weeks, I've already found two bugs in it (albeit, they  
were edge cases).  I could write quite a bit about metaphor sheer  
between the typical "def" vs. "define_method" or "method_missing",  
but this email is long enough.

Thanks for your feedback.  I hope to hear more of it.

Scott





From mailing_lists at railsnewbie.com  Thu Aug 30 10:38:11 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Thu, 30 Aug 2007 10:38:11 -0400
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <8d961d900708281425j4697dd0aoe3e370c984f4e88d@mail.gmail.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<46D489A2.1000005@tastapod.com>
	<57c63afe0708281353r7ad6e069s7350f8943daafa7b@mail.gmail.com>
	<8d961d900708281425j4697dd0aoe3e370c984f4e88d@mail.gmail.com>
Message-ID: <CC4E3F5C-9DDC-4DFB-BB45-2391D0163A26@railsnewbie.com>

>
> Hmmm. I think it will lead to nomenclature confusion again. Too many
> words: (behaviour+story+example+code). In order to reduce the number
> of words I suggest:
>
> GEM:
> ROOT/lib
> ROOT/stories # RBehave stuff
> ROOT/examples # Classic RSpec stuff
>
> RAILS:
> ROOT/app
> ROOT/lib
> ROOT/stories # RBehave stuff
> ROOT/examples # Classic RSpec stuff
> ROOT/examples/models
> ROOT/examples/controllers
> ROOT/examples/views
> ROOT/examples/helpers
> ROOT/examples/lib
>
> This makes the directory convention more similar between gems and
> rails, and we only have "stories and examples" (not behaviour, code
> and specs). Less is more.

I know this thread is old, but +1 for this idea.

Also, just wanted to comment on one of Dan North's Comments:

"The current rspec core is aimed at developers. They care about the  
code. It's all behaviour, but at the higher level it's examples of  
what the application does, and at the lower level it's examples of  
what the code does."

I'm not sure if this is necessarily true on something like a rails  
project.  Writing specs/examples for a rails project can be very  
clear for the business users involved (but, it does show things on a  
more fine grained level).  You don't need to understand anything  
anything about MVC, Relational Databases, ruby, testing, etc, to  
understand the following specdoc:

User
- should validate gender for new user
- should validate education for new user
- should tell whether a user has the correct credentials
- should tell whether a user has the wrong credentials
- should be able to authenticate a valid user with the users username  
and correct password

On any other ruby project, though, I would agree with you.  Most  
spec'ing on that level is too fine grained (and doesn't mean anything  
to a business user).

Regards,

Scott



From mailing_lists at railsnewbie.com  Thu Aug 30 10:41:20 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Thu, 30 Aug 2007 10:41:20 -0400
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <E9B236C4-0671-4C8E-A26B-7D62E647FFE0@rupespad.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<46D489A2.1000005@tastapod.com>
	<57c63afe0708281353r7ad6e069s7350f8943daafa7b@mail.gmail.com>
	<8d961d900708281425j4697dd0aoe3e370c984f4e88d@mail.gmail.com>
	<E9B236C4-0671-4C8E-A26B-7D62E647FFE0@rupespad.com>
Message-ID: <3206C4CE-9C04-4206-9FC1-CA9E224CD8F5@railsnewbie.com>


On Aug 28, 2007, at 5:44 PM, rupert wrote:

>
> On 28 Aug 2007, at 22:25, aslak hellesoy wrote:
>> GEM:
>> ROOT/lib
>> ROOT/stories # RBehave stuff
>> ROOT/examples # Classic RSpec stuff
>>
>> RAILS:
>> ROOT/app
>> ROOT/lib
>> ROOT/stories # RBehave stuff
>> ROOT/examples # Classic RSpec stuff
>> ROOT/examples/models
>> ROOT/examples/controllers
>> ROOT/examples/views
>> ROOT/examples/helpers
>> ROOT/examples/lib
>
> How about implementation(s) instead of examples, as it contains the
> specs that show how the stories have been implemented.  Examples to
> me sounds more like a 'this is how it might be done' rather than a
> 'this is how it has been done'.

Examples are both a "this is how it should be done in the future",  
and "this is how it is done, now."  Isn't this why "should" won, and  
"must" lost in Rspec v 0.1 ?

Scott


From noreply at rubyforge.org  Thu Aug 30 11:56:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 11:56:59 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13453 ] disabled specs
Message-ID: <20070830155659.7F5F85240A46@rubyforge.org>

Feature Requests item #13453, was opened at 2007-08-28 00:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13453&group_id=797

Category: runner module
Group: None
>Status: Deleted
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in

I'm open to names other than xit, such as disabled_it.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13453&group_id=797

From noreply at rubyforge.org  Thu Aug 30 11:59:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 11:59:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13453 ] disabled specs
Message-ID: <20070830155940.EE9B75240B2B@rubyforge.org>

Feature Requests item #13453, was opened at 2007-08-28 07:45
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13453&group_id=797

Category: runner module
Group: None
Status: Deleted
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in

I'm open to names other than xit, such as disabled_it.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-30 15:59

Message:
Who marked this as deleted and why?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13453&group_id=797

From dan at tastapod.com  Thu Aug 30 12:00:07 2007
From: dan at tastapod.com (dan at tastapod.com)
Date: Thu, 30 Aug 2007 17:00:07 +0100 (BST)
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <3206C4CE-9C04-4206-9FC1-CA9E224CD8F5@railsnewbie.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<46D489A2.1000005@tastapod.com>
	<57c63afe0708281353r7ad6e069s7350f8943daafa7b@mail.gmail.com>
	<8d961d900708281425j4697dd0aoe3e370c984f4e88d@mail.gmail.com>
	<E9B236C4-0671-4C8E-A26B-7D62E647FFE0@rupespad.com>
	<3206C4CE-9C04-4206-9FC1-CA9E224CD8F5@railsnewbie.com>
Message-ID: <38093.147.114.226.182.1188489607.squirrel@www.tastapod.com>

>
> On Aug 28, 2007, at 5:44 PM, rupert wrote:
>
>>
>> On 28 Aug 2007, at 22:25, aslak hellesoy wrote:
>>> GEM:
>>> ROOT/lib
>>> ROOT/stories # RBehave stuff
>>> ROOT/examples # Classic RSpec stuff
>>>
>>> RAILS:
>>> ROOT/app
>>> ROOT/lib
>>> ROOT/stories # RBehave stuff
>>> ROOT/examples # Classic RSpec stuff
>>> ROOT/examples/models
>>> ROOT/examples/controllers
>>> ROOT/examples/views
>>> ROOT/examples/helpers
>>> ROOT/examples/lib
>>
>> How about implementation(s) instead of examples, as it contains the
>> specs that show how the stories have been implemented.  Examples to
>> me sounds more like a 'this is how it might be done' rather than a
>> 'this is how it has been done'.
>
> Examples are both a "this is how it should be done in the future",
> and "this is how it is done, now."  Isn't this why "should" won, and
> "must" lost in Rspec v 0.1 ?
>
> Scott

The power of "should" is that when you read a failing example, you're
allowed to ask yourself "should it?". Words like "must" or "shall" tend to
limit this process linguistically. "Should" works before the fact (I need
to implement code because the object should do blah and currently doesn't)
and after the fact (it should continue to do blah, unless the premise of
the system changes, in which case I change the example or replace it with
one that describes the new behaviour).

I've noticed a lot of novice TDDers are uncomfortable changing or deleting
tests because they equate the number of tests with the quality of their
application and/or they fear changing a test they didn't write. BDDers get
past this stage much more quickly by learning to feel safe questioning the
premise of a failing example.

ps. I'm really starting to like this layout of having the code spec
directory and story directory at the top level. The parent "behaviour"
directory isn't doing much for me any more. I'm happy to retract it.


From dan at tastapod.com  Thu Aug 30 12:28:10 2007
From: dan at tastapod.com (dan at tastapod.com)
Date: Thu, 30 Aug 2007 17:28:10 +0100 (BST)
Subject: [rspec-devel] experimental rails story adapter in trunk
In-Reply-To: <57c63afe0708292147k58ab553ag68b064c3fa8d1351@mail.gmail.com>
References: <57c63afe0708292147k58ab553ag68b064c3fa8d1351@mail.gmail.com>
Message-ID: <48933.147.114.226.182.1188491290.squirrel@www.tastapod.com>

> For those of you interested in getting a jump on learning about and
> using the new Story Runner in a Rails app, I've added an experimental
> Rails-Story adapter to trunk.
>
> You can see how to use it here:
>
> http://pastie.caboo.se/92320
>
> This is PURELY EXPERIMENTAL, however it actually works and will likely
> not change much in the way that it does work.
>
> Happy hacking!
>
> David

I tidied it up a bit - there were some parameters that weren't being used
as parameters. It's now at http://pastie.caboo.se/92472.

Also, I'm wondering (out loud) whether you can do this:

When "creating a new person with no name" do
  When "creating a new person named", nil
end

It _feels_ like it should work. Can't see why it wouldn't. Better yet, you
could have a method:

def create_person(name)
  post "/people/create", :person => {:name => name}
end

at the Story or Scenario level and call it from both Whens.

Cheers,
Dan


From noreply at rubyforge.org  Thu Aug 30 12:31:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 12:31:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g.
	xit)
Message-ID: <20070830163104.AC00DA970022@rubyforge.org>

Feature Requests item #13454, was opened at 2007-08-28 00:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.

----------------------------------------------------------------------

>Comment By: Brian Takita (btakita)
Date: 2007-08-30 09:31

Message:
I propose raising an error (e.g. raise
BehaviourDisabledError, "Behaviour blah blah is disabled").
This has different semantic meaning and usage from pending.
Pending can be checked in, xit cannot.

Also, to clarify, xtest in an xUnit convention (by practical
usage). It naturally works because tests are methods and you
can change the method name. I meant, xit is rspec's
equivalent to xtest.
I have been in several situations where the developer is new
to rspec and experienced with xUnit expects to be able to x
out the examples.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 13:40

Message:
Maybe I misunderstood the goal here. My thinking is that xit is a shortcut for pending - it should work exactly like pending does, providing its own message - so that it does keep it on the radar. I agree w/ Brian's goal of being able to swiftly switch the state of each "it" by preceding it w/ an 'x', but only if it makes sure you know about it.

----------------------------------------------------------------------

Comment By: Dan North (tastapod)
Date: 2007-08-28 13:28

Message:
David said: "I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing."

The problem is, it doesn't keep it on the radar. I've found literally tens of tests commented out (or x-ed out) in a codebase, which once they were re-enabled all failed because the code no longer did what it was supposed to.

The intent behind pending() is to keep them on the radar, nagging away with every build, but without actually failing the build. You can put a pending in a describe (specify) block and it should Just Work (ie. mark the whole section and any of its examples as pending). If not this is a bug.

I'd like to challenge two of the comments in the original description. Firstly pending is exactly intended to temporarily disable examples or scenarios - that's the point! Secondly, it isn't a convention from xunit, it's a convention from jbehave - the java bdd framework - that I introduced because I didn't like the binary nature of red/green (I guess I wanted yellow!). Pending behaviour is very much a BDD initiative, although it's made its way back into the xunit world (nunit has it as an Ignore attribute on a Test).

Then I brought it into rbehave because I found it so useful - and because scenarios tend to spend longer in a "pending" state than code-level examples. Then one of the rspec devs (I think it was Brian) brought it into rspec and improved it by allowing it to wrap a block.

I would strongly encourage using pending() for exactly this use case. Ideally with a message saying what needs to be done to make it work.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 10:06

Message:
For me, RSpec is all about process. So even though I was originally resistant to this, the more I think about it the more I can see using it. I comment specs out all the time in practice and I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing.

I say go for it - but the docs should be very specific about intent (i.e. recommend that xit should not be committed).

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-28 09:04

Message:
Just playing devil's advocate here, but couldn't you accomplish the same by just pasting "; pending 'x'" at the end of the "it" line, like this?

describe Foo
  it 'should be baz' do; pending 'x'
    @foo.should == 'baz'
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

From noreply at rubyforge.org  Thu Aug 30 12:38:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 12:38:31 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13454 ] disabled specs (e.g.
	xit)
Message-ID: <20070830163831.628205240B92@rubyforge.org>

Feature Requests item #13454, was opened at 2007-08-28 07:51
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

Category: runner module
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: disabled specs (e.g. xit)

Initial Comment:
I ran into a situation where a pending spec was not sufficient.
It was useful to create an xit method that deactivated the spec and gave a warning that the spec was deactivated.

It would be very nice to have xit (or equivalent method) because:
* There are situations where a spec just needs to be xed out for a moment. This is not meant to be checked in. Its a good backup when focused specs do not reliably work, such as when working on rspec core.
* Sticking a pending in front of every spec requires too much mental effort. i.e.  I lost the context of the problem I was working on because I needed to figure out the regex. Its really annoying.
* Pending is not meant to temporarily disable specs
* Its an xUnit convention
* test/spec uses xspecify (for pending specs, which is not the same)
* I feel silly having a useful method lying around that I can't check in (well I did check it in again, and since removed it)
* Its the simplest thing that could possibly work
* The alternative is commenting out the specs

I'm open to names other than xit, such as disabled_it. If we are afraid of confusing users, it could be deemed an "advanced" feature.

I understand that its difficult to justify because it involves a process that not commited to the repository, yet it is a common practice and useful.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-30 16:38

Message:
+1 for BehaviourDisabledError or ExampleDisabledError

----------------------------------------------------------------------

Comment By: Brian Takita (btakita)
Date: 2007-08-30 16:31

Message:
I propose raising an error (e.g. raise
BehaviourDisabledError, "Behaviour blah blah is disabled").
This has different semantic meaning and usage from pending.
Pending can be checked in, xit cannot.

Also, to clarify, xtest in an xUnit convention (by practical
usage). It naturally works because tests are methods and you
can change the method name. I meant, xit is rspec's
equivalent to xtest.
I have been in several situations where the developer is new
to rspec and experienced with xUnit expects to be able to x
out the examples.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 20:40

Message:
Maybe I misunderstood the goal here. My thinking is that xit is a shortcut for pending - it should work exactly like pending does, providing its own message - so that it does keep it on the radar. I agree w/ Brian's goal of being able to swiftly switch the state of each "it" by preceding it w/ an 'x', but only if it makes sure you know about it.

----------------------------------------------------------------------

Comment By: Dan North (tastapod)
Date: 2007-08-28 20:28

Message:
David said: "I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing."

The problem is, it doesn't keep it on the radar. I've found literally tens of tests commented out (or x-ed out) in a codebase, which once they were re-enabled all failed because the code no longer did what it was supposed to.

The intent behind pending() is to keep them on the radar, nagging away with every build, but without actually failing the build. You can put a pending in a describe (specify) block and it should Just Work (ie. mark the whole section and any of its examples as pending). If not this is a bug.

I'd like to challenge two of the comments in the original description. Firstly pending is exactly intended to temporarily disable examples or scenarios - that's the point! Secondly, it isn't a convention from xunit, it's a convention from jbehave - the java bdd framework - that I introduced because I didn't like the binary nature of red/green (I guess I wanted yellow!). Pending behaviour is very much a BDD initiative, although it's made its way back into the xunit world (nunit has it as an Ignore attribute on a Test).

Then I brought it into rbehave because I found it so useful - and because scenarios tend to spend longer in a "pending" state than code-level examples. Then one of the rspec devs (I think it was Brian) brought it into rspec and improved it by allowing it to wrap a block.

I would strongly encourage using pending() for exactly this use case. Ideally with a message saying what needs to be done to make it work.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-28 17:06

Message:
For me, RSpec is all about process. So even though I was originally resistant to this, the more I think about it the more I can see using it. I comment specs out all the time in practice and I've been known to accidentally check one in from time to time. If this helps to keep things on the radar, then it's a good thing.

I say go for it - but the docs should be very specific about intent (i.e. recommend that xit should not be committed).

----------------------------------------------------------------------

Comment By: Ian Dees (undees)
Date: 2007-08-28 16:04

Message:
Just playing devil's advocate here, but couldn't you accomplish the same by just pasting "; pending 'x'" at the end of the "it" line, like this?

describe Foo
  it 'should be baz' do; pending 'x'
    @foo.should == 'baz'
  end
end



----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13454&group_id=797

From brian.takita at gmail.com  Thu Aug 30 12:41:41 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Thu, 30 Aug 2007 09:41:41 -0700
Subject: [rspec-devel] Behaviour/Example naming confusion
Message-ID: <1d7ddd110708300941p1d44a8f5x24c0922615df593c@mail.gmail.com>

I recently removed the Example class from rspec core. Currently, the
specs run in an instance of Behaviour. I'm wondering do we want to
call the "spec" a Behaviour or an Example?

Currently I do not see a need for an Example domain term. It seems
like Behaviour is sufficient.
"User has 3 behaviours" vs "User has 3 examples"

I've found that involving the term Example, clutters my explanation of
rspec, and the describe/it syntax.

Coworker: "I have 5 its in my describe."
Me: "You mean you have 5 Examples in your Behaviour?"

If we remove Example, I think the explanation can be easier to grok.
Coworker: "I have 5 its in my describe."
Me: "You mean you have 5 Behaviours in your Description?"

wdyt?

From mailing_lists at railsnewbie.com  Thu Aug 30 12:43:15 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Thu, 30 Aug 2007 12:43:15 -0400
Subject: [rspec-devel] Game of Life questions
In-Reply-To: <38093.147.114.226.182.1188489607.squirrel@www.tastapod.com>
References: <8d961d900708281052u3d7bee71i74165aec9d9aba79@mail.gmail.com>
	<46D489A2.1000005@tastapod.com>
	<57c63afe0708281353r7ad6e069s7350f8943daafa7b@mail.gmail.com>
	<8d961d900708281425j4697dd0aoe3e370c984f4e88d@mail.gmail.com>
	<E9B236C4-0671-4C8E-A26B-7D62E647FFE0@rupespad.com>
	<3206C4CE-9C04-4206-9FC1-CA9E224CD8F5@railsnewbie.com>
	<38093.147.114.226.182.1188489607.squirrel@www.tastapod.com>
Message-ID: <A126F5C6-CE20-4EED-BB19-39DCFED32D95@railsnewbie.com>


On Aug 30, 2007, at 12:00 PM, dan at tastapod.com wrote:

>>
>> On Aug 28, 2007, at 5:44 PM, rupert wrote:
>>
>>>
>>> On 28 Aug 2007, at 22:25, aslak hellesoy wrote:
>>>> GEM:
>>>> ROOT/lib
>>>> ROOT/stories # RBehave stuff
>>>> ROOT/examples # Classic RSpec stuff
>>>>
>>>> RAILS:
>>>> ROOT/app
>>>> ROOT/lib
>>>> ROOT/stories # RBehave stuff
>>>> ROOT/examples # Classic RSpec stuff
>>>> ROOT/examples/models
>>>> ROOT/examples/controllers
>>>> ROOT/examples/views
>>>> ROOT/examples/helpers
>>>> ROOT/examples/lib
>>>
>>> How about implementation(s) instead of examples, as it contains the
>>> specs that show how the stories have been implemented.  Examples to
>>> me sounds more like a 'this is how it might be done' rather than a
>>> 'this is how it has been done'.
>>
>> Examples are both a "this is how it should be done in the future",
>> and "this is how it is done, now."  Isn't this why "should" won, and
>> "must" lost in Rspec v 0.1 ?
>>
>> Scott
>
> The power of "should" is that when you read a failing example, you're
> allowed to ask yourself "should it?". Words like "must" or "shall"  
> tend to
> limit this process linguistically. "Should" works before the fact  
> (I need
> to implement code because the object should do blah and currently  
> doesn't)
> and after the fact (it should continue to do blah, unless the  
> premise of
> the system changes, in which case I change the example or replace  
> it with
> one that describes the new behaviour).

When doing TDD, there seems to be two types of things that occur:

1. an new example is given (the spec).  The runner is run, and there  
is one failing spec: The one which hasn't been implemented yet.
2. #1 occurs, but after the spec is implemented, and working, other  
specs start to fail.  This one is more about questioning assumptions.

These two scenarios embody a general principle - "I am making the  
thing, so I am telling it what should and should not be".  When the  
second case occurs, either your spec contradicts itself (in which  
case specs can be deleted), or your implementation contradicts the  
intended behaviour (the spec), in which case the implementation needs  
to be fixed.  You're probably right in saying that the language of  
"testing"/"must" gives some sort of subconscious feeling that the  
spec isn't contradicting itself, but rather the implementation is.

>
> I've noticed a lot of novice TDDers are uncomfortable changing or  
> deleting
> tests because they equate the number of tests with the quality of  
> their
>

And non TDD-ers are alright with writing code which breaks tests,  
without taking the time to run the tests.

> application and/or they fear changing a test they didn't write.  
> BDDers get
> past this stage much more quickly by learning to feel safe  
> questioning the
> premise of a failing example.

Sure - because testing comes after a thing is built, while a  
specification can change over time.

The novice assumption that more tests = quality of application  
certainly does hold true (although it certainly isn't proportional).   
I would be inclined to think that when you delete a test/spec, you  
should probably replace it with a spec of the new behaviour (although  
this seems pretty dependent on the situation).  It's certainly true  
that an app w/ no tests/specs can be quite buggy, and can be  
considered lacking in sufficient documentation.

Scott


From dchelimsky at gmail.com  Thu Aug 30 12:48:31 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 30 Aug 2007 11:48:31 -0500
Subject: [rspec-devel] Behaviour/Example naming confusion
In-Reply-To: <1d7ddd110708300941p1d44a8f5x24c0922615df593c@mail.gmail.com>
References: <1d7ddd110708300941p1d44a8f5x24c0922615df593c@mail.gmail.com>
Message-ID: <57c63afe0708300948i3e0857ecm79219a2940b625ce@mail.gmail.com>

On 8/30/07, Brian Takita <brian.takita at gmail.com> wrote:
> I recently removed the Example class from rspec core. Currently, the
> specs run in an instance of Behaviour. I'm wondering do we want to
> call the "spec" a Behaviour or an Example?
>
> Currently I do not see a need for an Example domain term. It seems
> like Behaviour is sufficient.
> "User has 3 behaviours" vs "User has 3 examples"
>
> I've found that involving the term Example, clutters my explanation of
> rspec, and the describe/it syntax.
>
> Coworker: "I have 5 its in my describe."

That IS an unfortunate side-effect of our choice in words.

> Me: "You mean you have 5 Examples in your Behaviour?"
>
> If we remove Example, I think the explanation can be easier to grok.
> Coworker: "I have 5 its in my describe."
> Me: "You mean you have 5 Behaviours in your Description?"
>
> wdyt?

My gut reaction to this is that the problematic word here is
Behaviour, not Example. I'd say let's bag Behaviour.

Coworker: "I have 5 its in my describe."
Me: "You mean you have 5 Examples in your Description?"

That makes much more sense to me.

Thoughts?


> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brian.takita at gmail.com  Thu Aug 30 13:03:46 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Thu, 30 Aug 2007 10:03:46 -0700
Subject: [rspec-devel] Behaviour/Example naming confusion
In-Reply-To: <57c63afe0708300948i3e0857ecm79219a2940b625ce@mail.gmail.com>
References: <1d7ddd110708300941p1d44a8f5x24c0922615df593c@mail.gmail.com>
	<57c63afe0708300948i3e0857ecm79219a2940b625ce@mail.gmail.com>
Message-ID: <1d7ddd110708301003i6ea6fc99qec50b65ea14a1d71@mail.gmail.com>

On 8/30/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/30/07, Brian Takita <brian.takita at gmail.com> wrote:
> > I recently removed the Example class from rspec core. Currently, the
> > specs run in an instance of Behaviour. I'm wondering do we want to
> > call the "spec" a Behaviour or an Example?
> >
> > Currently I do not see a need for an Example domain term. It seems
> > like Behaviour is sufficient.
> > "User has 3 behaviours" vs "User has 3 examples"
> >
> > I've found that involving the term Example, clutters my explanation of
> > rspec, and the describe/it syntax.
> >
> > Coworker: "I have 5 its in my describe."
>
> That IS an unfortunate side-effect of our choice in words.
>
> > Me: "You mean you have 5 Examples in your Behaviour?"
> >
> > If we remove Example, I think the explanation can be easier to grok.
> > Coworker: "I have 5 its in my describe."
> > Me: "You mean you have 5 Behaviours in your Description?"
> >
> > wdyt?
>
> My gut reaction to this is that the problematic word here is
> Behaviour, not Example. I'd say let's bag Behaviour.
>
> Coworker: "I have 5 its in my describe."
> Me: "You mean you have 5 Examples in your Description?"
>
> That makes much more sense to me.
That makes sense. Example is equivalent to TestCase is more natural
than saying Behaviour is equivalent to TestCase.
Does this mean our Behaviour object should be renamed to Example?

>
> Thoughts?
>
>
> > _______________________________________________
> > 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  Thu Aug 30 13:23:32 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 30 Aug 2007 12:23:32 -0500
Subject: [rspec-devel] Behaviour/Example naming confusion
In-Reply-To: <1d7ddd110708301003i6ea6fc99qec50b65ea14a1d71@mail.gmail.com>
References: <1d7ddd110708300941p1d44a8f5x24c0922615df593c@mail.gmail.com>
	<57c63afe0708300948i3e0857ecm79219a2940b625ce@mail.gmail.com>
	<1d7ddd110708301003i6ea6fc99qec50b65ea14a1d71@mail.gmail.com>
Message-ID: <57c63afe0708301023n795d08adxe6976f5634946086@mail.gmail.com>

On 8/30/07, Brian Takita <brian.takita at gmail.com> wrote:
> On 8/30/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/30/07, Brian Takita <brian.takita at gmail.com> wrote:
> > > I recently removed the Example class from rspec core. Currently, the
> > > specs run in an instance of Behaviour. I'm wondering do we want to
> > > call the "spec" a Behaviour or an Example?
> > >
> > > Currently I do not see a need for an Example domain term. It seems
> > > like Behaviour is sufficient.
> > > "User has 3 behaviours" vs "User has 3 examples"
> > >
> > > I've found that involving the term Example, clutters my explanation of
> > > rspec, and the describe/it syntax.
> > >
> > > Coworker: "I have 5 its in my describe."
> >
> > That IS an unfortunate side-effect of our choice in words.
> >
> > > Me: "You mean you have 5 Examples in your Behaviour?"
> > >
> > > If we remove Example, I think the explanation can be easier to grok.
> > > Coworker: "I have 5 its in my describe."
> > > Me: "You mean you have 5 Behaviours in your Description?"
> > >
> > > wdyt?
> >
> > My gut reaction to this is that the problematic word here is
> > Behaviour, not Example. I'd say let's bag Behaviour.
> >
> > Coworker: "I have 5 its in my describe."
> > Me: "You mean you have 5 Examples in your Description?"
> >
> > That makes much more sense to me.
> That makes sense. Example is equivalent to TestCase is more natural
> than saying Behaviour is equivalent to TestCase.
> Does this mean our Behaviour object should be renamed to Example?

Well - that's where that would lead. I'd like to see some input from
Aslak and Dan and anyone else who wants to comment first.

>
> >
> > Thoughts?
> >
> >
> > > _______________________________________________
> > > 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  Thu Aug 30 15:11:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 15:11:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13532 ] /lib specs should
	get base EvalContext
Message-ID: <20070830191141.7E83A5240C54@rubyforge.org>

Feature Requests item #13532, was opened at 2007-08-30 15:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: /lib specs should get base EvalContext

Initial Comment:
Right now, we have spec/controllers, spec/views, spec/models, and spec/helpers.  spec/lib is often used for classes in /lib that are not part of a model, but which might need to interact Rails.  /lib specs should get the base behaviour - which currently only includes mock_model, but might expand to other things.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

From noreply at rubyforge.org  Thu Aug 30 16:22:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 16:22:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13532 ] /lib specs should
	get base EvalContext
Message-ID: <20070830202254.D479D5240C55@rubyforge.org>

Feature Requests item #13532, was opened at 2007-08-30 15:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: /lib specs should get base EvalContext

Initial Comment:
Right now, we have spec/controllers, spec/views, spec/models, and spec/helpers.  spec/lib is often used for classes in /lib that are not part of a model, but which might need to interact Rails.  /lib specs should get the base behaviour - which currently only includes mock_model, but might expand to other things.

----------------------------------------------------------------------

>Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-30 16:22

Message:
This is a bit vague - can you illustrate with a failing spec?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

From noreply at rubyforge.org  Thu Aug 30 16:30:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 16:30:14 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13532 ] /lib specs should
	get base EvalContext
Message-ID: <20070830203014.C47AA5240C66@rubyforge.org>

Feature Requests item #13532, was opened at 2007-08-30 15:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: /lib specs should get base EvalContext

Initial Comment:
Right now, we have spec/controllers, spec/views, spec/models, and spec/helpers.  spec/lib is often used for classes in /lib that are not part of a model, but which might need to interact Rails.  /lib specs should get the base behaviour - which currently only includes mock_model, but might expand to other things.

----------------------------------------------------------------------

>Comment By: Jay Levitt (jaylev)
Date: 2007-08-30 16:30

Message:
Sure - as the OP posted to rspec-users, any spec with
mock_model in spec/lib will fail:

describe my_lib_func
  it "should be PI higher than my_model.id" do
    u = mock_model(:user)
    my_lib_func.value.should == u.id + PI
  end
end


----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-30 16:22

Message:
This is a bit vague - can you illustrate with a failing spec?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

From noreply at rubyforge.org  Thu Aug 30 18:08:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 18:08:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13532 ] /lib specs should
	get base EvalContext
Message-ID: <20070830220835.ACBE15240CB5@rubyforge.org>

Feature Requests item #13532, was opened at 2007-08-30 19:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jay Levitt (jaylev)
Assigned to: Nobody (None)
Summary: /lib specs should get base EvalContext

Initial Comment:
Right now, we have spec/controllers, spec/views, spec/models, and spec/helpers.  spec/lib is often used for classes in /lib that are not part of a model, but which might need to interact Rails.  /lib specs should get the base behaviour - which currently only includes mock_model, but might expand to other things.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-30 22:08

Message:
I set this up a bit differently - there was already a RailsBehaviour which is the base for ModelBehaviour, ViewBehaviour, ControllerBehaviour and HelperBehaviour. I made it so that is the default for ANY directory outside models, views, controllers, and helpers. It has mock_model, add_stubs and general fixtures support.

Right now, ModelBehaviour simply derives from RailsBehaviour but doesn't add anything additional. It seems like it wants to be deprecated, but that's a topic for another thread.

Added to r2482.

----------------------------------------------------------------------

Comment By: Jay Levitt (jaylev)
Date: 2007-08-30 20:30

Message:
Sure - as the OP posted to rspec-users, any spec with
mock_model in spec/lib will fail:

describe my_lib_func
  it "should be PI higher than my_model.id" do
    u = mock_model(:user)
    my_lib_func.value.should == u.id + PI
  end
end


----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-30 20:22

Message:
This is a bit vague - can you illustrate with a failing spec?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

From noreply at rubyforge.org  Thu Aug 30 18:09:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 18:09:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13532 ] /lib specs should
	get base EvalContext
Message-ID: <20070830220901.B34805240C70@rubyforge.org>

Feature Requests item #13532, was opened at 2007-08-30 19:11
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

Category: rails plugin
Group: None
>Status: Closed
Priority: 3
Submitted By: Jay Levitt (jaylev)
>Assigned to: David Chelimsky (dchelimsky)
Summary: /lib specs should get base EvalContext

Initial Comment:
Right now, we have spec/controllers, spec/views, spec/models, and spec/helpers.  spec/lib is often used for classes in /lib that are not part of a model, but which might need to interact Rails.  /lib specs should get the base behaviour - which currently only includes mock_model, but might expand to other things.

----------------------------------------------------------------------

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-30 22:09

Message:
Meant to close it w/ the last comment.

----------------------------------------------------------------------

Comment By: David Chelimsky (dchelimsky)
Date: 2007-08-30 22:08

Message:
I set this up a bit differently - there was already a RailsBehaviour which is the base for ModelBehaviour, ViewBehaviour, ControllerBehaviour and HelperBehaviour. I made it so that is the default for ANY directory outside models, views, controllers, and helpers. It has mock_model, add_stubs and general fixtures support.

Right now, ModelBehaviour simply derives from RailsBehaviour but doesn't add anything additional. It seems like it wants to be deprecated, but that's a topic for another thread.

Added to r2482.

----------------------------------------------------------------------

Comment By: Jay Levitt (jaylev)
Date: 2007-08-30 20:30

Message:
Sure - as the OP posted to rspec-users, any spec with
mock_model in spec/lib will fail:

describe my_lib_func
  it "should be PI higher than my_model.id" do
    u = mock_model(:user)
    my_lib_func.value.should == u.id + PI
  end
end


----------------------------------------------------------------------

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-30 20:22

Message:
This is a bit vague - can you illustrate with a failing spec?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13532&group_id=797

From dan at tastapod.com  Thu Aug 30 19:11:00 2007
From: dan at tastapod.com (Dan North)
Date: Fri, 31 Aug 2007 00:11:00 +0100
Subject: [rspec-devel] Behaviour/Example naming confusion
In-Reply-To: <57c63afe0708301023n795d08adxe6976f5634946086@mail.gmail.com>
References: <1d7ddd110708300941p1d44a8f5x24c0922615df593c@mail.gmail.com>	<57c63afe0708300948i3e0857ecm79219a2940b625ce@mail.gmail.com>	<1d7ddd110708301003i6ea6fc99qec50b65ea14a1d71@mail.gmail.com>
	<57c63afe0708301023n795d08adxe6976f5634946086@mail.gmail.com>
Message-ID: <46D74E84.8000405@tastapod.com>

David Chelimsky wrote:
> On 8/30/07, Brian Takita <brian.takita at gmail.com> wrote:
>   
>> On 8/30/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>>     
>>> On 8/30/07, Brian Takita <brian.takita at gmail.com> wrote:
>>>       
>>>> I recently removed the Example class from rspec core. Currently, the
>>>> specs run in an instance of Behaviour. I'm wondering do we want to
>>>> call the "spec" a Behaviour or an Example?
>>>>
>>>> Currently I do not see a need for an Example domain term. It seems
>>>> like Behaviour is sufficient.
>>>> "User has 3 behaviours" vs "User has 3 examples"
>>>>
>>>> I've found that involving the term Example, clutters my explanation of
>>>> rspec, and the describe/it syntax.
>>>>
>>>> Coworker: "I have 5 its in my describe."
>>>>         
>>> That IS an unfortunate side-effect of our choice in words.
>>>
>>>       
>>>> Me: "You mean you have 5 Examples in your Behaviour?"
>>>>
>>>> If we remove Example, I think the explanation can be easier to grok.
>>>> Coworker: "I have 5 its in my describe."
>>>> Me: "You mean you have 5 Behaviours in your Description?"
>>>>
>>>> wdyt?
>>>>         
>>> My gut reaction to this is that the problematic word here is
>>> Behaviour, not Example. I'd say let's bag Behaviour.
>>>
>>> Coworker: "I have 5 its in my describe."
>>> Me: "You mean you have 5 Examples in your Description?"
>>>
>>> That makes much more sense to me.
>>>       
>> That makes sense. Example is equivalent to TestCase is more natural
>> than saying Behaviour is equivalent to TestCase.
>> Does this mean our Behaviour object should be renamed to Example?
>>     
>
> Well - that's where that would lead. I'd like to see some input from
> Aslak and Dan and anyone else who wants to comment first.
>
>   
You had me at "5 its". Eww!

What you're really saying is "I can describe this object's behaviour 
with these five examples". When I was first writing JBehave I ended up 
with everything /but/ a Behaviour class. It seemed like the framework 
created a "behaviour-shaped hole" in the middle for me to put stuff in.

I say go with Examples inside a Description, analagous to Scenarios 
inside a Story. (fwiw in Java-land I used to call them behaviour 
methods, but I've found myself switching to "examples" recently).

Great work with the simplification Brian.

Cheers,
Dan

ps. Does that mean include works properly inside the example and 
description blocks now?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20070831/eef6a1a0/attachment.html 

From noreply at rubyforge.org  Thu Aug 30 20:56:53 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 30 Aug 2007 20:56:53 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13540 ] [Story Runner] dry
	run should show all of the steps, even after one that fails
Message-ID: <20070831005653.3ED445240DD1@rubyforge.org>

Feature Requests item #13540, was opened at 2007-08-31 00:56
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13540&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Dan North (tastapod)
Summary: [Story Runner] dry run should show all of the steps, even after one that fails

Initial Comment:
I've got a Scenario which is failing at a step in the middle. When I run:

  ruby stories/user_changes_password.rb

the output does not include all of the steps, but does show the error that occurs in the last step that was executed.

When I run:

  ruby stories/user_changes_password.rb --dry-run

the output, again, does not include all of the steps, even though it doesn't give you the impression that any steps are actually getting executed.

I think you should see all of the steps when doing a dry run. In fact, I really think you should see all of the steps even when one fails. This is high level stuff - 'fail fast' doesn't have the same meaning here as it does when doing TDD at the object level.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13540&group_id=797

From undees at gmail.com  Thu Aug 30 21:14:21 2007
From: undees at gmail.com (Ian Dees)
Date: Thu, 30 Aug 2007 18:14:21 -0700
Subject: [rspec-devel] Behaviour/Example naming confusion
Message-ID: <ad4f9af90708301814v4b2cd817ke236c293662ff14@mail.gmail.com>

Hi, all.

Quoth Brian:

> That makes sense. Example is equivalent to TestCase is more natural
> than saying Behaviour is equivalent to TestCase.
> Does this mean our Behaviour object should be renamed to Example?

I like it.  It avoids the whole transatlantic spelling issue.

--Ian

From lists-rspec at shopwatch.org  Thu Aug 30 21:38:19 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Thu, 30 Aug 2007 21:38:19 -0400
Subject: [rspec-devel] [ rspec-Feature Requests-13532 ] /lib specs
 should get base EvalContext
In-Reply-To: <20070830220901.B34805240C70@rubyforge.org>
References: <20070830220901.B34805240C70@rubyforge.org>
Message-ID: <46D7710B.3050906@jay.fm>

> I set this up a bit differently - there was already a RailsBehaviour which is the base for ModelBehaviour, ViewBehaviour, ControllerBehaviour and HelperBehaviour. I made it so that is the default for ANY directory outside models, views, controllers, and helpers. It has mock_model, add_stubs and general fixtures support.
> 
> Right now, ModelBehaviour simply derives from RailsBehaviour but doesn't add anything additional. It seems like it wants to be deprecated, but that's a topic for another thread.

That sounds great.  I don't think ModelBehaviour needs deprecation; it 
seems obvious that someone will need to create it in the future, so 
might as well keep it for symmetry.  rspec_on_rails is early days even 
compared to rspec!

That said, I noticed FunctionalBehaviour still kicking around; isn't 
that deprecated?

Jay


From lists-rspec at shopwatch.org  Thu Aug 30 21:39:56 2007
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Thu, 30 Aug 2007 21:39:56 -0400
Subject: [rspec-devel] Behaviour/Example naming confusion
In-Reply-To: <ad4f9af90708301814v4b2cd817ke236c293662ff14@mail.gmail.com>
References: <ad4f9af90708301814v4b2cd817ke236c293662ff14@mail.gmail.com>
Message-ID: <46D7716C.1050902@jay.fm>

Ian Dees wrote:
> Hi, all.
> 
> Quoth Brian:
> 
>> That makes sense. Example is equivalent to TestCase is more natural
>> than saying Behaviour is equivalent to TestCase.
>> Does this mean our Behaviour object should be renamed to Example?
> 
> I like it.  It avoids the whole transatlantic spelling issue.

I'm not sure it does.  Don't they pronounce it "Exaumple" across the pond?

Jay


From dchelimsky at gmail.com  Thu Aug 30 23:46:55 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 30 Aug 2007 22:46:55 -0500
Subject: [rspec-devel] [ rspec-Feature Requests-13532 ] /lib specs
	should get base EvalContext
In-Reply-To: <46D7710B.3050906@jay.fm>
References: <20070830220901.B34805240C70@rubyforge.org>
	<46D7710B.3050906@jay.fm>
Message-ID: <57c63afe0708302046y3354fd46q3c39744543433566@mail.gmail.com>

On 8/30/07, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> > I set this up a bit differently - there was already a RailsBehaviour which is the base for ModelBehaviour, ViewBehaviour, ControllerBehaviour and HelperBehaviour. I made it so that is the default for ANY directory outside models, views, controllers, and helpers. It has mock_model, add_stubs and general fixtures support.
> >
> > Right now, ModelBehaviour simply derives from RailsBehaviour but doesn't add anything additional. It seems like it wants to be deprecated, but that's a topic for another thread.
>
> That sounds great.  I don't think ModelBehaviour needs deprecation; it
> seems obvious that someone will need to create it in the future, so
> might as well keep it for symmetry.  rspec_on_rails is early days even
> compared to rspec!
>
> That said, I noticed FunctionalBehaviour still kicking around; isn't
> that deprecated?

Nope. That's the base class for ControllerBehaviour, ViewBehaviour and
HelperBehaviour.

>
> Jay
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Fri Aug 31 05:01:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 31 Aug 2007 05:01:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13547 ] [Story Runner] html
	formatted output
Message-ID: <20070831090157.543B05240A2F@rubyforge.org>

Feature Requests item #13547, was opened at 2007-08-31 09:01
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13547&group_id=797

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: [Story Runner] html formatted output

Initial Comment:
Add html format for Story Runner

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=3152&aid=13547&group_id=797

From noreply at rubyforge.org  Fri Aug 31 05:03:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 31 Aug 2007 05:03:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13547 ] [Story Runner] html
	formatted output
Message-ID: <20070831090307.61FE95240A2E@rubyforge.org>

Feature Requests item #13547, was opened a