From pergesu at gmail.com  Mon Oct  1 16:11:43 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Mon, 1 Oct 2007 13:11:43 -0700
Subject: [rspec-devel] Partially mocked objects that define == blow up when
	another mock exists
Message-ID: <810a540e0710011311i73e0d5a3obb98543f92b96d89@mail.gmail.com>

One of my coworkers wrote a class that defines == to have simple value
object semantics.  One of our specs partially stubs the value object.
A change in the last week or so broke it.  Here's the setup:

stub("existing mock", :foo => :foo)
class ValueObject
  attr_reader :val

  def initialize(val)
    @val = val
  end

  def ==(other)
    @val == other.val
  end
end

@obj = ValueObject.new :bar
@obj.stub!(:some_method)  # blows up with undefined method on
#<Spec::Mocks::Proxy>

Now, this was easily fixed with changing == to

def ==(other)
  other.responds_to?(:val) && @val == val
end

which imo is better anyway, at least in this particular case.  His
argument was, "but we're never going to pass in an object of a
different class" in which case he should probably check the other
object's class just to make sure.

Anyway, I was interested in why this failed, because the error message
wasn't very helpful.

The problem is that in Spec::Mocks::Space#add it calls mocks.include?.
 Internally, Ruby uses == in include?, which in this case blows up.

I've got two ideas on this.  The first is to check for object identity
using equal?.  #add becomes:

def add(obj)
  mocks << obj unless mocks.detect {|m| m.equal? obj}
end

This way people can write the first version of == with no problems.

Another option is to inform them of duck typing, and that they'll want
to either use respond_to or check for the object's class.

The first way is less intrusive, and I think I would prefer it solely
on that merit.  I don't hate the other way though, and that's just as
trivial to implement.  Just rescue NoMethodError in #add with a link
to some duck typing page.

Here's a patch for the .equal? version: http://pastie.caboo.se/102619
I opted not to put it in the tracker because I wanted to generate some
discussion first.  Plus there are a lot of patches that are just
chilling there and I don't know if anyone's looking at them :)

Pat

From dchelimsky at gmail.com  Mon Oct  1 18:47:14 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 1 Oct 2007 17:47:14 -0500
Subject: [rspec-devel] Partially mocked objects that define == blow up
	when another mock exists
In-Reply-To: <810a540e0710011311i73e0d5a3obb98543f92b96d89@mail.gmail.com>
References: <810a540e0710011311i73e0d5a3obb98543f92b96d89@mail.gmail.com>
Message-ID: <57c63afe0710011547h150e02f9k1e54b7fff3d9cdd7@mail.gmail.com>

On 10/1/07, Pat Maddox <pergesu at gmail.com> wrote:
> One of my coworkers wrote a class that defines == to have simple value
> object semantics.  One of our specs partially stubs the value object.
> A change in the last week or so broke it.  Here's the setup:
>
> stub("existing mock", :foo => :foo)
> class ValueObject
>   attr_reader :val
>
>   def initialize(val)
>     @val = val
>   end
>
>   def ==(other)
>     @val == other.val
>   end
> end
>
> @obj = ValueObject.new :bar
> @obj.stub!(:some_method)  # blows up with undefined method on
> #<Spec::Mocks::Proxy>
>
> Now, this was easily fixed with changing == to
>
> def ==(other)
>   other.responds_to?(:val) && @val == val
> end
>
> which imo is better anyway, at least in this particular case.  His
> argument was, "but we're never going to pass in an object of a
> different class" in which case he should probably check the other
> object's class just to make sure.
>
> Anyway, I was interested in why this failed, because the error message
> wasn't very helpful.
>
> The problem is that in Spec::Mocks::Space#add it calls mocks.include?.
>  Internally, Ruby uses == in include?, which in this case blows up.
>
> I've got two ideas on this.  The first is to check for object identity
> using equal?.  #add becomes:
>
> def add(obj)
>   mocks << obj unless mocks.detect {|m| m.equal? obj}
> end
>
> This way people can write the first version of == with no problems.
>
> Another option is to inform them of duck typing, and that they'll want
> to either use respond_to or check for the object's class.
>
> The first way is less intrusive, and I think I would prefer it solely
> on that merit.  I don't hate the other way though, and that's just as
> trivial to implement.  Just rescue NoMethodError in #add with a link
> to some duck typing page.
>
> Here's a patch for the .equal? version: http://pastie.caboo.se/102619
> I opted not to put it in the tracker because I wanted to generate some
> discussion first.  Plus there are a lot of patches that are just
> chilling there and I don't know if anyone's looking at them :)

As luck would have it, I just ran into this exact problem. I think
your solution is sound. Unless anyone else barks "nay", I'd say go
ahead and submit the patch to the tracker and I'll apply it.

Cheers,
David

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

From noreply at rubyforge.org  Mon Oct  1 19:49:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  1 Oct 2007 19:49:17 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14362 ] [PATCH] partially mocking
	objects that define == can blow up
Message-ID: <20071001234917.4EF225240DA4@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Pat Maddox (pergesu)
Assigned to: Nobody (None)
Summary: [PATCH] partially mocking objects that define == can blow up

Initial Comment:
One of my coworkers wrote a class that defines == to have simple value
object semantics.  One of our specs partially stubs the value object.
A change in the last week or so broke it.  Here's the setup:

stub("existing mock", :foo => :foo)
class ValueObject
 attr_reader :val

 def initialize(val)
   @val = val
 end

 def ==(other)
   @val == other.val
 end
end

@obj = ValueObject.new :bar
@obj.stub!(:some_method)  # blows up with undefined method on
#<Spec::Mocks::Proxy>

Now, this was easily fixed with changing == to

def ==(other)
 other.responds_to?(:val) && @val == val
end

which imo is better anyway, at least in this particular case.  His
argument was, "but we're never going to pass in an object of a
different class" in which case he should probably check the other
object's class just to make sure.

Anyway, I was interested in why this failed, because the error message
wasn't very helpful.

The problem is that in Spec::Mocks::Space#add it calls mocks.include?.
 Internally, Ruby uses == in include?, which in this case blows up.

I've got two ideas on this.  The first is to check for object identity
using equal?.  #add becomes:

def add(obj)
 mocks << obj unless mocks.detect {|m| m.equal? obj}
end

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

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

From pergesu at gmail.com  Mon Oct  1 20:06:22 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Mon, 1 Oct 2007 17:06:22 -0700
Subject: [rspec-devel] Partially mocked objects that define == blow up
	when another mock exists
In-Reply-To: <57c63afe0710011547h150e02f9k1e54b7fff3d9cdd7@mail.gmail.com>
References: <810a540e0710011311i73e0d5a3obb98543f92b96d89@mail.gmail.com>
	<57c63afe0710011547h150e02f9k1e54b7fff3d9cdd7@mail.gmail.com>
Message-ID: <810a540e0710011706u23042a3h61adb9e7aa615fbc@mail.gmail.com>

On 10/1/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 10/1/07, Pat Maddox <pergesu at gmail.com> wrote:
> > One of my coworkers wrote a class that defines == to have simple value
> > object semantics.  One of our specs partially stubs the value object.
> > A change in the last week or so broke it.  Here's the setup:
> >
> > stub("existing mock", :foo => :foo)
> > class ValueObject
> >   attr_reader :val
> >
> >   def initialize(val)
> >     @val = val
> >   end
> >
> >   def ==(other)
> >     @val == other.val
> >   end
> > end
> >
> > @obj = ValueObject.new :bar
> > @obj.stub!(:some_method)  # blows up with undefined method on
> > #<Spec::Mocks::Proxy>
> >
> > Now, this was easily fixed with changing == to
> >
> > def ==(other)
> >   other.responds_to?(:val) && @val == val
> > end
> >
> > which imo is better anyway, at least in this particular case.  His
> > argument was, "but we're never going to pass in an object of a
> > different class" in which case he should probably check the other
> > object's class just to make sure.
> >
> > Anyway, I was interested in why this failed, because the error message
> > wasn't very helpful.
> >
> > The problem is that in Spec::Mocks::Space#add it calls mocks.include?.
> >  Internally, Ruby uses == in include?, which in this case blows up.
> >
> > I've got two ideas on this.  The first is to check for object identity
> > using equal?.  #add becomes:
> >
> > def add(obj)
> >   mocks << obj unless mocks.detect {|m| m.equal? obj}
> > end
> >
> > This way people can write the first version of == with no problems.
> >
> > Another option is to inform them of duck typing, and that they'll want
> > to either use respond_to or check for the object's class.
> >
> > The first way is less intrusive, and I think I would prefer it solely
> > on that merit.  I don't hate the other way though, and that's just as
> > trivial to implement.  Just rescue NoMethodError in #add with a link
> > to some duck typing page.
> >
> > Here's a patch for the .equal? version: http://pastie.caboo.se/102619
> > I opted not to put it in the tracker because I wanted to generate some
> > discussion first.  Plus there are a lot of patches that are just
> > chilling there and I don't know if anyone's looking at them :)
>
> As luck would have it, I just ran into this exact problem. I think
> your solution is sound. Unless anyone else barks "nay", I'd say go
> ahead and submit the patch to the tracker and I'll apply it.
>
> Cheers,
> David
>
> >
> > Pat
> > _______________________________________________
> > 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
>

Ticket is http://rubyforge.org/tracker/?func=detail&atid=3151&aid=14362&group_id=797

From noreply at rubyforge.org  Tue Oct  2 02:24:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 02:24:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14362 ] [PATCH] partially mocking
	objects that define == can blow up
Message-ID: <20071002062458.2F7455240DF1@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Pat Maddox (pergesu)
>Assigned to: David Chelimsky (dchelimsky)
Summary: [PATCH] partially mocking objects that define == can blow up

Initial Comment:
One of my coworkers wrote a class that defines == to have simple value
object semantics.  One of our specs partially stubs the value object.
A change in the last week or so broke it.  Here's the setup:

stub("existing mock", :foo => :foo)
class ValueObject
 attr_reader :val

 def initialize(val)
   @val = val
 end

 def ==(other)
   @val == other.val
 end
end

@obj = ValueObject.new :bar
@obj.stub!(:some_method)  # blows up with undefined method on
#<Spec::Mocks::Proxy>

Now, this was easily fixed with changing == to

def ==(other)
 other.responds_to?(:val) && @val == val
end

which imo is better anyway, at least in this particular case.  His
argument was, "but we're never going to pass in an object of a
different class" in which case he should probably check the other
object's class just to make sure.

Anyway, I was interested in why this failed, because the error message
wasn't very helpful.

The problem is that in Spec::Mocks::Space#add it calls mocks.include?.
 Internally, Ruby uses == in include?, which in this case blows up.

I've got two ideas on this.  The first is to check for object identity
using equal?.  #add becomes:

def add(obj)
 mocks << obj unless mocks.detect {|m| m.equal? obj}
end

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 06:24

Message:
Applied to r2681

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

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

From noreply at rubyforge.org  Tue Oct  2 02:46:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 02:46:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14255 ] Fixed examples in
	mock_spec.rb and shared_behaviour_spec.rb
Message-ID: <20071002064618.596E55240DDB@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Antti Tarvainen (tarvaina)
Assigned to: Nobody (None)
Summary: Fixed examples in mock_spec.rb and shared_behaviour_spec.rb

Initial Comment:
A recurring pattern in rspec internal examples is this:

it "should fail with a meaningful error message" do
  begin
    @object.failing_operation
  rescue PanicExceptionError => e
    e.message.should == "Something went wrong!"
  end
end


The problem with this pattern is that it gives a false positive when @object.failing_operation doesn't raise a PanicExceptionError.


This patch fixes these examples by using the raise_error matcher. The above example thus becomes:

it "should fail with a meaningful error message" do
  lambda {
    @object.failing_operation
  }.should raise_error(PanicExceptionError, "Something went wrong!")
end


These changes revealed one false positive in mock_spec.rb. I marked the example pending and added another example that demonstrates the current behavior.


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 06:46

Message:
Applied to r2682.

I think the pending example should pass and the other one should error out when calling the non-expected method. Looking into that now.

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

Comment By: Antti Tarvainen (tarvaina)
Date: 2007-09-26 17:11

Message:
Here's the actual patch file.

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

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

From noreply at rubyforge.org  Tue Oct  2 03:22:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 03:22:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14208 ] Fix to Mock#method_missing
	raising NameErrors instead of MockExpectationErrors
Message-ID: <20071002072236.3C9DBA970003@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Antti Tarvainen (tarvaina)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Fix to Mock#method_missing raising NameErrors instead of MockExpectationErrors

Initial Comment:
This patch fixes the nasty heisenbug in mock.rb. 


Symptom:
--------

Every now and then mocks would throw NameErrors instead of MockExpectationErrors when they received unexpected method calls -- but sure enough, not when running the program in a debugger.


Cause:
------

Ruby's Object#method_missing throws either NameErrors or NoMethodErrors.

On a fresh ruby program Object#method_missing raises: 
 * NoMethodError when called directly (object.method_missing :foo)
 * NameError when called indirectly (object.foo)

Once Object#method_missing has been called at least once (on any object)
it starts raising: 
 * NameError when called directly
 * NameError when called indirectly

It is also possible for method_missing to go back to the original state, but I don't know when this happens. 

Why Object#method_missing behaves this way, I have no idea. The version of Ruby I use is ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1].

Mock#method_missing relied on the assumption that calling Object#method_missing directly causes a NoMethodError to be raised.


Fix:
----

Mock#method_missing now converts all kinds of NameErrors (instead of just NoMethodErrors) into MockExpectationErrors.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 07:22

Message:
Applied to r2683.

Thank so much for fixing this one!

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

Comment By: Antti Tarvainen (tarvaina)
Date: 2007-09-25 05:47

Message:
Here's a test/unit test case that illustrates the weird
behavior of Object#method_missing. 

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

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

From noreply at rubyforge.org  Tue Oct  2 03:27:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 03:27:31 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14183 ] Tiny improvement on
	mock_spec.rb
Message-ID: <20071002072731.C1EE05240DDB@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Antti Tarvainen (tarvaina)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Tiny improvement on mock_spec.rb

Initial Comment:
Just a tiny patch to fix an example in mock_spec.rb. Now it doesn't break when you add more examples or rename the file.



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 07:27

Message:
Applied to r2684.

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

Comment By: Antti Tarvainen (tarvaina)
Date: 2007-09-24 13:45

Message:
(Forgot to check the upload box.)

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

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

From noreply at rubyforge.org  Tue Oct  2 03:38:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 03:38:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14186 ] Remove dead code from
	message_expecation.rb
Message-ID: <20071002073854.DCC195240DFD@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Antti Tarvainen (tarvaina)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Remove dead code from message_expecation.rb

Initial Comment:
This patch removes dead code from message_expectation.rb. The variable @exception_instance_to_raise was not used anywhere.




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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 07:38

Message:
Applied to r2685.

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

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

From dchelimsky at gmail.com  Tue Oct  2 14:02:17 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 2 Oct 2007 13:02:17 -0500
Subject: [rspec-devel] Rails 2.0 Preview Release and RSpec Trunk
Message-ID: <57c63afe0710021102g43b2c54fpd933266397185814@mail.gmail.com>

Hi all,

For those of you checking out the Rails 2.0 preview release:

RSpec-1.0.8 does not support Rails 2.0.

Unfortunately, we're in the middle of some big changes to the
internals in trunk and won't be in a position to do a release for
another week or so. Therefore, if you are using the Rails 2.0 preview,
you'll need to use the RSpec trunk.

Additionally, right now there is at least one known issue related to
Rails 2.0 and RSpec - however it was reported on the list and not in
the tracker. Please report bugs to the tracker. It's fine to talk
about them on the lists first, but they will almost certainly not get
addressed in RSpec unless/until you report them in the tracker. And,
of course, patches will get addressed faster than bug reports w/ no
solutions.

http://rspec.rubyforge.org/community/contribute.html

http://rubyforge.org/tracker/?group_id=797

Cheers,
David

From noreply at rubyforge.org  Tue Oct  2 14:10:55 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 14:10:55 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13760 ] False Positives on eql?()
Message-ID: <20071002181055.783E35240C2F@rubyforge.org>

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

Category: expectation module
Group: None
>Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Geoffrey Wiseman (diathesis)
>Assigned to: David Chelimsky (dchelimsky)
Summary: False Positives on eql?()

Initial Comment:
I accidentally typed:
  ob.should eql?(something)

This passed incorrectly.  It seems to be that I've essentially compared the 'something' value to the behavior object, and generated a false; by way of example, this also passes:
  ob.should false

Both of these are presumably dangerous false positives, particularly the former that's one keystroke away from the valid approach, and in keeping with eql? elsewhere, so it's an easy mistake to make.

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

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

Message:
This has been fairly well addressed by r2532 and subsequent patches (specifically 14156).

Closing this now.

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

Comment By: Geoffrey Wiseman (diathesis)
Date: 2007-09-08 14:34

Message:
Not a problem; the bug could have been more clear, I was
relying on the message to the list, but I woulda been happy
to set up a quick example.

Something like David describes seems sensible if that works.

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

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

Message:
Sorry - not an InvalidArgument error - just a NoMethod for now - at least you won't get a false positive on eql?().

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

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

Message:
I just committed a partial fix for this (r2532). If the matcher receives anything besides nil, it'll work was you expect (w/ an InvalidArgument error). I want to solve for nil before I close this, but the slam dunk I was expecting eluded me.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-08 00:15

Message:
should and should_not both take a matcher (an object that responds to matches?). If no matcher is passed, it handles operators (should == expected).

In the case of handling operators, nothing gets passed to should. My thinking is that if anything besides a matcher is passed to should, it should raise an InvalidArgument error.

WDYT?

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-09-07 22:32

Message:
Sorry, my bad - I just saw that you actually had posted on the list first, and having read the mail I understand what you mean.

How would you like RSpec to behave in the situation you describe? Can you describe that with a (failing) spec?

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-09-07 22:26

Message:
I don't understand what you mean, nor is there any complete code here I can execute to reproduce what you say is a bug.

Please submit some more complete code on the mailing list to make sure what you're talking about is a bug or not.

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

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

From noreply at rubyforge.org  Tue Oct  2 15:46:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 15:46:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14388 ] protect_against_forgery? helper
	method not being picked up by rspec_on_rails
Message-ID: <20071002194642.2325D5240E39@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jens-Christian Fischer (jcfischer)
Assigned to: Nobody (None)
Summary: protect_against_forgery? helper method not being picked up by rspec_on_rails

Initial Comment:
The new forgery protection is throwing of rspec:

NoMethodError in 'ApplicationHelper login-logout when logged in should show the name of the current user'
undefined method `protect_against_forgery?' for #<#<Class:0x3219118>:0x34e1f94>
/Users/jcf/dev/work/sim/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:41:in `method_missing'
/Users/jcf/dev/work/sim/app/helpers/application_helper.rb:8:in `login_logout'
./spec/helpers/application_helper_spec.rb:28:

I have looked into patching rspec to include the "protect_against_forgery?" helper, but it's included dynamically via a "helper_method :protect_against_forgery?" call in request_forgery_protection.rb

I have forged the forgery_protection by adding this to my spec_helper.rb

def protect_against_forgery?

end

Probably not the most elegant solution, but for now it works

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

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

From chad at spicycode.com  Tue Oct  2 16:00:38 2007
From: chad at spicycode.com (Chad Humphries)
Date: Tue, 2 Oct 2007 16:00:38 -0400
Subject: [rspec-devel] Rails 2.0 Preview Release and RSpec Trunk
In-Reply-To: <57c63afe0710021102g43b2c54fpd933266397185814@mail.gmail.com>
References: <57c63afe0710021102g43b2c54fpd933266397185814@mail.gmail.com>
Message-ID: <D6EAA14D-066A-4DF3-BDFC-6E56FF6E1BA7@spicycode.com>

So far it works great for me :)  We have a project going on edgerails/ 
edge rspec (internal project) and aside from adding in the  
protect_from_forgery? we have been great.

-Chad

On Oct 2, 2007, at 2:02 PM, David Chelimsky wrote:

> Hi all,
>
> For those of you checking out the Rails 2.0 preview release:
>
> RSpec-1.0.8 does not support Rails 2.0.
>
> Unfortunately, we're in the middle of some big changes to the
> internals in trunk and won't be in a position to do a release for
> another week or so. Therefore, if you are using the Rails 2.0 preview,
> you'll need to use the RSpec trunk.
>
> Additionally, right now there is at least one known issue related to
> Rails 2.0 and RSpec - however it was reported on the list and not in
> the tracker. Please report bugs to the tracker. It's fine to talk
> about them on the lists first, but they will almost certainly not get
> addressed in RSpec unless/until you report them in the tracker. And,
> of course, patches will get addressed faster than bug reports w/ no
> solutions.
>
> http://rspec.rubyforge.org/community/contribute.html
>
> http://rubyforge.org/tracker/?group_id=797
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Tue Oct  2 16:03:34 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 2 Oct 2007 15:03:34 -0500
Subject: [rspec-devel] Rails 2.0 Preview Release and RSpec Trunk
In-Reply-To: <D6EAA14D-066A-4DF3-BDFC-6E56FF6E1BA7@spicycode.com>
References: <57c63afe0710021102g43b2c54fpd933266397185814@mail.gmail.com>
	<D6EAA14D-066A-4DF3-BDFC-6E56FF6E1BA7@spicycode.com>
Message-ID: <57c63afe0710021303s7c7adc39l3e4dbc96584f7b17@mail.gmail.com>

On 10/2/07, Chad Humphries <chad at spicycode.com> wrote:
> So far it works great for me :)  We have a project going on edgerails/
> edge rspec (internal project) and aside from adding in the
> protect_from_forgery? we have been great.

Chad - do you have a solution for that? If so, would you consider
contributing a patch to
http://rubyforge.org/tracker/index.php?func=detail&aid=14388&group_id=797&atid=3149?

Thanks,
David

>
> -Chad
>
> On Oct 2, 2007, at 2:02 PM, David Chelimsky wrote:
>
> > Hi all,
> >
> > For those of you checking out the Rails 2.0 preview release:
> >
> > RSpec-1.0.8 does not support Rails 2.0.
> >
> > Unfortunately, we're in the middle of some big changes to the
> > internals in trunk and won't be in a position to do a release for
> > another week or so. Therefore, if you are using the Rails 2.0 preview,
> > you'll need to use the RSpec trunk.
> >
> > Additionally, right now there is at least one known issue related to
> > Rails 2.0 and RSpec - however it was reported on the list and not in
> > the tracker. Please report bugs to the tracker. It's fine to talk
> > about them on the lists first, but they will almost certainly not get
> > addressed in RSpec unless/until you report them in the tracker. And,
> > of course, patches will get addressed faster than bug reports w/ no
> > solutions.
> >
> > http://rspec.rubyforge.org/community/contribute.html
> >
> > http://rubyforge.org/tracker/?group_id=797
> >
> > 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 noreply at rubyforge.org  Tue Oct  2 18:00:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 18:00:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14391 ] .should respond_to()
	vs respond_to?()
Message-ID: <20071002220010.5682C5240E40@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Garrett Heaver (garrettheaver)
Assigned to: Nobody (None)
Summary: .should respond_to() vs respond_to?()

Initial Comment:
In Rails, when methods are declared on an association such as a has_many, these methods are not visible to the respond_to() rSpec method.

for example:

class Item < ActiveRecord::Base
has_many :translations do
    def active
        find(:first, :conditions => {:language_id, Language.active.id})
    end
end
end

it "should add an active method to the translations association" do
  @item.translations.should respond_to(:active)
end

^^ will never pass, however

it "should add an active method to the translations association" do
  @item.translations.respond_to?(:active).should be_true
end

^^ will pass

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

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

From noreply at rubyforge.org  Tue Oct  2 18:05:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 18:05:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14391 ] .should respond_to()
	vs respond_to?()
Message-ID: <20071002220543.3EE175240CDD@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Garrett Heaver (garrettheaver)
>Assigned to: David Chelimsky (dchelimsky)
Summary: .should respond_to() vs respond_to?()

Initial Comment:
In Rails, when methods are declared on an association such as a has_many, these methods are not visible to the respond_to() rSpec method.

for example:

class Item < ActiveRecord::Base
has_many :translations do
    def active
        find(:first, :conditions => {:language_id, Language.active.id})
    end
end
end

it "should add an active method to the translations association" do
  @item.translations.should respond_to(:active)
end

^^ will never pass, however

it "should add an active method to the translations association" do
  @item.translations.respond_to?(:active).should be_true
end

^^ will pass

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:05

Message:
This strikes me as a bug rather than a feature request - agree?

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

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

From noreply at rubyforge.org  Tue Oct  2 18:09:54 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 18:09:54 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14391 ] .should respond_to()
	vs respond_to?()
Message-ID: <20071002220954.6E2795240CDD@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Priority: 3
Submitted By: Garrett Heaver (garrettheaver)
Assigned to: David Chelimsky (dchelimsky)
Summary: .should respond_to() vs respond_to?()

Initial Comment:
In Rails, when methods are declared on an association such as a has_many, these methods are not visible to the respond_to() rSpec method.

for example:

class Item < ActiveRecord::Base
has_many :translations do
    def active
        find(:first, :conditions => {:language_id, Language.active.id})
    end
end
end

it "should add an active method to the translations association" do
  @item.translations.should respond_to(:active)
end

^^ will never pass, however

it "should add an active method to the translations association" do
  @item.translations.respond_to?(:active).should be_true
end

^^ will pass

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

>Comment By: Garrett Heaver (garrettheaver)
Date: 2007-10-02 22:09

Message:
If you think it belongs better as that David, absolutly.

I'm going to try and dig into it a bit myself but someone who knows the matcher 
better might well beat me to it.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:05

Message:
This strikes me as a bug rather than a feature request - agree?

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

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

From noreply at rubyforge.org  Tue Oct  2 18:28:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 18:28:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14254 ] Improved error handling for
	Object#should and Object#should_not
Message-ID: <20071002222816.3209B5240E61@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Antti Tarvainen (tarvaina)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Improved error handling for Object#should and Object#should_not

Initial Comment:
This patch improves the error handling of Object#should and Object#should_not methods. It does two things:

1. It causes an InvalidMatcherError to be raised when something else besides a matcher is given to a should expression as a parameter. Before the patch, the type of exception depended on context and was either NoMethodError or ExpectationNotMetError, depending on the context.

2. It catches cases where a nil parameter is given as a matcher. (There was a pending example in the specs for this one.)


Note that cases where no matcher argument is given to a should expression are not caught and will continue to give no warnings. I made a pending example for this but I doubt there's a way to solve it.

Summarising:

# These all will now raise InvalidMatcherError
object.should 5
object.should false
object.should nil
object.should eql?("foo")
object.should_not 5
object.should_not false
object.should_not nil
object.should_not eql?("foo")

# As before, these will pass without a warning
object.should
object.should_not


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:28

Message:
Applied to r2686.

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

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

From noreply at rubyforge.org  Tue Oct  2 18:30:57 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 18:30:57 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14152 ] Output warning when method is
	defined on a nil object.
Message-ID: <20071002223057.456375240E61@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ian Leitch (idl)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Output warning when method is defined on a nil object.

Initial Comment:
This patch causes define_expected_method to output a warning when a method is defined on a nil object.

This patch allows me to quickly resolve failing specs caused by typos.

e.g.:

before do
  @obj = mock('some object')
  @ob.stub!(:do_stuff)
end

it "should do something" do
    some_trigger
end

This will result in:

Warning: 'do_stuff' defined on a nil object at foo.rb:123.

This patch highlights some nil object stubs in the rspec's own specs. Most appear to be where the author hasn't bothered to use the method created in the before block (or not realized they were referencing a nil object). Although, one case identified in passing_mock_argument_constraints_spec.rb is where the "handling non-constraint arguments" behavior does not define 'it_should_behave_like "mock argument constraints"'.

Cheers
Ian

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:30

Message:
How would I specify this:

nil.should_receive(:some_message)

?????

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

Comment By: Ian Leitch (idl)
Date: 2007-09-22 19:18

Message:
By the way, if you accept this patch I'll go ahead and fix
all the warnings in rspec's specs.

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

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

From chad at spicycode.com  Tue Oct  2 18:42:34 2007
From: chad at spicycode.com (Chad Humphries)
Date: Tue, 2 Oct 2007 18:42:34 -0400
Subject: [rspec-devel] Rails 2.0 Preview Release and RSpec Trunk
In-Reply-To: <57c63afe0710021303s7c7adc39l3e4dbc96584f7b17@mail.gmail.com>
References: <57c63afe0710021102g43b2c54fpd933266397185814@mail.gmail.com>
	<D6EAA14D-066A-4DF3-BDFC-6E56FF6E1BA7@spicycode.com>
	<57c63afe0710021303s7c7adc39l3e4dbc96584f7b17@mail.gmail.com>
Message-ID: <75DE6780-C258-4D11-8FD8-42B8020ECCBE@spicycode.com>

Will look into and try to get something more formal (less hackish)  
together as a patch shortly.

-Chad

On Oct 2, 2007, at 4:03 PM, David Chelimsky wrote:

> On 10/2/07, Chad Humphries <chad at spicycode.com> wrote:
>> So far it works great for me :)  We have a project going on  
>> edgerails/
>> edge rspec (internal project) and aside from adding in the
>> protect_from_forgery? we have been great.
>
> Chad - do you have a solution for that? If so, would you consider
> contributing a patch to
> http://rubyforge.org/tracker/index.php? 
> func=detail&aid=14388&group_id=797&atid=3149?
>
> Thanks,
> David
>
>>
>> -Chad
>>
>> On Oct 2, 2007, at 2:02 PM, David Chelimsky wrote:
>>
>>> Hi all,
>>>
>>> For those of you checking out the Rails 2.0 preview release:
>>>
>>> RSpec-1.0.8 does not support Rails 2.0.
>>>
>>> Unfortunately, we're in the middle of some big changes to the
>>> internals in trunk and won't be in a position to do a release for
>>> another week or so. Therefore, if you are using the Rails 2.0  
>>> preview,
>>> you'll need to use the RSpec trunk.
>>>
>>> Additionally, right now there is at least one known issue related to
>>> Rails 2.0 and RSpec - however it was reported on the list and not in
>>> the tracker. Please report bugs to the tracker. It's fine to talk
>>> about them on the lists first, but they will almost certainly not  
>>> get
>>> addressed in RSpec unless/until you report them in the tracker. And,
>>> of course, patches will get addressed faster than bug reports w/ no
>>> solutions.
>>>
>>> http://rspec.rubyforge.org/community/contribute.html
>>>
>>> http://rubyforge.org/tracker/?group_id=797
>>>
>>> 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


From dchelimsky at gmail.com  Tue Oct  2 18:45:58 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 2 Oct 2007 17:45:58 -0500
Subject: [rspec-devel] Rails 2.0 Preview Release and RSpec Trunk
In-Reply-To: <75DE6780-C258-4D11-8FD8-42B8020ECCBE@spicycode.com>
References: <57c63afe0710021102g43b2c54fpd933266397185814@mail.gmail.com>
	<D6EAA14D-066A-4DF3-BDFC-6E56FF6E1BA7@spicycode.com>
	<57c63afe0710021303s7c7adc39l3e4dbc96584f7b17@mail.gmail.com>
	<75DE6780-C258-4D11-8FD8-42B8020ECCBE@spicycode.com>
Message-ID: <57c63afe0710021545o7becd8b3gd61b54530aa251a7@mail.gmail.com>

On 10/2/07, Chad Humphries <chad at spicycode.com> wrote:
> Will look into and try to get something more formal (less hackish)
> together as a patch shortly.

Thanks Chad - I appreciate it.

Cheers,
David

>
> -Chad
>
> On Oct 2, 2007, at 4:03 PM, David Chelimsky wrote:
>
> > On 10/2/07, Chad Humphries <chad at spicycode.com> wrote:
> >> So far it works great for me :)  We have a project going on
> >> edgerails/
> >> edge rspec (internal project) and aside from adding in the
> >> protect_from_forgery? we have been great.
> >
> > Chad - do you have a solution for that? If so, would you consider
> > contributing a patch to
> > http://rubyforge.org/tracker/index.php?
> > func=detail&aid=14388&group_id=797&atid=3149?
> >
> > Thanks,
> > David
> >
> >>
> >> -Chad
> >>
> >> On Oct 2, 2007, at 2:02 PM, David Chelimsky wrote:
> >>
> >>> Hi all,
> >>>
> >>> For those of you checking out the Rails 2.0 preview release:
> >>>
> >>> RSpec-1.0.8 does not support Rails 2.0.
> >>>
> >>> Unfortunately, we're in the middle of some big changes to the
> >>> internals in trunk and won't be in a position to do a release for
> >>> another week or so. Therefore, if you are using the Rails 2.0
> >>> preview,
> >>> you'll need to use the RSpec trunk.
> >>>
> >>> Additionally, right now there is at least one known issue related to
> >>> Rails 2.0 and RSpec - however it was reported on the list and not in
> >>> the tracker. Please report bugs to the tracker. It's fine to talk
> >>> about them on the lists first, but they will almost certainly not
> >>> get
> >>> addressed in RSpec unless/until you report them in the tracker. And,
> >>> of course, patches will get addressed faster than bug reports w/ no
> >>> solutions.
> >>>
> >>> http://rspec.rubyforge.org/community/contribute.html
> >>>
> >>> http://rubyforge.org/tracker/?group_id=797
> >>>
> >>> 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 noreply at rubyforge.org  Tue Oct  2 18:48:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 18:48:59 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14140 ] fix for TM when switching to
	alternate file
Message-ID: <20071002224859.C01895240BAD@rubyforge.org>

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

Category: RSpec.tmbundle
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Trevor Squires (protocool)
>Assigned to: David Chelimsky (dchelimsky)
Summary: fix for TM when switching to alternate file

Initial Comment:
When using textmate's ctrl-shift-downarrow (switch to "Alternate File") command I get exceptions of "undefined method + for NilClass".

Note: this *only* happens if the 'alternate file' you are trying to switch to does not exist, and you elect to let TM create it for you.

The problem appears to be down to content_for() incorrectly checking the file_type parameter.  It looks for 'spec' even though it would seem 'model spec' and 'view spec' are examples of the values it receives.

I've attached a patch which corrects this issue for me.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:48

Message:
Please add a spec that fails without this change and passes with it. There are specs in RSpec.tmbundle/Support. You can run them thusly:

cd RSpec.tmbundle/Support
rake spec

They were failing recently due to a bug that I just fixed, so please make sure you've got the most recent trunk.

Thanks.

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

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

From noreply at rubyforge.org  Tue Oct  2 18:57:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 18:57:43 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13412 ] Stop generating
	previous_failures.txt
Message-ID: <20071002225743.2E70A5240E2C@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: Closed
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
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-10-02 22:57

Message:
Closed by http://rubyforge.org/tracker/index.php?func=detail&aid=14095&group_id=797&atid=3151

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

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 noreply at rubyforge.org  Tue Oct  2 18:57:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 18:57:49 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14095 ] Don't have ./script/generate
	rspec create previous_failures.txt
Message-ID: <20071002225749.B24115240E60@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Don't have ./script/generate rspec create previous_failures.txt

Initial Comment:
An implementation for http://rubyforge.org/tracker/index.php?func=detail&aid=13412&group_id=797&atid=3152 . I couldn't figure out how to attach this to 
the other tracker item. Is that possible?

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:57

Message:
Applied to r2688.

Also closes 13412.

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

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

From noreply at rubyforge.org  Tue Oct  2 19:02:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 19:02:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14095 ] Don't have ./script/generate
	rspec create previous_failures.txt
Message-ID: <20071002230201.C7A965240E2C@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
Assigned to: David Chelimsky (dchelimsky)
Summary: Don't have ./script/generate rspec create previous_failures.txt

Initial Comment:
An implementation for http://rubyforge.org/tracker/index.php?func=detail&aid=13412&group_id=797&atid=3152 . I couldn't figure out how to attach this to 
the other tracker item. Is that possible?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-10-02 23:02

Message:
Thanks.  That's been annoying me.

Scott


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:57

Message:
Applied to r2688.

Also closes 13412.

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

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

From noreply at rubyforge.org  Tue Oct  2 19:03:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 19:03:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14043 ] Change output ordering to
	show pending before errors
Message-ID: <20071002230305.0241A5240E2C@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Mike Mangino (mmangino)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Change output ordering to show pending before errors

Initial Comment:
When running via the console, it's much nicer to see errors at the bottom of the screen. If you have a lot of pending specs, you have to scroll to see errors. That makes Red Green Refactor harder to do. This change moves the pending dump from the summary to the reporter object



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

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

Message:
Applied to r2689.

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

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

From noreply at rubyforge.org  Tue Oct  2 20:21:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue,  2 Oct 2007 20:21:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-8303 ] :nil_object option for mocks
Message-ID: <20071003002137.DA4505240E60@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-10-03 00:21

Message:
This is a couple of months old now. Anybody have thoughts about :null_object => :returns_nil?

How about :default => any_return_value?????

Then you could say :default => nil, but you could also say :default => "" in the case of views, etc.

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

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  Wed Oct  3 02:09:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 02:09:50 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14399 ] Show pending reasons in HTML
	report
Message-ID: <20071003060950.71674A970008@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
Assigned to: Nobody (None)
Summary: Show pending reasons in HTML report

Initial Comment:
Implements the feature request described in http://rubyforge.org/tracker/index.php?func=detail&aid=13856&group_id=797&atid=3152


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

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

From noreply at rubyforge.org  Wed Oct  3 02:10:20 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 02:10:20 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13856 ] Show Pending
	Messages in RSpec Report
Message-ID: <20071003061020.C0996A970008@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Geoffrey Wiseman (diathesis)
Assigned to: Nobody (None)
Summary: Show Pending Messages in RSpec Report

Initial Comment:
When the spec contains an explicit pending message, e.g.:

  describe "Secure passwords with MD5" do
    pending "Waiting on selection of an MD5 library."
  end

It'd be nice if this were visible in the RSpec HTML report.  Currently, the HTML report contains 'Secure passwords with MD5' as pending, but does not add the explanation as to why.


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

Comment By: Bryan Helmkamp (brynary)
Date: 2007-10-03 02:10

Message:
Patch submitted: http://rubyforge.org/tracker/index.php?func=detail&aid=14399&group_id=797&atid=3151

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

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

From noreply at rubyforge.org  Wed Oct  3 03:03:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 03:03:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14402 ] Add --profile option to show
	example options in specdoc
Message-ID: <20071003070335.B2D165240E8F@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
Assigned to: Nobody (None)
Summary: Add --profile option to show example options in specdoc

Initial Comment:
Implementation of http://rubyforge.org/tracker/index.php?func=detail&aid=13206&group_id=797&atid=3152

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

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

From noreply at rubyforge.org  Wed Oct  3 03:03:49 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 03:03:49 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13206 ] Individual Spec's
	Runtimes in Specdoc formatter
Message-ID: <20071003070349.C62AB5240E94@rubyforge.org>

Feature Requests item #13206, was opened at 2007-08-19 17: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)



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

Comment By: Bryan Helmkamp (brynary)
Date: 2007-10-03 03:03

Message:
Patch submitted: http://rubyforge.org/tracker/index.php?func=detail&aid=14402&group_id=797&atid=3151

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

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

From noreply at rubyforge.org  Wed Oct  3 06:30:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 06:30:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14406 ] rake spec:plugins:rspec_on_rails
	fails with Rails 2.0 preview release
Message-ID: <20071003103004.B10935240998@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Neil Wilson (aldursys)
Assigned to: Nobody (None)
Summary: rake spec:plugins:rspec_on_rails fails with Rails 2.0 preview release

Initial Comment:
File helper_spec_spec.rb still contains ActionView::Helpers::JavascriptMacrosHelper and ActionView::Helpers::PaginationHelper. 

Once you comment these out (which I'm sure isn't the correct fix), then you get failures due to a lack of fixtures.

Is it worth removing this task in Rake until you get the specs working?



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

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

From noreply at rubyforge.org  Wed Oct  3 08:14:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 08:14:14 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14399 ] Show pending reasons in HTML
	report
Message-ID: <20071003121415.286195240A4C@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
Assigned to: Nobody (None)
Summary: Show pending reasons in HTML report

Initial Comment:
Implements the feature request described in http://rubyforge.org/tracker/index.php?func=detail&aid=13856&group_id=797&atid=3152


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

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

Message:
I get failures when I apply this. Did you run the pre_commit?

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

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

From bkeepers at gmail.com  Wed Oct  3 09:00:23 2007
From: bkeepers at gmail.com (Brandon Keepers)
Date: Wed, 3 Oct 2007 09:00:23 -0400
Subject: [rspec-devel] Rails 2.0 Preview Release and RSpec Trunk
In-Reply-To: <57c63afe0710021303s7c7adc39l3e4dbc96584f7b17@mail.gmail.com>
References: <57c63afe0710021102g43b2c54fpd933266397185814@mail.gmail.com>
	<D6EAA14D-066A-4DF3-BDFC-6E56FF6E1BA7@spicycode.com>
	<57c63afe0710021303s7c7adc39l3e4dbc96584f7b17@mail.gmail.com>
Message-ID: <ABCD055B-8F81-47CB-9293-2D4641562E31@gmail.com>


On Oct 2, 2007, at 4:03 PM, David Chelimsky wrote:

> On 10/2/07, Chad Humphries <chad at spicycode.com> wrote:
>> So far it works great for me :)  We have a project going on  
>> edgerails/
>> edge rspec (internal project) and aside from adding in the
>> protect_from_forgery? we have been great.
>
> Chad - do you have a solution for that? If so, would you consider
> contributing a patch to
> http://rubyforge.org/tracker/index.php? 
> func=detail&aid=14388&group_id=797&atid=3149?

Throw this in environments/test.rb:

# Disable request forgery protection in test environment
config.action_controller.allow_forgery_protection    = false




From noreply at rubyforge.org  Wed Oct  3 10:04:13 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 10:04:13 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14406 ] rake spec:plugins:rspec_on_rails
	fails with Rails 2.0 preview release
Message-ID: <20071003140413.688795240B4D@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Neil Wilson (aldursys)
Assigned to: Nobody (None)
Summary: rake spec:plugins:rspec_on_rails fails with Rails 2.0 preview release

Initial Comment:
File helper_spec_spec.rb still contains ActionView::Helpers::JavascriptMacrosHelper and ActionView::Helpers::PaginationHelper. 

Once you comment these out (which I'm sure isn't the correct fix), then you get failures due to a lack of fixtures.

Is it worth removing this task in Rake until you get the specs working?



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

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

Message:
Absolutely not. Better to fix the problem than hide it, don't you think.

Resolved in r2691, which now passes against rails 1.2.1, 1.2.2, 1.2.3, 2.0.0 preview, and edge

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

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

From noreply at rubyforge.org  Wed Oct  3 10:56:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 10:56:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14406 ] rake spec:plugins:rspec_on_rails
	fails with Rails 2.0 preview release
Message-ID: <20071003145627.2D4EC5240B06@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Neil Wilson (aldursys)
>Assigned to: David Chelimsky (dchelimsky)
Summary: rake spec:plugins:rspec_on_rails fails with Rails 2.0 preview release

Initial Comment:
File helper_spec_spec.rb still contains ActionView::Helpers::JavascriptMacrosHelper and ActionView::Helpers::PaginationHelper. 

Once you comment these out (which I'm sure isn't the correct fix), then you get failures due to a lack of fixtures.

Is it worth removing this task in Rake until you get the specs working?



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

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

Message:
Forgot to close this.

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

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

Message:
Absolutely not. Better to fix the problem than hide it, don't you think.

Resolved in r2691, which now passes against rails 1.2.1, 1.2.2, 1.2.3, 2.0.0 preview, and edge

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

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

From noreply at rubyforge.org  Wed Oct  3 11:49:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 11:49:43 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14399 ] Show pending reasons in HTML
	report
Message-ID: <20071003154943.82B585240B82@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
Assigned to: Nobody (None)
Summary: Show pending reasons in HTML report

Initial Comment:
Implements the feature request described in http://rubyforge.org/tracker/index.php?func=detail&aid=13856&group_id=797&atid=3152


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

>Comment By: Bryan Helmkamp (brynary)
Date: 2007-10-03 11:49

Message:
David -- Yes, I ran pre_commit and got the "OK TO COMMIT"
output.

I just applied the patch on a clean working copy (at r2691),
and ran it again. Results were:

All specs passed against the following released versions of
Rails: edge, 2.0.0, 1.2.3, 1.2.2, 1.2.1
OK TO COMMIT

Ruby version is ruby 1.8.5 (2006-12-25 patchlevel 12)
[i686-darwin8.8.1].



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

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

Message:
I get failures when I apply this. Did you run the pre_commit?

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

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

From noreply at rubyforge.org  Wed Oct  3 12:35:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 12:35:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14152 ] Output warning when method is
	defined on a nil object.
Message-ID: <20071003163532.E9A1D5240D04@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ian Leitch (idl)
Assigned to: David Chelimsky (dchelimsky)
Summary: Output warning when method is defined on a nil object.

Initial Comment:
This patch causes define_expected_method to output a warning when a method is defined on a nil object.

This patch allows me to quickly resolve failing specs caused by typos.

e.g.:

before do
  @obj = mock('some object')
  @ob.stub!(:do_stuff)
end

it "should do something" do
    some_trigger
end

This will result in:

Warning: 'do_stuff' defined on a nil object at foo.rb:123.

This patch highlights some nil object stubs in the rspec's own specs. Most appear to be where the author hasn't bothered to use the method created in the before block (or not realized they were referencing a nil object). Although, one case identified in passing_mock_argument_constraints_spec.rb is where the "handling non-constraint arguments" behavior does not define 'it_should_behave_like "mock argument constraints"'.

Cheers
Ian

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

>Comment By: Ian Leitch (idl)
Date: 2007-10-03 16:35

Message:
You wouldn't, is that even a valid use case?

Please correct me, but from what I understand, someone
stubbing on nil directly is being lazy and not bothering to
create mock objects. Also, stubbing on a global object like
that could lead to expected (and very hard to debug) behavior.

This patch has been very handy for myself and my fellow
employees, it'd be a shame if it were completely rejected.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:30

Message:
How would I specify this:

nil.should_receive(:some_message)

?????

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

Comment By: Ian Leitch (idl)
Date: 2007-09-22 19:18

Message:
By the way, if you accept this patch I'll go ahead and fix
all the warnings in rspec's specs.

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

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

From noreply at rubyforge.org  Wed Oct  3 12:42:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 12:42:51 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14152 ] Output warning when method is
	defined on a nil object.
Message-ID: <20071003164251.C9A3F5240B4D@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ian Leitch (idl)
Assigned to: David Chelimsky (dchelimsky)
Summary: Output warning when method is defined on a nil object.

Initial Comment:
This patch causes define_expected_method to output a warning when a method is defined on a nil object.

This patch allows me to quickly resolve failing specs caused by typos.

e.g.:

before do
  @obj = mock('some object')
  @ob.stub!(:do_stuff)
end

it "should do something" do
    some_trigger
end

This will result in:

Warning: 'do_stuff' defined on a nil object at foo.rb:123.

This patch highlights some nil object stubs in the rspec's own specs. Most appear to be where the author hasn't bothered to use the method created in the before block (or not realized they were referencing a nil object). Although, one case identified in passing_mock_argument_constraints_spec.rb is where the "handling non-constraint arguments" behavior does not define 'it_should_behave_like "mock argument constraints"'.

Cheers
Ian

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-03 16:42

Message:
Sure it's a valid use case! Any time you have code that has to interact with nil in some way, you might want to say nil.stub!(:some_message) or nil.should_receive(:some_message).

We mock/stub globals all the time. Think Rails finder methods. They get cleared out after each example, so while there is risk of odd behaviour within a given example (if you don't understand what you're doing), it doesn't bleed out to the rest of the system.

As for rejecting it - it hasn't been rejected yet partially or completely. I simply asked a question, which I now reiterate:

How would I specify nil.should_receive(:some_message).

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

Comment By: Ian Leitch (idl)
Date: 2007-10-03 16:35

Message:
You wouldn't, is that even a valid use case?

Please correct me, but from what I understand, someone
stubbing on nil directly is being lazy and not bothering to
create mock objects. Also, stubbing on a global object like
that could lead to expected (and very hard to debug) behavior.

This patch has been very handy for myself and my fellow
employees, it'd be a shame if it were completely rejected.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-02 22:30

Message:
How would I specify this:

nil.should_receive(:some_message)

?????

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

Comment By: Ian Leitch (idl)
Date: 2007-09-22 19:18

Message:
By the way, if you accept this patch I'll go ahead and fix
all the warnings in rspec's specs.

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

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

From noreply at rubyforge.org  Wed Oct  3 14:09:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed,  3 Oct 2007 14:09:43 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14406 ] rake spec:plugins:rspec_on_rails
	fails with Rails 2.0 preview release
Message-ID: <20071003180943.2101F5240C72@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Neil Wilson (aldursys)
Assigned to: David Chelimsky (dchelimsky)
Summary: rake spec:plugins:rspec_on_rails fails with Rails 2.0 preview release

Initial Comment:
File helper_spec_spec.rb still contains ActionView::Helpers::JavascriptMacrosHelper and ActionView::Helpers::PaginationHelper. 

Once you comment these out (which I'm sure isn't the correct fix), then you get failures due to a lack of fixtures.

Is it worth removing this task in Rake until you get the specs working?



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

>Comment By: Neil Wilson (aldursys)
Date: 2007-10-03 18:09

Message:
r2691 still can't find the fixtures specified in 
helper_spec_spec.rb when the Rake task is run from an 
arbitrary Rails app.




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

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

Message:
Forgot to close this.

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

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

Message:
Absolutely not. Better to fix the problem than hide it, don't you think.

Resolved in r2691, which now passes against rails 1.2.1, 1.2.2, 1.2.3, 2.0.0 preview, and edge

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

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

From noreply at rubyforge.org  Thu Oct  4 13:00:34 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  4 Oct 2007 13:00:34 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-8001 ] separate out routing
	specs
Message-ID: <20071004170034.23F025240A75@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: separate out routing specs

Initial Comment:
Routing happens outside of controllers and should be spec'able separately from controllers. This should be either part of a higher level integration spec or Story Runner, OR should be a new component category parallel w/ models, views, controllers and helpers.

Routing specs should support both route processing and route generation. For example:

route_for(:controller => "people", :action => "edit", :id => 1).should == "/people/1;edit"

AND

"/people/1;edit".should route_to(:controller => "people", :action => "edit", :id => 1)

The latter example would be extremely useful for custom mappings like this:

"/".should route_to(:controller => 'welcome')


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

Comment By: Matt Scilipoti (mattscilipoti)
Date: 2007-10-04 12:00

Message:
+1.  This looks like a good format to me.

Note: On edge, url format has changed from "/people/1;edit" to "/people/1/edit"

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-19 11:34

Message:
I'd LOVE to take credit for it, but it comes from a comment by Eric Peden to [#6541]:

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

Thanks for the idea Eric!

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-19 10:00

Message:
I LOVE that idea.

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

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

From noreply at rubyforge.org  Thu Oct  4 16:46:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  4 Oct 2007 16:46:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-8001 ] separate out routing
	specs
Message-ID: <20071004204629.070685240D33@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: separate out routing specs

Initial Comment:
Routing happens outside of controllers and should be spec'able separately from controllers. This should be either part of a higher level integration spec or Story Runner, OR should be a new component category parallel w/ models, views, controllers and helpers.

Routing specs should support both route processing and route generation. For example:

route_for(:controller => "people", :action => "edit", :id => 1).should == "/people/1;edit"

AND

"/people/1;edit".should route_to(:controller => "people", :action => "edit", :id => 1)

The latter example would be extremely useful for custom mappings like this:

"/".should route_to(:controller => 'welcome')


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

Comment By: Rupert Voelcker (rupert)
Date: 2007-10-04 21:46

Message:
you can actually specify routes the other way round using params_from with the following syntax:

params_from(:get, '/people/1/edit').should == {:controller => "people", :action => "edit", :id => "1"}

although route_to is a bit more suggestive of what it does. Then perhaps route_from should be aliased to route_for so there's a route_to and a route_from.

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

Comment By: Matt Scilipoti (mattscilipoti)
Date: 2007-10-04 18:00

Message:
+1.  This looks like a good format to me.

Note: On edge, url format has changed from "/people/1;edit" to "/people/1/edit"

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-01-19 16:34

Message:
I'd LOVE to take credit for it, but it comes from a comment by Eric Peden to [#6541]:

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

Thanks for the idea Eric!

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-01-19 15:00

Message:
I LOVE that idea.

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

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

From noreply at rubyforge.org  Thu Oct  4 17:51:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu,  4 Oct 2007 17:51:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-13777 ] run last example action in
	textmate bundle
Message-ID: <20071004215128.275655240D3C@rubyforge.org>

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

Category: RSpec.tmbundle
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jeremy Stell-Smith (stellsmi)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: run last example action in textmate bundle

Initial Comment:
This patch records every action you do in the textmate plugin and will rerun it.

For example, go to a file, run a spec, go to a different file, and then cmd-shift-i, the last spec will be run

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

>Comment By: Jeremy Stell-Smith (stellsmi)
Date: 2007-10-04 14:51

Message:
I added it a while back,

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-09-08 14:46

Message:
You forgot to check the box when attaching the patch Jeremy :-/

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

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

From noreply at rubyforge.org  Fri Oct  5 06:40:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  5 Oct 2007 06:40:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14475 ] Tempfile doesn't pass
	be_an_instance_of(Tempfile). Maybe becouse it use decorator
Message-ID: <20071005104004.916805240AFC@rubyforge.org>

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

Category: expectation module
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Serhiy Boiko (cris)
Assigned to: Nobody (None)
Summary: Tempfile doesn't pass be_an_instance_of(Tempfile). Maybe becouse it use decorator

Initial Comment:
describe "My problem" do

  it "should pass be_an_instance_of for newly created Tempfile" do
    # create test object
    xml_tempfile = Tempfile.new "object.xml"
    xml_tempfile.close
    # this kind of test passed normally
    xml_tempfile.class.should eql(Tempfile)
    # this doesn't pass
    xml_tempfile.should be_an_instance_of(Tempfile)
  end
end

In ruby-debug I found, that in validation stage, object become instance of File. Maybe something unwrap Delegator in Tempfile?

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

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

From noreply at rubyforge.org  Fri Oct  5 07:53:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  5 Oct 2007 07:53:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14475 ] Tempfile doesn't pass
	be_an_instance_of(Tempfile). Maybe becouse it use decorator
Message-ID: <20071005115319.B5F305240AD5@rubyforge.org>

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

Category: expectation module
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Serhiy Boiko (cris)
>Assigned to: David Chelimsky (dchelimsky)
Summary: Tempfile doesn't pass be_an_instance_of(Tempfile). Maybe becouse it use decorator

Initial Comment:
describe "My problem" do

  it "should pass be_an_instance_of for newly created Tempfile" do
    # create test object
    xml_tempfile = Tempfile.new "object.xml"
    xml_tempfile.close
    # this kind of test passed normally
    xml_tempfile.class.should eql(Tempfile)
    # this doesn't pass
    xml_tempfile.should be_an_instance_of(Tempfile)
  end
end

In ruby-debug I found, that in validation stage, object become instance of File. Maybe something unwrap Delegator in Tempfile?

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-05 11:53

Message:
This is related to http://rubyforge.org/tracker/index.php?func=detail&aid=11526&group_id=797&atid=3149.

Check this out - if you require in this order:

require 'spec'
require 'tempfile'

Then your example fails. However, if you require in this order:

require 'tempfile'
require 'spec'

Then the example passes!




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

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

From noreply at rubyforge.org  Fri Oct  5 09:51:11 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  5 Oct 2007 09:51:11 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14475 ] Tempfile doesn't pass
	be_an_instance_of(Tempfile). Maybe becouse it use decorator
Message-ID: <20071005135111.805575240B97@rubyforge.org>

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

Category: expectation module
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Serhiy Boiko (cris)
Assigned to: David Chelimsky (dchelimsky)
Summary: Tempfile doesn't pass be_an_instance_of(Tempfile). Maybe becouse it use decorator

Initial Comment:
describe "My problem" do

  it "should pass be_an_instance_of for newly created Tempfile" do
    # create test object
    xml_tempfile = Tempfile.new "object.xml"
    xml_tempfile.close
    # this kind of test passed normally
    xml_tempfile.class.should eql(Tempfile)
    # this doesn't pass
    xml_tempfile.should be_an_instance_of(Tempfile)
  end
end

In ruby-debug I found, that in validation stage, object become instance of File. Maybe something unwrap Delegator in Tempfile?

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

>Comment By: Serhiy Boiko (cris)
Date: 2007-10-05 16:51

Message:
Thanks a lot.
Its work.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-05 14:53

Message:
This is related to http://rubyforge.org/tracker/index.php?func=detail&aid=11526&group_id=797&atid=3149.

Check this out - if you require in this order:

require 'spec'
require 'tempfile'

Then your example fails. However, if you require in this order:

require 'tempfile'
require 'spec'

Then the example passes!




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

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

From noreply at rubyforge.org  Fri Oct  5 09:56:31 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri,  5 Oct 2007 09:56:31 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14475 ] Tempfile doesn't pass
	be_an_instance_of(Tempfile). Maybe becouse it use decorator
Message-ID: <20071005135631.E83C55240C32@rubyforge.org>

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

Category: expectation module
Group: v1.0 (example)
Status: Open
Resolution: None
Priority: 3
Submitted By: Serhiy Boiko (cris)
Assigned to: David Chelimsky (dchelimsky)
Summary: Tempfile doesn't pass be_an_instance_of(Tempfile). Maybe becouse it use decorator

Initial Comment:
describe "My problem" do

  it "should pass be_an_instance_of for newly created Tempfile" do
    # create test object
    xml_tempfile = Tempfile.new "object.xml"
    xml_tempfile.close
    # this kind of test passed normally
    xml_tempfile.class.should eql(Tempfile)
    # this doesn't pass
    xml_tempfile.should be_an_instance_of(Tempfile)
  end
end

In ruby-debug I found, that in validation stage, object become instance of File. Maybe something unwrap Delegator in Tempfile?

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-05 13:56

Message:
It works - but you shouldn't have to switch the requires. I'd say its still a bug.

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

Comment By: Serhiy Boiko (cris)
Date: 2007-10-05 13:51

Message:
Thanks a lot.
Its work.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-05 11:53

Message:
This is related to http://rubyforge.org/tracker/index.php?func=detail&aid=11526&group_id=797&atid=3149.

Check this out - if you require in this order:

require 'spec'
require 'tempfile'

Then your example fails. However, if you require in this order:

require 'tempfile'
require 'spec'

Then the example passes!




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

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

From noreply at rubyforge.org  Sat Oct  6 11:36:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  6 Oct 2007 11:36:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14304 ] Specify the
	controller request in the description options
Message-ID: <20071006153605.1AD57A970006@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jonathan Leighton (jonleighton)
Assigned to: Nobody (None)
Summary: Specify the controller request in the description options

Initial Comment:
I was experimenting with metaprogramming some of my examples, in order to keep my specs DRY, and I needed some way to programmatically specify what the request being tested was. I came up with this:

describe ArticlesController, :request => { :get => :show, :id => 53 } do
  it "should find the article" do
    Article.expects(:find).with(53)
    send_request
  end
end

Here is my code: http://pastie.caboo.se/101764

I would be willing to make this into a patch if it sounds like a good idea?

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

>Comment By: Jonathan Leighton (jonleighton)
Date: 2007-10-06 15:36

Message:
Mike: I agree with you in general but I created it in order
to solve the problem of knowing what request to use if I was
defining my own example generator such as
"it_should_redirect_to :index".

I guess another approach might be to have the last argument
specify the request, eg:

it_should_redirect_to :index, :get => :create

I'm going to stick a post on my blog about it, though I
doubt many people will read that ;)

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

Comment By: Mike Mangino (mmangino)
Date: 2007-10-01 01:16

Message:
I don't care for this at all. If you want this behavior, you could easily define the send_request method yourself. It just seems like a really obscure syntax. I'd rather the action performed by send_request be made more explicit.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-30 15:05

Message:
It sounds like a good idea, but I'd like to get more feedback first.

How about blogging it or releasing it as a plugin so people can get some experience with it. If the feedback is generally positive I'd be open to adding it.

The only reason I'm not jumping on it is that I've been feeling as though RSpec has become too bloated as it is, and I'm hesitant to add any new features without careful consideration.

It does sound like a good idea, and I'll be exploring it myself on my own projects.

Cheers,
David

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

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

From noreply at rubyforge.org  Sat Oct  6 14:08:03 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat,  6 Oct 2007 14:08:03 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14304 ] Specify the
	controller request in the description options
Message-ID: <20071006180803.A784CA970006@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Priority: 3
Submitted By: Jonathan Leighton (jonleighton)
Assigned to: Nobody (None)
Summary: Specify the controller request in the description options

Initial Comment:
I was experimenting with metaprogramming some of my examples, in order to keep my specs DRY, and I needed some way to programmatically specify what the request being tested was. I came up with this:

describe ArticlesController, :request => { :get => :show, :id => 53 } do
  it "should find the article" do
    Article.expects(:find).with(53)
    send_request
  end
end

Here is my code: http://pastie.caboo.se/101764

I would be willing to make this into a patch if it sounds like a good idea?

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-10-06 18:08

Message:
Personally, I really like this option.  I've found myself doing the same thing over and over again:

describe SomeController do
  def do_action
    get :something, :id => 1
  end

  it "should blah blah" do
    do_action
    assertion
  end

  it "should do blah blah" do
    assertion
    do_action
  end

  # ...

end


The question is not whether RSpec is too bloated (nor that the example is not DRY)- the question is if it makes the tests more *readable* or understandable.  Maybe with the right syntax it would.  

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

Comment By: Jonathan Leighton (jonleighton)
Date: 2007-10-06 15:36

Message:
Mike: I agree with you in general but I created it in order
to solve the problem of knowing what request to use if I was
defining my own example generator such as
"it_should_redirect_to :index".

I guess another approach might be to have the last argument
specify the request, eg:

it_should_redirect_to :index, :get => :create

I'm going to stick a post on my blog about it, though I
doubt many people will read that ;)

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

Comment By: Mike Mangino (mmangino)
Date: 2007-10-01 01:16

Message:
I don't care for this at all. If you want this behavior, you could easily define the send_request method yourself. It just seems like a really obscure syntax. I'd rather the action performed by send_request be made more explicit.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-30 15:05

Message:
It sounds like a good idea, but I'd like to get more feedback first.

How about blogging it or releasing it as a plugin so people can get some experience with it. If the feedback is generally positive I'd be open to adding it.

The only reason I'm not jumping on it is that I've been feeling as though RSpec has become too bloated as it is, and I'm hesitant to add any new features without careful consideration.

It does sound like a good idea, and I'll be exploring it myself on my own projects.

Cheers,
David

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

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

From dchelimsky at gmail.com  Sun Oct  7 05:57:23 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 7 Oct 2007 04:57:23 -0500
Subject: [rspec-devel] rails versions
Message-ID: <57c63afe0710070257u1f93ecc7id4c68eb23cc9294@mail.gmail.com>

Hey all,

I added rails 1.2.4 and 2.0.0 preview to the pre-commit, increasing
the number of rails versions to 6. As you can imagine, it takes
forever. I set out to speed things up by running against sqlite3
in-memory and found that this was not supported in rails 1.2.1 (no
adapter).

Last we talked about this, we agreed to always support the latest
release plus two previous releases of rails (plus edge).

Based on that and the sqlite3 problem, I've yanked 1.2.1 from the
pre-commit for now. The pre-commit now runs against rails 1.2.2,
1.2.3, 1.2.4, 2.0.0-preview and edge.

If you're running the pre-commit, you can delete
example_rails_app/vendor/rails/1.2.1.

Cheers,
David

From mailing_lists at railsnewbie.com  Sun Oct  7 10:13:21 2007
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Sun, 7 Oct 2007 10:13:21 -0400
Subject: [rspec-devel] rails versions
In-Reply-To: <57c63afe0710070257u1f93ecc7id4c68eb23cc9294@mail.gmail.com>
References: <57c63afe0710070257u1f93ecc7id4c68eb23cc9294@mail.gmail.com>
Message-ID: <5034C734-A1D3-4D42-9928-1EA2849DC2CD@railsnewbie.com>


On Oct 7, 2007, at 5:57 AM, David Chelimsky wrote:

> Hey all,
>
> I added rails 1.2.4 and 2.0.0 preview to the pre-commit, increasing
> the number of rails versions to 6. As you can imagine, it takes
> forever. I set out to speed things up by running against sqlite3
> in-memory and found that this was not supported in rails 1.2.1 (no
> adapter).

Wasn't I rooting for this, back in rspec 0.7?

Anyway, do you think you could post the speed difference that you see  
with sqlite3 in memory and mysql?

Scott

From dchelimsky at gmail.com  Sun Oct  7 11:21:50 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 7 Oct 2007 10:21:50 -0500
Subject: [rspec-devel] rails versions
In-Reply-To: <5034C734-A1D3-4D42-9928-1EA2849DC2CD@railsnewbie.com>
References: <57c63afe0710070257u1f93ecc7id4c68eb23cc9294@mail.gmail.com>
	<5034C734-A1D3-4D42-9928-1EA2849DC2CD@railsnewbie.com>
Message-ID: <57c63afe0710070821o491b9b29uea3766b87191ec6@mail.gmail.com>

On 10/7/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
>
> On Oct 7, 2007, at 5:57 AM, David Chelimsky wrote:
>
> > Hey all,
> >
> > I added rails 1.2.4 and 2.0.0 preview to the pre-commit, increasing
> > the number of rails versions to 6. As you can imagine, it takes
> > forever. I set out to speed things up by running against sqlite3
> > in-memory and found that this was not supported in rails 1.2.1 (no
> > adapter).
>
> Wasn't I rooting for this, back in rspec 0.7?

We weren't ready to dispense with 1.2.1 until now (that there are
sufficient subsequent releases).

> Anyway, do you think you could post the speed difference that you see
> with sqlite3 in memory and mysql?

This is not scientific - I ran each once and timed it w/ an external
time source - but here's what I got:

mysql  4:23
sqlite3 2:54

This includes running all the rspec core examples plus the
rspec_on_rails plugin examples against 5 versions of rails.

Cheers,
David


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

From noreply at rubyforge.org  Sun Oct  7 19:52:29 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  7 Oct 2007 19:52:29 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14527 ] specs run twice on rails 1.2.4
	and rspec/rspec_on_rails trunk
Message-ID: <20071007235229.C69D55240BAD@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Jack Dempsey (jackdempsey)
Assigned to: Nobody (None)
Summary: specs run twice on rails 1.2.4 and rspec/rspec_on_rails trunk

Initial Comment:
I think this might be related to the Textmate 'specs run twice' bug entered on 9/10.

I'm using rails 1.2.4 and trunk on both rspec and rspec_on_rails and i'm noticing things running twice:

~/spec_example $ rake spec
(in /Users/jdempsey/spec_example)

      *******************************************************************
      * config.breakpoint_server has been deprecated and has no effect. *
      *******************************************************************
      


Finished in 0.002407 seconds

0 examples, 0 failures


Finished in 9.0e-06 seconds

0 examples, 0 failures


You can easily duplicate this by creating a skeleton rails app, freezing to edge, checking out the trunk of rspec and rspec_on_rails plugins, creating the db's and running rake spec. 

I saw two mentions of this on ohloh when i was looking around before:

Aug 22 2007 23:08  	aslak.hellesoy (aslak_hellesoy)  	Moved Spec::Distributed to rspec-ext project,

Sep 21 2007 11:33  	btakita  	Fixed bin/spec running the specs twice issue (I think) [Details] removed mtime/reverse to get
 more consistent running, removed rspec_suite.rb since it broke 'ruby bin/spec spec' (things got loaded twice) [Details]


I couldn't quite figure out why things aren't working, but I do know that when you remove this from lib/spec.rb:

at_exit do
  unless rspec_options.examples_run?; exit rspec_options.run_examples; end
end

things don't run twice...

So, any thoughts? I'm going to see if I can figure out why and will submit a patch if so, but wanted to bring this up to start things off. 

Thanks!

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

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

From noreply at rubyforge.org  Sun Oct  7 20:56:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  7 Oct 2007 20:56:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14527 ] specs run twice on rails 1.2.4
	and rspec/rspec_on_rails trunk
Message-ID: <20071008005639.710945240A4D@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Jack Dempsey (jackdempsey)
>Assigned to: David Chelimsky (dchelimsky)
Summary: specs run twice on rails 1.2.4 and rspec/rspec_on_rails trunk

Initial Comment:
I think this might be related to the Textmate 'specs run twice' bug entered on 9/10.

I'm using rails 1.2.4 and trunk on both rspec and rspec_on_rails and i'm noticing things running twice:

~/spec_example $ rake spec
(in /Users/jdempsey/spec_example)

      *******************************************************************
      * config.breakpoint_server has been deprecated and has no effect. *
      *******************************************************************
      


Finished in 0.002407 seconds

0 examples, 0 failures


Finished in 9.0e-06 seconds

0 examples, 0 failures


You can easily duplicate this by creating a skeleton rails app, freezing to edge, checking out the trunk of rspec and rspec_on_rails plugins, creating the db's and running rake spec. 

I saw two mentions of this on ohloh when i was looking around before:

Aug 22 2007 23:08  	aslak.hellesoy (aslak_hellesoy)  	Moved Spec::Distributed to rspec-ext project,

Sep 21 2007 11:33  	btakita  	Fixed bin/spec running the specs twice issue (I think) [Details] removed mtime/reverse to get
 more consistent running, removed rspec_suite.rb since it broke 'ruby bin/spec spec' (things got loaded twice) [Details]


I couldn't quite figure out why things aren't working, but I do know that when you remove this from lib/spec.rb:

at_exit do
  unless rspec_options.examples_run?; exit rspec_options.run_examples; end
end

things don't run twice...

So, any thoughts? I'm going to see if I can figure out why and will submit a patch if so, but wanted to bring this up to start things off. 

Thanks!

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

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

Message:
Fixed in r2700

I think those lines in spec.rb are residual from a refactoring we are currently working on. I've removed them and all seems well for the moment.

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

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

From noreply at rubyforge.org  Sun Oct  7 21:01:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun,  7 Oct 2007 21:01:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14527 ] specs run twice on rails 1.2.4
	and rspec/rspec_on_rails trunk
Message-ID: <20071008010136.61EF05240BAD@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Jack Dempsey (jackdempsey)
Assigned to: David Chelimsky (dchelimsky)
Summary: specs run twice on rails 1.2.4 and rspec/rspec_on_rails trunk

Initial Comment:
I think this might be related to the Textmate 'specs run twice' bug entered on 9/10.

I'm using rails 1.2.4 and trunk on both rspec and rspec_on_rails and i'm noticing things running twice:

~/spec_example $ rake spec
(in /Users/jdempsey/spec_example)

      *******************************************************************
      * config.breakpoint_server has been deprecated and has no effect. *
      *******************************************************************
      


Finished in 0.002407 seconds

0 examples, 0 failures


Finished in 9.0e-06 seconds

0 examples, 0 failures


You can easily duplicate this by creating a skeleton rails app, freezing to edge, checking out the trunk of rspec and rspec_on_rails plugins, creating the db's and running rake spec. 

I saw two mentions of this on ohloh when i was looking around before:

Aug 22 2007 23:08  	aslak.hellesoy (aslak_hellesoy)  	Moved Spec::Distributed to rspec-ext project,

Sep 21 2007 11:33  	btakita  	Fixed bin/spec running the specs twice issue (I think) [Details] removed mtime/reverse to get
 more consistent running, removed rspec_suite.rb since it broke 'ruby bin/spec spec' (things got loaded twice) [Details]


I couldn't quite figure out why things aren't working, but I do know that when you remove this from lib/spec.rb:

at_exit do
  unless rspec_options.examples_run?; exit rspec_options.run_examples; end
end

things don't run twice...

So, any thoughts? I'm going to see if I can figure out why and will submit a patch if so, but wanted to bring this up to start things off. 

Thanks!

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

>Comment By: Jack Dempsey (jackdempsey)
Date: 2007-10-07 20:01

Message:
Awesome David, thanks for such a quick response, everything
looks great!

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-07 19:56

Message:
Fixed in r2700

I think those lines in spec.rb are residual from a refactoring we are currently working on. I've removed them and all seems well for the moment.

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

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

From noreply at rubyforge.org  Mon Oct  8 02:02:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  8 Oct 2007 02:02:22 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14532 ] 'ruby some_spec.rb' does not run
	the spec
Message-ID: <20071008060222.2BD285240DB8@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: 'ruby some_spec.rb' does not run the spec

Initial Comment:
The Fixed [#14527] specs run twice on rails 1.2.4 and rspec/rspec_on_rails trunk checkin seems to have broken this.

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

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

From noreply at rubyforge.org  Mon Oct  8 03:09:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  8 Oct 2007 03:09:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14532 ] 'ruby some_spec.rb' does not run
	the spec
Message-ID: <20071008070919.91D7E5240E66@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: 'ruby some_spec.rb' does not run the spec

Initial Comment:
The Fixed [#14527] specs run twice on rails 1.2.4 and rspec/rspec_on_rails trunk checkin seems to have broken this.

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

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

From noreply at rubyforge.org  Mon Oct  8 08:22:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  8 Oct 2007 08:22:25 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14543 ] rspec_scaffold broken with Rails
	2.0
Message-ID: <20071008122227.1095E5240A1C@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Steven Garcia (pimpmaster)
Assigned to: Nobody (None)
Summary: rspec_scaffold broken with Rails 2.0

Initial Comment:
Rails Edge r7774
Rspec Trunk r2701

Trying to run:

script/generate rspec_scaffold Thing

and I get

uninitialized constant Rails::VERSION::String

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

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

From noreply at rubyforge.org  Mon Oct  8 08:23:39 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon,  8 Oct 2007 08:23:39 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14543 ] rspec_scaffold broken with Rails
	2.0
Message-ID: <20071008122339.DC635524098C@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Steven Garcia (pimpmaster)
Assigned to: Nobody (None)
Summary: rspec_scaffold broken with Rails 2.0

Initial Comment:
Rails Edge r7774
Rspec Trunk r2701

Trying to run:

script/generate rspec_scaffold Thing

and I get

uninitialized constant Rails::VERSION::String

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

>Comment By: Steven Garcia (pimpmaster)
Date: 2007-10-08 12:23

Message:
BTW, this is on OS 10.4.10

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

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

From mvanholstyn at gmail.com  Mon Oct  8 23:18:06 2007
From: mvanholstyn at gmail.com (Mark Van Holstyn)
Date: Mon, 8 Oct 2007 23:18:06 -0400
Subject: [rspec-devel] rake aborted! when setting expectations in before
Message-ID: <e45a289c0710082018vb7a58absdebdb6cfc6d3aefa@mail.gmail.com>

describe UsersController, "#new" do
  before(:each) do
    User.should_receive(:new)
  end

  it "creates a new user"
end

Running that via "rake spec" spec causes a "rake aborted" in rails. The
specs pass (as expected) but for some reason the rake task aborted.

Any ideas?

Mark

-- 
Mark Van Holstyn, Partner / Software Developer
mvanholstyn at mutuallyhuman.com, (616) 706-6842
Mutually Human Software, http://mutuallyhuman.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071008/aac54618/attachment.html 

From dchelimsky at gmail.com  Mon Oct  8 23:21:58 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 8 Oct 2007 22:21:58 -0500
Subject: [rspec-devel] rake aborted! when setting expectations in before
In-Reply-To: <e45a289c0710082018vb7a58absdebdb6cfc6d3aefa@mail.gmail.com>
References: <e45a289c0710082018vb7a58absdebdb6cfc6d3aefa@mail.gmail.com>
Message-ID: <57c63afe0710082021u37f793eayb6d7cb834b512f3@mail.gmail.com>

On 10/8/07, Mark Van Holstyn <mvanholstyn at gmail.com> wrote:
> describe UsersController, "#new" do
>   before(:each) do
>     User.should_receive(:new)
>   end
>
>   it "creates a new user"
> end
>
> Running that via "rake spec" spec causes a "rake aborted" in rails. The
> specs pass (as expected) but for some reason the rake task aborted.
>
> Any ideas?

Need a bit more info:

versions? rspec? rails? os? run "rake spec --trace" and copy the output pls

>
> Mark
>
> --
> Mark Van Holstyn, Partner / Software Developer
> mvanholstyn at mutuallyhuman.com, (616) 706-6842
> Mutually Human Software, http://mutuallyhuman.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From mvanholstyn at gmail.com  Mon Oct  8 23:52:56 2007
From: mvanholstyn at gmail.com (Mark Van Holstyn)
Date: Mon, 8 Oct 2007 23:52:56 -0400
Subject: [rspec-devel] rake aborted! when setting expectations in before
In-Reply-To: <57c63afe0710082021u37f793eayb6d7cb834b512f3@mail.gmail.com>
References: <e45a289c0710082018vb7a58absdebdb6cfc6d3aefa@mail.gmail.com>
	<57c63afe0710082021u37f793eayb6d7cb834b512f3@mail.gmail.com>
Message-ID: <e45a289c0710082052k68e763b0g9e93218c83d8e6db@mail.gmail.com>

On 10/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> versions? rspec?


trunk

rails?


trunk

os?


OS X 10.4

run "rake spec --trace" and copy the output pls


$ rake spec:controllers --trace
** Invoke spec:controllers (first_time)
** Invoke db:test:prepare (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:test:prepare
** Invoke db:test:clone (first_time)
** Invoke db:schema:dump (first_time)
** Invoke environment
** Execute db:schema:dump
** Invoke db:test:purge (first_time)
** Invoke environment
** Execute db:test:purge
** Execute db:test:clone
** Invoke db:schema:load (first_time)
** Invoke environment
** Execute db:schema:load
** Execute spec:controllers
P................................................................................................................P.......P...................

Pending:
UsersController redirect after login needs to be tested (Not Yet
Implemented)
DesignsController#index with view_designs privilege should pull
design_search from the session if it already exists (Not Yet Implemented)
DesignsController#index with crud_designs privilege should pull
design_search from the session if it already exists (Not Yet Implemented)

Finished in 0.939632 seconds

141 examples, 0 failures, 3 pending
rake aborted!
Command ruby -I"~/project/vendor/plugins/rspec/lib"
"~/project/vendor/plugins/rspec/bin/spec"
"spec/controllers/agencies_controller_spec.rb"
"spec/controllers/designs_controller_spec.rb"
"spec/controllers/projects_controller_spec.rb"
"spec/controllers/users_controller_spec.rb" --options
"~/project/spec/spec.opts" failed
~/project/vendor/plugins/rspec/lib/spec/rake/spectask.rb:173:in `define'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:823:in `verbose'
~/project/vendor/plugins/rspec/lib/spec/rake/spectask.rb:142:in `define'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `call'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `each'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in `execute'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362: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


-- 
Mark Van Holstyn, Partner / Software Developer
mvanholstyn at mutuallyhuman.com, (616) 706-6842
Mutually Human Software, http://mutuallyhuman.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071008/6dce3d83/attachment.html 

From dchelimsky at gmail.com  Tue Oct  9 00:32:30 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 8 Oct 2007 23:32:30 -0500
Subject: [rspec-devel] rake aborted! when setting expectations in before
In-Reply-To: <e45a289c0710082052k68e763b0g9e93218c83d8e6db@mail.gmail.com>
References: <e45a289c0710082018vb7a58absdebdb6cfc6d3aefa@mail.gmail.com>
	<57c63afe0710082021u37f793eayb6d7cb834b512f3@mail.gmail.com>
	<e45a289c0710082052k68e763b0g9e93218c83d8e6db@mail.gmail.com>
Message-ID: <57c63afe0710082132l3eb1d764ie40f34e57a64e0a3@mail.gmail.com>

Thanks - sadly that doesn't tell me much.

You said you think it's because you're setting expectations
before(:each) example. Have you tried moving this line:

User.should_receive(:new)

directly into the examples? Different result?

Also - the expectation is that User.should_receive(:new), but it
doesn't return anything - so I wonder what's going in in the code.
Would you mind posting the full spec and code? At least the failing
spec (w/ before, etc) and the action it is going after.

Thanks,
David

On 10/8/07, Mark Van Holstyn <mvanholstyn at gmail.com> wrote:
>
>
> On 10/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > versions? rspec?
>
> trunk
>
> > rails?
>
> trunk
>
> > os?
>
> OS X 10.4
>
> > run "rake spec --trace" and copy the output pls
>
> $ rake spec:controllers --trace
> ** Invoke spec:controllers (first_time)
> ** Invoke db:test:prepare (first_time)
> ** Invoke environment (first_time)
> ** Execute environment
> ** Execute db:test:prepare
> ** Invoke db:test:clone (first_time)
> ** Invoke db:schema:dump (first_time)
> ** Invoke environment
> ** Execute db:schema:dump
> ** Invoke db:test:purge (first_time)
> ** Invoke environment
> ** Execute db:test:purge
> ** Execute db:test:clone
> ** Invoke db:schema:load (first_time)
> ** Invoke environment
> ** Execute db:schema:load
> ** Execute spec:controllers
> P................................................................................................................P.......P...................
>
> Pending:
> UsersController redirect after login needs to be tested (Not Yet
> Implemented)
> DesignsController#index with view_designs privilege should pull
> design_search from the session if it already exists (Not Yet Implemented)
> DesignsController#index with crud_designs privilege should pull
> design_search from the session if it already exists (Not Yet Implemented)
>
> Finished in 0.939632 seconds
>
> 141 examples, 0 failures, 3 pending
>  rake aborted!
> Command ruby -I"~/project/vendor/plugins/rspec/lib"
> "~/project/vendor/plugins/rspec/bin/spec"
> "spec/controllers/agencies_controller_spec.rb"
> "spec/controllers/designs_controller_spec.rb"
> "spec/controllers/projects_controller_spec.rb"
> "spec/controllers/users_controller_spec.rb" --options
> "~/project/spec/spec.opts" failed
> ~/project/vendor/plugins/rspec/lib/spec/rake/spectask.rb:173:in
> `define'
> /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:823:in
> `verbose'
> ~/project/vendor/plugins/rspec/lib/spec/rake/spectask.rb:142:in
> `define'
> /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in
> `call'
> /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in
> `execute'
> /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in
> `each'
> /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:392:in
> `execute'
> /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362: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
>
>
> --
>
> Mark Van Holstyn, Partner / Software Developer
> mvanholstyn at mutuallyhuman.com, (616) 706-6842
> Mutually Human Software, http://mutuallyhuman.com
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From mvanholstyn at gmail.com  Tue Oct  9 01:17:02 2007
From: mvanholstyn at gmail.com (Mark Van Holstyn)
Date: Tue, 9 Oct 2007 01:17:02 -0400
Subject: [rspec-devel] rake aborted! when setting expectations in before
In-Reply-To: <57c63afe0710082132l3eb1d764ie40f34e57a64e0a3@mail.gmail.com>
References: <e45a289c0710082018vb7a58absdebdb6cfc6d3aefa@mail.gmail.com>
	<57c63afe0710082021u37f793eayb6d7cb834b512f3@mail.gmail.com>
	<e45a289c0710082052k68e763b0g9e93218c83d8e6db@mail.gmail.com>
	<57c63afe0710082132l3eb1d764ie40f34e57a64e0a3@mail.gmail.com>
Message-ID: <e45a289c0710082217r27d07c1cu7839e4dbbfcdf04b@mail.gmail.com>

On 10/9/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> Thanks - sadly that doesn't tell me much.
>
> You said you think it's because you're setting expectations
> before(:each) example.


That is why...

Have you tried moving this line:
>
> User.should_receive(:new)
>
> directly into the examples? Different result?


Yes, This resolves the rake aborted problem. I have some places however
where it would be preferable to keep these calls in the before(:each) block.

Also - the expectation is that User.should_receive(:new), but it
> doesn't return anything - so I wonder what's going in in the code.
> Would you mind posting the full spec and code? At least the failing
> spec (w/ before, etc) and the action it is going after.


This was just a contrived example (but when running this contrived example,
the specs "pass" and I get "rake aborted").

Mark

-- 
Mark Van Holstyn, Partner / Software Developer
mvanholstyn at mutuallyhuman.com, (616) 706-6842
Mutually Human Software, http://mutuallyhuman.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071009/d1512ee5/attachment.html 

From bkeepers at gmail.com  Tue Oct  9 08:19:50 2007
From: bkeepers at gmail.com (Brandon Keepers)
Date: Tue, 9 Oct 2007 08:19:50 -0400
Subject: [rspec-devel] rake aborted! when setting expectations in before
In-Reply-To: <e45a289c0710082217r27d07c1cu7839e4dbbfcdf04b@mail.gmail.com>
References: <e45a289c0710082018vb7a58absdebdb6cfc6d3aefa@mail.gmail.com>
	<57c63afe0710082021u37f793eayb6d7cb834b512f3@mail.gmail.com>
	<e45a289c0710082052k68e763b0g9e93218c83d8e6db@mail.gmail.com>
	<57c63afe0710082132l3eb1d764ie40f34e57a64e0a3@mail.gmail.com>
	<e45a289c0710082217r27d07c1cu7839e4dbbfcdf04b@mail.gmail.com>
Message-ID: <7FAA9DA8-18A0-48F7-8012-1F0A5D22927C@gmail.com>


On Oct 9, 2007, at 1:17 AM, Mark Van Holstyn wrote:

> Have you tried moving this line:
>
> User.should_receive(:new)
>
> directly into the examples? Different result?
>
> Yes, This resolves the rake aborted problem. I have some places  
> however where it would be preferable to keep these calls in the  
> before(:each) block.


What about just stubbing the :new call in the before block and then  
setting the expectation in an example?

User.stub!(:new)

Brandon



From dchelimsky at gmail.com  Tue Oct  9 09:50:09 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 9 Oct 2007 08:50:09 -0500
Subject: [rspec-devel] rake aborted! when setting expectations in before
In-Reply-To: <7FAA9DA8-18A0-48F7-8012-1F0A5D22927C@gmail.com>
References: <e45a289c0710082018vb7a58absdebdb6cfc6d3aefa@mail.gmail.com>
	<57c63afe0710082021u37f793eayb6d7cb834b512f3@mail.gmail.com>
	<e45a289c0710082052k68e763b0g9e93218c83d8e6db@mail.gmail.com>
	<57c63afe0710082132l3eb1d764ie40f34e57a64e0a3@mail.gmail.com>
	<e45a289c0710082217r27d07c1cu7839e4dbbfcdf04b@mail.gmail.com>
	<7FAA9DA8-18A0-48F7-8012-1F0A5D22927C@gmail.com>
Message-ID: <57c63afe0710090650y4df10f14sd3a23cec3326aa77@mail.gmail.com>

On 10/9/07, Brandon Keepers <bkeepers at gmail.com> wrote:
>
> On Oct 9, 2007, at 1:17 AM, Mark Van Holstyn wrote:
>
> > Have you tried moving this line:
> >
> > User.should_receive(:new)
> >
> > directly into the examples? Different result?
> >
> > Yes, This resolves the rake aborted problem. I have some places
> > however where it would be preferable to keep these calls in the
> > before(:each) block.
>
>
> What about just stubbing the :new call in the before block and then
> setting the expectation in an example?
>
> User.stub!(:new)

That might get it to work, but this behaviour is very odd. Also, I am
not able to duplicate the behaviour at all.

David

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

From noreply at rubyforge.org  Fri Oct 12 19:33:21 2007
F