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
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Oct 2007 19:33:21 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14671 ] Spec::DSL::ExampleRunner gives
	"NO NAME because of --dry-run" for every example for 'rake spec:doc'
Message-ID: <20071012233321.B9D731858658@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Tim  Dysinger (dysinger)
Assigned to: Nobody (None)
Summary: Spec::DSL::ExampleRunner gives "NO NAME because of --dry-run" for every example for 'rake spec:doc'

Initial Comment:
This used to work but currently in trunk is broken.  Reproduce by rake spec:doc on a rails project with specs and examples.

It can be fixed by commenting out line 19 of example runner where it statically assigns the example_definition.description as "NO NAME (Because of --dry-run)" instead of just leaving it as the actual example def description.

???


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

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

From noreply at rubyforge.org  Fri Oct 12 23:02:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 12 Oct 2007 23:02:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14671 ] Spec::DSL::ExampleRunner gives
	"NO NAME because of --dry-run" for every example for 'rake spec:doc'
Message-ID: <20071013030248.60E6D185865E@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Tim  Dysinger (dysinger)
Assigned to: Nobody (None)
>Summary: Spec::DSL::ExampleRunner gives "NO NAME because of --dry-run" for every example for 'rake spec:doc'

Initial Comment:
This used to work but currently in trunk is broken.  Reproduce by rake spec:doc on a rails project with specs and examples.

It can be fixed by commenting out line 19 of example runner where it statically assigns the example_definition.description as "NO NAME (Because of --dry-run)" instead of just leaving it as the actual example def description.

???


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

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

Message:
I think this is a casualty of some recent refactoring in which there are specs for a positive case but not a negative case.

Unfortunately, the fix is not as simple as you prescribe, as that would result in incorrect behaviour for examples with no strings:

describe Foo do
  before {@foo = Foo.new}
  specify {@foo.should be_bar}
end

This case, which is supported, should produce "NO NAME (Because of --dry-run)" when running a dry run.

So, we'll fix it, but it'll require a bit more work than simply removing lines of code. Patches welcome.

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

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

From noreply at rubyforge.org  Sun Oct 14 06:57:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 14 Oct 2007 06:57:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-11259 ] windows?: autotest suppresses
	output
Message-ID: <20071014105710.D6A091858694@rubyforge.org>

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

Category: None
Group: None
Status: Closed
Resolution: Out of Date
Priority: 3
Submitted By: Erik Ostrom (eostrom)
Assigned to: Nobody (None)
Summary: windows?: autotest suppresses output

Initial Comment:
When I run rspec under autotest (with the change I noted in 11258), it seems to run okay; it detects specs that should be run anew; it runs them (as evidenced by test.log); but it never, ever shows me any output from the spec runner.  Even a test known to fail shows me nothing.

If I use rspec without autotest, everything works fine.  If I use Test::Unit instead of rspec, autotest shows me the full test runner output.  So it must be a problem with the way rspec and autotest interact.

(I don't know if this is actually a Windows problem, but it seems plausible.)


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

Comment By: Juanma Cervera (jmcervera)
Date: 2007-10-14 10:57

Message:
I have the same problems.
With the option --colour autotest has no output.
withot this options int works.

But 'rake spec' works with colours and without any problem. 



* Windows XP SP2
* Ruby 1.8.6
* Rails Edge (r7873)
* RSpec and Spec::Rails r2717
* ZenTest 3.6.1

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-09-23 20:18

Message:
Erik - never heard back from you on the last comment. I'm closing this. If you have more information to help us understand the problem, please reopen it.

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

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

Message:
The --colour option on windows requires the win32console gem. Do you have that installed? If not, it would help if you would install it and report the behaviour with and without the --colour option.

Thanks,
David

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

Comment By: Adam Grant (krypticus)
Date: 2007-07-11 00:31

Message:
Yeah. Same here. I don't get any output from the autotest, except to tell me what it's running. Once I remove --colour from the spec.opts line, I get it working just fine.

Windows XP Pro w/SP2
Rspec 1.0.5 (r2081)
Rails 1.2.3
Ruby 1.8.6
ZenTest 3.6.0

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

Comment By: Erik Ostrom (eostrom)
Date: 2007-06-01 04:44

Message:
Another useful piece of information I could have given you,
it turns out, is the contents of my spec.opts file, which
starts with '--colour'.  With that removed, the bug goes away.

That's probably good enough for me.  In case it'll help
track down this problem now or in the future, this is as far
as I got:

  * In run_tests() in autotest.rb, the loop that's supposed
to loop over characters in the test command's output gets
EOF immediately, i.e., there's apparently no output from the
spec script.

  * In colour() in base_text_formatter.rb, @colour and
output_to_tty? are both true, so presumably the
colour-formatted string is returned.

I don't know what happens to it after it's returned and
before it gets output.

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

Comment By: Erik Ostrom (eostrom)
Date: 2007-06-01 03:46

Message:
Sorry, I forgot.  I think I've got the latest everything:

* Windows XP SP2
* Ruby 1.8.6
* Rails 1.2.3
* RSpec and Spec::Rails r2064
* ZenTest 3.6.0


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-05-31 19:27

Message:
Before investigating this we need to know the versions of all 
relevant software you are using, for example:

* OS X 10.4.9
* Ruby 1.8.6
* RSpec 1.8.2 or RSpec trunk r1643
* Spec::Rails 1.8.2 or Spec::Rails tag r1234...
* Rails 1.2.3 or Rails edge r5645
* Whatever other relevant software.

Without this information it's like solving 1 equation (your 
question) with 5 unknown variables (the versions).

We strongly recommend that you use the latest released version of
RSpec, alternatively the subversion trunk (if you're the bleeding
edge kind of person).

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

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

From noreply at rubyforge.org  Mon Oct 15 11:36:50 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 15 Oct 2007 11:36:50 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14543 ] rspec_scaffold broken with Rails
	2.0
Message-ID: <20071015153650.CD78118585BC@rubyforge.org>

Bugs item #14543, was opened at 2007-10-08 13: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: Spencer Turner (spencer)
Date: 2007-10-15 16:36

Message:
I get the same thing (Also on OS X 10.4.10)

same error if I run from script/console:

However, Rails:VERSION:STRING returns a value.

Line 40 in rspec_scaffold_generator.rb should be:
    if Rails::VERSION::STRING =~ /^1\.2\.[123]/
not
    if Rails::VERSION::String =~ /^1\.2\.[123]/

confirmed working after that change on 1.2.5

Sorry, probably not the right format to submit this in

I'll read up on a more formal submission.



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

Comment By: Steven Garcia (pimpmaster)
Date: 2007-10-08 13: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 noreply at rubyforge.org  Mon Oct 15 11:49:35 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 15 Oct 2007 11:49:35 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14738 ] Rspec's scaffold_generator fails
	on OSX 10.4.10 as STRING is set as String
Message-ID: <20071015154935.D1DB71858598@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Spencer Turner (spencer)
Assigned to: Nobody (None)
Summary: Rspec's scaffold_generator fails on OSX 10.4.10 as STRING is set as String

Initial Comment:
Ref: #14543 

Bug exists in trunk.
Affects 1.2.(4? - unconfirmed) 1.2.5 and 2.0.0RC

No doubt being dumb, but I can't find the Rspec tests for Rspec itself

I think the attached diff is all that is needed to fix this.

Hope that is good enough.
Spencer

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

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

From noreply at rubyforge.org  Wed Oct 17 21:40:33 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 17 Oct 2007 21:40:33 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14824 ]
	Spec::Runner.configuration.include does not work for
	ActionController::UrlWriter
Message-ID: <20071018014033.86F3718585BF@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Spec::Runner.configuration.include does not work for ActionController::UrlWriter

Initial Comment:
Spec::Runner.configure do |config|
  config.include ActionController::UrlWriter
end

Inside of UrlRewriter is:
module ActionController::UrlWriter
  def self.included(base) #:nodoc:
    ActionController::Routing::Routes.named_routes.install base
    base.mattr_accessor :default_url_options
    base.default_url_options ||= default_url_options
  end
end

Here is the error message:
NoMethodError in 'BlockingsController destroy redirects on successful destroy'
undefined method `default_url_options' for #<Class:0x4cf45c8>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.5/lib/action_controller/url_rewriter.rb:41:in `url_for'
(eval):19:in `user_contacts_path'
/Users/pivotal/workspace/socialitis/vendor/plugins/connections/spec/controllers/blockings_controller_spec.rb:30:
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `instance_eval'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:65:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:26:in `run'
/usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:24:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:26:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/test/unit/example_suite.rb:7:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:12:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/options.rb:71:in `run_examples'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:18:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:27:
-e:1:


The following does work:
class Spec::DSL::Example
  include ActionController::UrlWriter
end

class Spec::Test::Unit::Example
  include ActionController::UrlWriter
end


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

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

From noreply at rubyforge.org  Thu Oct 18 01:19:30 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 01:19:30 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14738 ] Rspec's scaffold_generator fails
	on OSX 10.4.10 as STRING is set as String
Message-ID: <20071018051930.9048E18585F9@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Spencer Turner (spencer)
>Assigned to: Brian Takita (btakita)
Summary: Rspec's scaffold_generator fails on OSX 10.4.10 as STRING is set as String

Initial Comment:
Ref: #14543 

Bug exists in trunk.
Affects 1.2.(4? - unconfirmed) 1.2.5 and 2.0.0RC

No doubt being dumb, but I can't find the Rspec tests for Rspec itself

I think the attached diff is all that is needed to fix this.

Hope that is good enough.
Spencer

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

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

From noreply at rubyforge.org  Thu Oct 18 01:19:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 01:19:42 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14738 ] Rspec's scaffold_generator fails
	on OSX 10.4.10 as STRING is set as String
Message-ID: <20071018051942.6320418585F9@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Spencer Turner (spencer)
>Assigned to: Nobody (None)
Summary: Rspec's scaffold_generator fails on OSX 10.4.10 as STRING is set as String

Initial Comment:
Ref: #14543 

Bug exists in trunk.
Affects 1.2.(4? - unconfirmed) 1.2.5 and 2.0.0RC

No doubt being dumb, but I can't find the Rspec tests for Rspec itself

I think the attached diff is all that is needed to fix this.

Hope that is good enough.
Spencer

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

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

From noreply at rubyforge.org  Thu Oct 18 01:19:52 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 01:19:52 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14824 ]
	Spec::Runner.configuration.include does not work for
	ActionController::UrlWriter
Message-ID: <20071018051952.D9E101858608@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
>Assigned to: Brian Takita (btakita)
Summary: Spec::Runner.configuration.include does not work for ActionController::UrlWriter

Initial Comment:
Spec::Runner.configure do |config|
  config.include ActionController::UrlWriter
end

Inside of UrlRewriter is:
module ActionController::UrlWriter
  def self.included(base) #:nodoc:
    ActionController::Routing::Routes.named_routes.install base
    base.mattr_accessor :default_url_options
    base.default_url_options ||= default_url_options
  end
end

Here is the error message:
NoMethodError in 'BlockingsController destroy redirects on successful destroy'
undefined method `default_url_options' for #<Class:0x4cf45c8>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.5/lib/action_controller/url_rewriter.rb:41:in `url_for'
(eval):19:in `user_contacts_path'
/Users/pivotal/workspace/socialitis/vendor/plugins/connections/spec/controllers/blockings_controller_spec.rb:30:
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `instance_eval'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:65:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:26:in `run'
/usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:24:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:26:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/test/unit/example_suite.rb:7:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:12:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/options.rb:71:in `run_examples'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:18:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:27:
-e:1:


The following does work:
class Spec::DSL::Example
  include ActionController::UrlWriter
end

class Spec::Test::Unit::Example
  include ActionController::UrlWriter
end


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

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

From noreply at rubyforge.org  Thu Oct 18 02:25:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 02:25:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14824 ]
	Spec::Runner.configuration.include does not work for
	ActionController::UrlWriter
Message-ID: <20071018062507.0D62118585CD@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
>Assigned to: Nobody (None)
Summary: Spec::Runner.configuration.include does not work for ActionController::UrlWriter

Initial Comment:
Spec::Runner.configure do |config|
  config.include ActionController::UrlWriter
end

Inside of UrlRewriter is:
module ActionController::UrlWriter
  def self.included(base) #:nodoc:
    ActionController::Routing::Routes.named_routes.install base
    base.mattr_accessor :default_url_options
    base.default_url_options ||= default_url_options
  end
end

Here is the error message:
NoMethodError in 'BlockingsController destroy redirects on successful destroy'
undefined method `default_url_options' for #<Class:0x4cf45c8>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.5/lib/action_controller/url_rewriter.rb:41:in `url_for'
(eval):19:in `user_contacts_path'
/Users/pivotal/workspace/socialitis/vendor/plugins/connections/spec/controllers/blockings_controller_spec.rb:30:
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `instance_eval'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:65:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:26:in `run'
/usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:24:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:26:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/test/unit/example_suite.rb:7:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:12:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/options.rb:71:in `run_examples'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:18:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:27:
-e:1:


The following does work:
class Spec::DSL::Example
  include ActionController::UrlWriter
end

class Spec::Test::Unit::Example
  include ActionController::UrlWriter
end


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

>Comment By: Brian Takita (btakita)
Date: 2007-10-17 23:25

Message:
Spec::Runner.configure do |config|
  include ActionController::UrlWriter
end

also works.

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

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

From noreply at rubyforge.org  Thu Oct 18 02:26:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 02:26:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14824 ]
	Spec::Runner.configuration.include does not work for
	ActionController::UrlWriter
Message-ID: <20071018062648.6676118585F9@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Spec::Runner.configuration.include does not work for ActionController::UrlWriter

Initial Comment:
Spec::Runner.configure do |config|
  config.include ActionController::UrlWriter
end

Inside of UrlRewriter is:
module ActionController::UrlWriter
  def self.included(base) #:nodoc:
    ActionController::Routing::Routes.named_routes.install base
    base.mattr_accessor :default_url_options
    base.default_url_options ||= default_url_options
  end
end

Here is the error message:
NoMethodError in 'BlockingsController destroy redirects on successful destroy'
undefined method `default_url_options' for #<Class:0x4cf45c8>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.5/lib/action_controller/url_rewriter.rb:41:in `url_for'
(eval):19:in `user_contacts_path'
/Users/pivotal/workspace/socialitis/vendor/plugins/connections/spec/controllers/blockings_controller_spec.rb:30:
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `instance_eval'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:65:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:26:in `run'
/usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:24:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:26:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/test/unit/example_suite.rb:7:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:12:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/options.rb:71:in `run_examples'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:18:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:27:
-e:1:


The following does work:
class Spec::DSL::Example
  include ActionController::UrlWriter
end

class Spec::Test::Unit::Example
  include ActionController::UrlWriter
end


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

>Comment By: Brian Takita (btakita)
Date: 2007-10-17 23:26

Message:
Well it "works" because the include happens in the context
of Object.

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

Comment By: Brian Takita (btakita)
Date: 2007-10-17 23:25

Message:
Spec::Runner.configure do |config|
  include ActionController::UrlWriter
end

also works.

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

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

From dchelimsky at gmail.com  Thu Oct 18 04:33:53 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 18 Oct 2007 03:33:53 -0500
Subject: [rspec-devel] first cut at blockless given/when/then
Message-ID: <57c63afe0710180133q688660e3o1f4cf0b32514e626@mail.gmail.com>

Hi all,

I committed a first cut at blockless Givens/Whens/Thens to RSpec's trunk:

cd /path/to/rspec/project
svn up
cd rspec
bin/spec examples/story/calculator.rb

Take a look at examples/story/calculator.rb to see what's going on.

Needs docs!!!!

Thoughts welcome.

I've also got a cut at the plain text parser checked in, but it's not
hooked up to anything yet. However, now that we can do blockless GWT,
hooking the parser up to the rest is just a matter of a simple adapter
and logistics. Look for it in the next few days.

Cheers,
David

From noreply at rubyforge.org  Thu Oct 18 09:29:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 09:29:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14738 ] Rspec's scaffold_generator fails
	on OSX 10.4.10 as STRING is set as String
Message-ID: <20071018132941.89FA718585F9@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Spencer Turner (spencer)
Assigned to: Nobody (None)
Summary: Rspec's scaffold_generator fails on OSX 10.4.10 as STRING is set as String

Initial Comment:
Ref: #14543 

Bug exists in trunk.
Affects 1.2.(4? - unconfirmed) 1.2.5 and 2.0.0RC

No doubt being dumb, but I can't find the Rspec tests for Rspec itself

I think the attached diff is all that is needed to fix this.

Hope that is good enough.
Spencer

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

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

Message:
This is a duplicate of http://rubyforge.org/tracker/index.php?func=detail&aid=14543&group_id=797&atid=3149

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

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

From noreply at rubyforge.org  Thu Oct 18 10:15:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 10:15:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14543 ] rspec_scaffold broken with Rails
	2.0
Message-ID: <20071018141526.C529318585BF@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: David Chelimsky (dchelimsky)
Date: 2007-10-18 14:15

Message:
Not sure why I wasn't seeing this error when running the pre_commit, but I do see it when running outside the app.

One problem I'm having now is that the 2.0.0 pre-release says that it's Rails::VERSION::STRING is '1.2.3', which means we can't use that strategy to decide whether to use ";edit" or "/edit".

I'm tempted (out of pure frustration) to make the specs use a regexp that will match either, but that would be a bit too non-deterministic for my blood :)

I'll follow up as I learn.

Cheers,
David

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

Comment By: Spencer Turner (spencer)
Date: 2007-10-15 15:36

Message:
I get the same thing (Also on OS X 10.4.10)

same error if I run from script/console:

However, Rails:VERSION:STRING returns a value.

Line 40 in rspec_scaffold_generator.rb should be:
    if Rails::VERSION::STRING =~ /^1\.2\.[123]/
not
    if Rails::VERSION::String =~ /^1\.2\.[123]/

confirmed working after that change on 1.2.5

Sorry, probably not the right format to submit this in

I'll read up on a more formal submission.



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

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 noreply at rubyforge.org  Thu Oct 18 19:22:42 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 19:22:42 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14543 ] rspec_scaffold broken with Rails
	2.0
Message-ID: <20071018232243.07FC018585EF@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: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Steven Garcia (pimpmaster)
>Assigned to: David Chelimsky (dchelimsky)
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: David Chelimsky (dchelimsky)
Date: 2007-10-18 23:22

Message:
Fixed in rev2735

Using Routing::SEPARATORS.include(";") to determine which type of path to write (thanks to bitsweat for the suggestion)

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

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

Message:
Not sure why I wasn't seeing this error when running the pre_commit, but I do see it when running outside the app.

One problem I'm having now is that the 2.0.0 pre-release says that it's Rails::VERSION::STRING is '1.2.3', which means we can't use that strategy to decide whether to use ";edit" or "/edit".

I'm tempted (out of pure frustration) to make the specs use a regexp that will match either, but that would be a bit too non-deterministic for my blood :)

I'll follow up as I learn.

Cheers,
David

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

Comment By: Spencer Turner (spencer)
Date: 2007-10-15 15:36

Message:
I get the same thing (Also on OS X 10.4.10)

same error if I run from script/console:

However, Rails:VERSION:STRING returns a value.

Line 40 in rspec_scaffold_generator.rb should be:
    if Rails::VERSION::STRING =~ /^1\.2\.[123]/
not
    if Rails::VERSION::String =~ /^1\.2\.[123]/

confirmed working after that change on 1.2.5

Sorry, probably not the right format to submit this in

I'll read up on a more formal submission.



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

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 noreply at rubyforge.org  Thu Oct 18 19:30:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 19:30:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14867 ] Allow setting of
	default options in the spec_helper file
Message-ID: <20071018233001.1239918585EF@rubyforge.org>

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

Category: runner / command line
Group: None
Status: Open
Priority: 3
Submitted By: Luke Kanies (lkanies)
Assigned to: Nobody (None)
Summary: Allow setting of default options in the spec_helper file

Initial Comment:
Hullo,

I'd like to be able to set default options in Ruby, rather than having to use the -O flag to load an options file.

It'd be especially nice if I could do this via the block attached to Spec::Runner.configure.

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

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

From noreply at rubyforge.org  Thu Oct 18 20:35:26 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 20:35:26 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14671 ] Spec::DSL::ExampleRunner gives
	"NO NAME because of --dry-run" for every example for 'rake spec:doc'
Message-ID: <20071019003527.C0DD718585CD@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Tim  Dysinger (dysinger)
>Assigned to: David Chelimsky (dchelimsky)
>Summary: Spec::DSL::ExampleRunner gives "NO NAME because of --dry-run" for every example for 'rake spec:doc'

Initial Comment:
This used to work but currently in trunk is broken.  Reproduce by rake spec:doc on a rails project with specs and examples.

It can be fixed by commenting out line 19 of example runner where it statically assigns the example_definition.description as "NO NAME (Because of --dry-run)" instead of just leaving it as the actual example def description.

???


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-19 00:35

Message:
Fixed in r2737

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

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

Message:
I think this is a casualty of some recent refactoring in which there are specs for a positive case but not a negative case.

Unfortunately, the fix is not as simple as you prescribe, as that would result in incorrect behaviour for examples with no strings:

describe Foo do
  before {@foo = Foo.new}
  specify {@foo.should be_bar}
end

This case, which is supported, should produce "NO NAME (Because of --dry-run)" when running a dry run.

So, we'll fix it, but it'll require a bit more work than simply removing lines of code. Patches welcome.

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

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

From noreply at rubyforge.org  Thu Oct 18 20:42:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 20:42:46 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-10263 ] mock &quot; leak&quot;
	when setting an expectation in a block passed to mock#should_receive
Message-ID: <20071019004246.559E418585CD@rubyforge.org>

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

Category: mock module
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
>Assigned to: David Chelimsky (dchelimsky)
>Summary: mock &quot;leak&quot; when setting an expectation in a block passed to mock#should_receive

Initial Comment:
The following failing examples should tell the story:

describe "Mock" do
  before do
    @mock = mock("test mock")
  end
  
  specify "when one example has an expectation (non-mock) inside the block passed to the mock" do
    @mock.should_receive(:msg) do |b|
      b.should be_true #this call exposes the problem
    end
    @mock.msg(false) rescue nil
  end
  
  specify "then the next example should behave as expected instead of saying" do
    @mock.should_receive(:foobar)
    @mock.foobar
    @mock.rspec_verify
    begin
      @mock.foobar
    rescue => e
      e.message.should == "Mock 'test mock' received unexpected message :foobar with (no args)"
    end
  end 
end


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-19 00:42

Message:
Went to add this as pending and it turns out it got fixed. I have no idea when, but I suspect it was one of Antti Tarvainen's patches right after RailsConfEU.

Thanks AT!

Cheers,
David

ps - I did add the example above to the spec suite in r2738

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

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

From noreply at rubyforge.org  Thu Oct 18 20:45:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 20:45:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13411 ] &amp; quot;
	./script/generate rspec&amp; quot; is freezing
Message-ID: <20071019004528.567D418585B8@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
Summary: &amp;quot;./script/generate rspec&amp;quot; is freezing

Initial Comment:

Setup: 

Rails project (version 1.2.3), checked out in vendor/rails
Rspec + rspec_on_rails trunk (rev 2537) checked out in vendor/plugins
rspec gem, version 1.0.8
Mac OS X.4.10
(Am I missing anything else?)

Bug:

running "./script/generate rspec" first checks for the existence of the spec dir (which it finds), and then freezes.  

Oddly enough, running "rdebug ./script/generate rspec" allows the rest of the files to be created (after prompting), as usual.

I've uploaded a screencast of the bug here:

http://railsnewbie.com/files/script_generate_rspec.mov

I would try debugging this myself, but obviously my debugger has an effect on the debugging!



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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-19 00:45

Message:
Closing per OP (long ago).

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-09-28 02:26

Message:
Ah - so some new insight.  Actually, this isn't a freeze, it
just appears to be.  It only occurs when the file to be
generated is already present, and not identical(exists, but
is different).  Basically, the gets() routine seems to be
called before the puts prompt occurs.  Here is a little
screen cast:

http://railsnewbie.com/files/rspec_generator_bug2.mov

This doesn't look like a bug with rspec - it looks like a
bug with rails (or more likely my configuration).  I'm
having exactly the same thing with ./script/generate model
ModelName when the file exists and is different.

This ticket can be closed.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-27 15:12

Message:
I wasn't sure which generators you were speaking of, so I
tried a bunch (all of them seemed to work):

euclid% ./script/generate model HelloWorld
      exists  app/models/
      exists  test/unit/
      exists  test/fixtures/
      create  app/models/hello_world.rb
      create  test/unit/hello_world_test.rb
      create  test/fixtures/hello_worlds.yml
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
euclid% ./script/destroy model HelloWorld
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  test/fixtures/hello_worlds.yml
          rm  test/unit/hello_world_test.rb
          rm  app/models/hello_world.rb
    notempty  test/fixtures
    notempty  test
    notempty  test/unit
    notempty  test
    notempty  app/models
    notempty  app
euclid% ./script/generate rspec_model HelloWorld
      exists  app/models/
      exists  spec/models/
      exists  spec/fixtures/
      create  app/models/hello_world.rb
      create  spec/fixtures/hello_worlds.yml
      create  spec/models/hello_world_spec.rb
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
euclid% ./script/generate rspec_controller HelloWorld
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/hello_world
      exists  spec/controllers/
      exists  spec/helpers/
      create  spec/views/hello_world
      create  spec/controllers/hello_world_controller_spec.rb
      create  spec/helpers/hello_world_helper_spec.rb
      create  app/controllers/hello_world_controller.rb
      create  app/helpers/hello_world_helper.rb
euclid% ./script/destroy rspec_model HelloWorld
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  spec/models/hello_world_spec.rb
          rm  spec/fixtures/hello_worlds.yml
          rm  app/models/hello_world.rb
    notempty  spec/fixtures
    notempty  spec
    notempty  spec/models
    notempty  spec
    notempty  app/models
    notempty  app
euclid% ./script/destroy rspec_controller HelloWorld
          rm  app/helpers/hello_world_helper.rb
          rm  app/controllers/hello_world_controller.rb
          rm  spec/helpers/hello_world_helper_spec.rb
          rm  spec/controllers/hello_world_controller_spec.rb
       rmdir  spec/views/hello_world
       rmdir  spec/views
Directory not empty - script/../config/../spec/views
euclid% ./script/generate rspec_scaffold HelloWorld
      exists  app/models/
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/hello_worlds
      exists  spec/controllers/
      exists  spec/models/
      exists  spec/helpers/
      exists  spec/fixtures/
      create  spec/views/hello_worlds
      create  spec/controllers/hello_worlds_controller_spec.rb
      create  app/controllers/hello_worlds_controller.rb
      create  spec/helpers/hello_worlds_helper_spec.rb
      create  app/helpers/hello_worlds_helper.rb
      create  app/views/hello_worlds/index.rhtml
      create  app/views/hello_worlds/show.rhtml
      create  app/views/hello_worlds/new.rhtml
      create  app/views/hello_worlds/edit.rhtml
      create  app/models/hello_world.rb
      create  spec/fixtures/hello_worlds.yml
      create  spec/models/hello_world_spec.rb
      create  spec/views/hello_worlds/edit.rhtml_spec.rb
      create  spec/views/hello_worlds/index.rhtml_spec.rb
      create  spec/views/hello_worlds/new.rhtml_spec.rb
      create  spec/views/hello_worlds/show.rhtml_spec.rb
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
       route  map.resources :hello_worlds
euclid% ./script/destroy rspec_scaffold HelloWorld
       route  map.resources :hello_worlds
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  spec/views/hello_worlds/show.rhtml_spec.rb
          rm  spec/views/hello_worlds/new.rhtml_spec.rb
          rm  spec/views/hello_worlds/index.rhtml_spec.rb
          rm  spec/views/hello_worlds/edit.rhtml_spec.rb
          rm  spec/models/hello_world_spec.rb
          rm  spec/fixtures/hello_worlds.yml
          rm  app/models/hello_world.rb
          rm  app/views/hello_worlds/edit.rhtml
          rm  app/views/hello_worlds/new.rhtml
          rm  app/views/hello_worlds/show.rhtml
          rm  app/views/hello_worlds/index.rhtml
          rm  app/helpers/hello_worlds_helper.rb
          rm  spec/helpers/hello_worlds_helper_spec.rb
          rm  app/controllers/hello_worlds_controller.rb
          rm  spec/controllers/hello_worlds_controller_spec.rb
       rmdir  spec/views/hello_worlds
       rmdir  spec/views
Directory not empty - script/../config/../spec/views
euclid% 

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-27 06:54

Message:
Can you confirm that this only happens for the rspec generator and none of the others?

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

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

From noreply at rubyforge.org  Thu Oct 18 20:57:32 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 20:57:32 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14671 ] Spec::DSL::ExampleRunner gives
	&quot; NO NAME because of --dry-run&quot;
	for every example for 'rake spec:doc'
Message-ID: <20071019005732.1C4BA18585BF@rubyforge.org>

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

Category: runner module
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Tim  Dysinger (dysinger)
Assigned to: David Chelimsky (dchelimsky)
>Summary: Spec::DSL::ExampleRunner gives &quot;NO NAME because of --dry-run&quot; for every example for 'rake spec:doc'

Initial Comment:
This used to work but currently in trunk is broken.  Reproduce by rake spec:doc on a rails project with specs and examples.

It can be fixed by commenting out line 19 of example runner where it statically assigns the example_definition.description as "NO NAME (Because of --dry-run)" instead of just leaving it as the actual example def description.

???


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

>Comment By: Tim  Dysinger (dysinger)
Date: 2007-10-18 14:57

Message:
Cool.  Thanks for looking at.  I know I am not supposed to
be on trunk but I have to to use it with Rails 2.0 preview.

This was more of a "hey I know of this issue" than "hey! fix
it!" bug entry.

:)

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

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

Message:
Fixed in r2737

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-12 17:02

Message:
I think this is a casualty of some recent refactoring in which there are specs for a positive case but not a negative case.

Unfortunately, the fix is not as simple as you prescribe, as that would result in incorrect behaviour for examples with no strings:

describe Foo do
  before {@foo = Foo.new}
  specify {@foo.should be_bar}
end

This case, which is supported, should produce "NO NAME (Because of --dry-run)" when running a dry run.

So, we'll fix it, but it'll require a bit more work than simply removing lines of code. Patches welcome.

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

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

From noreply at rubyforge.org  Thu Oct 18 20:59:25 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 20:59:25 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14671 ] Spec::DSL::ExampleRunner gives
	&quot; NO NAME because of --dry-run&quot;
	for every example for 'rake spec:doc'
Message-ID: <20071019005925.D2A7C18585BF@rubyforge.org>

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

Category: runner module
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Tim  Dysinger (dysinger)
Assigned to: David Chelimsky (dchelimsky)
Summary: Spec::DSL::ExampleRunner gives &quot;NO NAME because of --dry-run&quot; for every example for 'rake spec:doc'

Initial Comment:
This used to work but currently in trunk is broken.  Reproduce by rake spec:doc on a rails project with specs and examples.

It can be fixed by commenting out line 19 of example runner where it statically assigns the example_definition.description as "NO NAME (Because of --dry-run)" instead of just leaving it as the actual example def description.

???


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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-19 00:59

Message:
Who said you're not supposed to be on trunk? You just have to accept the risks. But that should not stop you from reporting bugs when you see 'em!

Thanks.

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

Comment By: Tim  Dysinger (dysinger)
Date: 2007-10-19 00:57

Message:
Cool.  Thanks for looking at.  I know I am not supposed to
be on trunk but I have to to use it with Rails 2.0 preview.

This was more of a "hey I know of this issue" than "hey! fix
it!" bug entry.

:)

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-19 00:35

Message:
Fixed in r2737

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

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

Message:
I think this is a casualty of some recent refactoring in which there are specs for a positive case but not a negative case.

Unfortunately, the fix is not as simple as you prescribe, as that would result in incorrect behaviour for examples with no strings:

describe Foo do
  before {@foo = Foo.new}
  specify {@foo.should be_bar}
end

This case, which is supported, should produce "NO NAME (Because of --dry-run)" when running a dry run.

So, we'll fix it, but it'll require a bit more work than simply removing lines of code. Patches welcome.

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

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

From noreply at rubyforge.org  Thu Oct 18 21:03:09 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 21:03:09 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14399 ] Show pending reasons in HTML
	report
Message-ID: <20071019010309.401C018585DC@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: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
>Assigned to: David Chelimsky (dchelimsky)
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-19 01:03

Message:
Applied to r2739

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

Comment By: Bryan Helmkamp (brynary)
Date: 2007-10-03 15: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 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 noreply at rubyforge.org  Thu Oct 18 21:17:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 21:17:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14402 ] Add --profile option to show
	example options in specdoc
Message-ID: <20071019011736.7A0D118585DD@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Bryan Helmkamp (brynary)
>Assigned to: David Chelimsky (dchelimsky)
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

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-19 01:17

Message:
Applied to r2740

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

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

From noreply at rubyforge.org  Thu Oct 18 21:17:41 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 21:17:41 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-13206 ] Individual Spec's
	Runtimes in Specdoc formatter
Message-ID: <20071019011741.8B20318585F1@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
>Assigned to: David Chelimsky (dchelimsky)
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: David Chelimsky (dchelimsky)
Date: 2007-10-19 01:17

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

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

Comment By: Bryan Helmkamp (brynary)
Date: 2007-10-03 07: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  Thu Oct 18 21:19:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 21:19:47 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Patches-14152 ] Output warning when method is
	defined on a nil object.
Message-ID: <20071019011947.8964018585DD@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: Closed
>Resolution: Rejected
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-19 01:19

Message:
I'm closing this. I don't think it's something we should do because it assumes that there are never valid use cases for expecting a method call on nil, which I think there are.

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

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  Thu Oct 18 21:56:59 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Thu, 18 Oct 2007 21:56:59 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13411 ] &amp; amp; quot;
	./script/generate rspec&amp; amp; quot; is freezing
Message-ID: <20071019015659.331C218585BF@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Closed
Resolution: Rejected
Priority: 3
Submitted By: Scott Taylor (smtlaissezfaire)
Assigned to: Nobody (None)
>Summary: &amp;amp;quot;./script/generate rspec&amp;amp;quot; is freezing

Initial Comment:

Setup: 

Rails project (version 1.2.3), checked out in vendor/rails
Rspec + rspec_on_rails trunk (rev 2537) checked out in vendor/plugins
rspec gem, version 1.0.8
Mac OS X.4.10
(Am I missing anything else?)

Bug:

running "./script/generate rspec" first checks for the existence of the spec dir (which it finds), and then freezes.  

Oddly enough, running "rdebug ./script/generate rspec" allows the rest of the files to be created (after prompting), as usual.

I've uploaded a screencast of the bug here:

http://railsnewbie.com/files/script_generate_rspec.mov

I would try debugging this myself, but obviously my debugger has an effect on the debugging!



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

>Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-10-19 01:56

Message:
Sounds good, David.  I'm pretty sure it was actually a
problem with all rails generators (so it's a problem with
rails, and by association with rspec), but I haven't seen
this problem in a long time anyway.  I'll reopen this ticket
if I have any more problems.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-19 00:45

Message:
Closing per OP (long ago).

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-09-28 02:26

Message:
Ah - so some new insight.  Actually, this isn't a freeze, it
just appears to be.  It only occurs when the file to be
generated is already present, and not identical(exists, but
is different).  Basically, the gets() routine seems to be
called before the puts prompt occurs.  Here is a little
screen cast:

http://railsnewbie.com/files/rspec_generator_bug2.mov

This doesn't look like a bug with rspec - it looks like a
bug with rails (or more likely my configuration).  I'm
having exactly the same thing with ./script/generate model
ModelName when the file exists and is different.

This ticket can be closed.

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

Comment By: Scott Taylor (smtlaissezfaire)
Date: 2007-08-27 15:12

Message:
I wasn't sure which generators you were speaking of, so I
tried a bunch (all of them seemed to work):

euclid% ./script/generate model HelloWorld
      exists  app/models/
      exists  test/unit/
      exists  test/fixtures/
      create  app/models/hello_world.rb
      create  test/unit/hello_world_test.rb
      create  test/fixtures/hello_worlds.yml
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
euclid% ./script/destroy model HelloWorld
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  test/fixtures/hello_worlds.yml
          rm  test/unit/hello_world_test.rb
          rm  app/models/hello_world.rb
    notempty  test/fixtures
    notempty  test
    notempty  test/unit
    notempty  test
    notempty  app/models
    notempty  app
euclid% ./script/generate rspec_model HelloWorld
      exists  app/models/
      exists  spec/models/
      exists  spec/fixtures/
      create  app/models/hello_world.rb
      create  spec/fixtures/hello_worlds.yml
      create  spec/models/hello_world_spec.rb
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
euclid% ./script/generate rspec_controller HelloWorld
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/hello_world
      exists  spec/controllers/
      exists  spec/helpers/
      create  spec/views/hello_world
      create  spec/controllers/hello_world_controller_spec.rb
      create  spec/helpers/hello_world_helper_spec.rb
      create  app/controllers/hello_world_controller.rb
      create  app/helpers/hello_world_helper.rb
euclid% ./script/destroy rspec_model HelloWorld
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  spec/models/hello_world_spec.rb
          rm  spec/fixtures/hello_worlds.yml
          rm  app/models/hello_world.rb
    notempty  spec/fixtures
    notempty  spec
    notempty  spec/models
    notempty  spec
    notempty  app/models
    notempty  app
euclid% ./script/destroy rspec_controller HelloWorld
          rm  app/helpers/hello_world_helper.rb
          rm  app/controllers/hello_world_controller.rb
          rm  spec/helpers/hello_world_helper_spec.rb
          rm  spec/controllers/hello_world_controller_spec.rb
       rmdir  spec/views/hello_world
       rmdir  spec/views
Directory not empty - script/../config/../spec/views
euclid% ./script/generate rspec_scaffold HelloWorld
      exists  app/models/
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/hello_worlds
      exists  spec/controllers/
      exists  spec/models/
      exists  spec/helpers/
      exists  spec/fixtures/
      create  spec/views/hello_worlds
      create  spec/controllers/hello_worlds_controller_spec.rb
      create  app/controllers/hello_worlds_controller.rb
      create  spec/helpers/hello_worlds_helper_spec.rb
      create  app/helpers/hello_worlds_helper.rb
      create  app/views/hello_worlds/index.rhtml
      create  app/views/hello_worlds/show.rhtml
      create  app/views/hello_worlds/new.rhtml
      create  app/views/hello_worlds/edit.rhtml
      create  app/models/hello_world.rb
      create  spec/fixtures/hello_worlds.yml
      create  spec/models/hello_world_spec.rb
      create  spec/views/hello_worlds/edit.rhtml_spec.rb
      create  spec/views/hello_worlds/index.rhtml_spec.rb
      create  spec/views/hello_worlds/new.rhtml_spec.rb
      create  spec/views/hello_worlds/show.rhtml_spec.rb
      exists  db/migrate
      create  db/migrate/075_create_hello_worlds.rb
       route  map.resources :hello_worlds
euclid% ./script/destroy rspec_scaffold HelloWorld
       route  map.resources :hello_worlds
    notempty  db/migrate
    notempty  db
          rm  db/migrate/075_create_hello_worlds.rb
          rm  spec/views/hello_worlds/show.rhtml_spec.rb
          rm  spec/views/hello_worlds/new.rhtml_spec.rb
          rm  spec/views/hello_worlds/index.rhtml_spec.rb
          rm  spec/views/hello_worlds/edit.rhtml_spec.rb
          rm  spec/models/hello_world_spec.rb
          rm  spec/fixtures/hello_worlds.yml
          rm  app/models/hello_world.rb
          rm  app/views/hello_worlds/edit.rhtml
          rm  app/views/hello_worlds/new.rhtml
          rm  app/views/hello_worlds/show.rhtml
          rm  app/views/hello_worlds/index.rhtml
          rm  app/helpers/hello_worlds_helper.rb
          rm  spec/helpers/hello_worlds_helper_spec.rb
          rm  app/controllers/hello_worlds_controller.rb
          rm  spec/controllers/hello_worlds_controller_spec.rb
       rmdir  spec/views/hello_worlds
       rmdir  spec/views
Directory not empty - script/../config/../spec/views
euclid% 

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

Comment By: Aslak Helles?y (aslak_hellesoy)
Date: 2007-08-27 06:54

Message:
Can you confirm that this only happens for the rspec generator and none of the others?

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

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

From noreply at rubyforge.org  Fri Oct 19 00:38:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 19 Oct 2007 00:38:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14868 ] Migrate test DB
	independent of dev DB
Message-ID: <20071019043816.6A33018585F1@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Steve V (vertebrate)
Assigned to: Nobody (None)
Summary: Migrate test DB independent of dev DB

Initial Comment:
Current behavior has the test database only being migrated as far as the dev database. If doing true BDD you will be testing before going to the dev env. As such, when running specs the database should be performed to the latest migration, and give no concern to the dev DB.

This request is a result of the users list thread "spec:models depends on development db:migration"


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

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

From undees at gmail.com  Fri Oct 19 01:33:17 2007
From: undees at gmail.com (Ian Dees)
Date: Thu, 18 Oct 2007 22:33:17 -0700
Subject: [rspec-devel] first cut at blockless given/when/then
Message-ID: <ad4f9af90710182233p7ac38edfu58cd8ba18f2aab20@mail.gmail.com>

Hi, Dave.

> I committed a first cut at blockless Givens/Whens/Thens to RSpec's trunk:

Nice!

Thinking out loud for larger projects here....  What's the scope (or
lifetime -- I'm not sure what to call it) of a step created by
step_matcher?  How does it know which Story to attach to?

And a brief heretical thought: does step_matcher really need us to
specify :given, :when, or :then?  Is there ever a case when two steps
would have the same name, but one would be a Given and the other would
be a Then?

--Ian

From pergesu at gmail.com  Fri Oct 19 03:42:58 2007
From: pergesu at gmail.com (Pat Maddox)
Date: Fri, 19 Oct 2007 00:42:58 -0700
Subject: [rspec-devel] first cut at blockless given/when/then
In-Reply-To: <ad4f9af90710182233p7ac38edfu58cd8ba18f2aab20@mail.gmail.com>
References: <ad4f9af90710182233p7ac38edfu58cd8ba18f2aab20@mail.gmail.com>
Message-ID: <810a540e0710190042m6f9c7e21l7e1e3054958d85ad@mail.gmail.com>

On 10/18/07, Ian Dees <undees at gmail.com> wrote:
> Hi, Dave.
>
> > I committed a first cut at blockless Givens/Whens/Thens to RSpec's trunk:
>
> Nice!
>
> Thinking out loud for larger projects here....  What's the scope (or
> lifetime -- I'm not sure what to call it) of a step created by
> step_matcher?  How does it know which Story to attach to?

I don't think that's been figured out yet.  I chatted with David a bit
earlier this evening and we were brainstorming a little, but the convo
got cut short.  If you've got ideas I'd love to hear them.


> And a brief heretical thought: does step_matcher really need us to
> specify :given, :when, or :then?  Is there ever a case when two steps
> would have the same name, but one would be a Given and the other would
> be a Then?

I'm not sure there are many cases where step names could clash like
that, but I suppose there could be.  More importantly though, passing
in the type gives clarity.

step_matcher(:given, "an addend of $addend")

stands on its own.  At a glance you can tell that it's used as a
given.  Contrast that with scouring hundreds of lines of

step_matcher("an addend of $addend")
step_matcher("an augend of $augend")
step_matcher("a tightend of $tightend")

it gets painful if you don't have any idea what each one is.  At
least, it would be painful for me.

Pat

From undees at gmail.com  Fri Oct 19 20:05:17 2007
From: undees at gmail.com (Ian Dees)
Date: Fri, 19 Oct 2007 17:05:17 -0700
Subject: [rspec-devel] first cut at blockless given/when/then
Message-ID: <ad4f9af90710191705h322eae7apeca69ccc08ef4ba9@mail.gmail.com>

Hi, Pat.

> > Thinking out loud for larger projects here....  What's the scope (or
> > lifetime -- I'm not sure what to call it) of a step created by
> > step_matcher?  How does it know which Story to attach to?
>
> I don't think that's been figured out yet.  I chatted with David a bit
> earlier this evening and we were brainstorming a little, but the convo
> got cut short.  If you've got ideas I'd love to hear them.

I'm not sure I have a solution, but I have some puzzles.

Some steps might need to work for multiple stories.  A story about
managing users (with several scenarios) and another story about
managing blog posts (also with several scenarios) might both benefit
from a "when I log in as an administrator" step.  So something like a
story_helper.rb file could get included into multiple stories.

On the other hand...

Some steps are definitely story-specific.  A bowling game and a
football game (take your pick which kind of football) might each have
a "Given a new game" step.  We'd want to avoid collision somehow,
either by non-RSpec methods (file/directory/require organization) or
by some kind of optional namespacing:

step_helper(:given, 'A new game', :story => 'bowling') do
  @game = BowlingGame.new
end

> step_matcher(:given, "an addend of $addend")
>
> stands on its own.  At a glance you can tell that it's used as a
> given.  Contrast that with scouring hundreds of lines of
>
> step_matcher("an addend of $addend")
> step_matcher("an augend of $augend")
> step_matcher("a tightend of $tightend")

I dunno, it looks to me like those are all Given steps.  I certainly
can't imagine "when an addend of $addend" or "then an addend of
$addend."

The Given/:given capitalization and colon mismatch is actually more
distracting to me than a lack of a prefix; I'd constantly be typing
the wrong one.  But maybe I'm just clumsy....

--Ian

From noreply at rubyforge.org  Sat Oct 20 16:03:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 20 Oct 2007 16:03:56 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14901 ] add unit_record (or
	similar) support
Message-ID: <20071020200356.E3D2218585FF@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: add unit_record (or similar) support

Initial Comment:
unit_record allows you to enforce a rule that your tests never touch the database.

This request is that RSpec provide support for something similar, but that it be configurable at the spec level - so you can have arbitrary groups of specs that are not allowed to touch the DB and others that are.

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

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

From noreply at rubyforge.org  Sat Oct 20 16:06:06 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sat, 20 Oct 2007 16:06:06 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14901 ] add unit_record (or
	similar) support
Message-ID: <20071020200606.929A018585FF@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: add unit_record (or similar) support

Initial Comment:
unit_record allows you to enforce a rule that your tests never touch the database.

This request is that RSpec provide support for something similar, but that it be configurable at the spec level - so you can have arbitrary groups of specs that are not allowed to touch the DB and others that are.

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

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

Message:
FYI:

http://www.dcmanges.com/blog/rails-unit-record-test-without-the-database

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

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

From noreply at rubyforge.org  Sun Oct 21 09:48:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 21 Oct 2007 09:48:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14918 ] Facets
Message-ID: <20071021134810.F3EA518585CB@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Nobody (None)
Summary: Facets

Initial Comment:
Thought I would submit a ticket for this as a reminder of the rspec-users thread

Behaviours of the following format:

  describe "something" do
    facet "one facet" do
      it "should do something"
      facet "inner facet" do
        it "should do this too"
      end
      it "and a bit more"
    end
    facet "another facet" do
      it "should do something else"
    end
  end

should output:

  something
  - one facet
    -should do something
    - inner facet
      - should do this too
  - and a bit more
  - another facet
    - should do something else

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

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

From noreply at rubyforge.org  Sun Oct 21 09:57:55 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 21 Oct 2007 09:57:55 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14918 ] Facets
Message-ID: <20071021135755.3039118585F8@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Nobody (None)
Summary: Facets

Initial Comment:
Thought I would submit a ticket for this as a reminder of the rspec-users thread

Behaviours of the following format:

  describe "something" do
    facet "one facet" do
      it "should do something"
      facet "inner facet" do
        it "should do this too"
      end
      it "and a bit more"
    end
    facet "another facet" do
      it "should do something else"
    end
  end

should output:

  something
  - one facet
    -should do something
    - inner facet
      - should do this too
  - and a bit more
  - another facet
    - should do something else

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-21 13:57

Message:
Duplicate of http://rubyforge.org/tracker/?group_id=797&atid=3152&func=detail&aid=8654

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

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

From noreply at rubyforge.org  Sun Oct 21 13:40:43 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 21 Oct 2007 13:40:43 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14923 ] Nested shared behaviours get
	executed twice
Message-ID: <20071021174043.D06A718585FA@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Wincent Colaiuta (wincent)
Assigned to: Nobody (None)
Summary: Nested shared behaviours get executed twice

Initial Comment:
My original mailing list post follows:

http://rubyforge.org/pipermail/rspec-users/2007-October/003989.html

Given the following ApplicationController specs:

  describe ApplicationController, "one facet", :shared => true do
    it 'foo' ...
    it 'bar' ...
  end

  describe ApplicationController, "some other facet", :shared => true do
    it 'abc' ...
    it 'xyz' ...
  end

  describe ApplicationController, :shared => true do
    it_should_behave_like 'ApplicationController one facet'
    it_should_behave_like 'ApplicationController some other facet'
  end

And corresponding ApplicationController subclass specs:

  describe OtherController do
    it_should_behave_like 'ApplicationController'
  end

Both of the shared behaviour blocks get executed twice when running the subclass specs; the specdoc output looks like:

  OtherController
  - foo
  - bar
  - abc
  - xyz
  - abc
  - xyz
  - foo
  - bar

And note that it's running the shared behaviours in this order:

  - 'one facet'
  - 'some other facet'
  - 'some other facet'
  - 'one facet'

Not actually a big deal; seeing as the specs don't have any side-effects and running them twice is harmless, and in any case getting rid of the nesting (putting all the specs in a single shared behaviour block) gets rid of the duplicate.

Will shortly come up with a test case that exhibits the bug. That way when this is fixed we'll have a regression test to make sure it doesn't ever creep back in.

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

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

From noreply at rubyforge.org  Sun Oct 21 14:23:24 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 21 Oct 2007 14:23:24 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14923 ] Nested shared behaviours get
	executed twice
Message-ID: <20071021182324.A971518585FE@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Wincent Colaiuta (wincent)
Assigned to: Nobody (None)
Summary: Nested shared behaviours get executed twice

Initial Comment:
My original mailing list post follows:

http://rubyforge.org/pipermail/rspec-users/2007-October/003989.html

Given the following ApplicationController specs:

  describe ApplicationController, "one facet", :shared => true do
    it 'foo' ...
    it 'bar' ...
  end

  describe ApplicationController, "some other facet", :shared => true do
    it 'abc' ...
    it 'xyz' ...
  end

  describe ApplicationController, :shared => true do
    it_should_behave_like 'ApplicationController one facet'
    it_should_behave_like 'ApplicationController some other facet'
  end

And corresponding ApplicationController subclass specs:

  describe OtherController do
    it_should_behave_like 'ApplicationController'
  end

Both of the shared behaviour blocks get executed twice when running the subclass specs; the specdoc output looks like:

  OtherController
  - foo
  - bar
  - abc
  - xyz
  - abc
  - xyz
  - foo
  - bar

And note that it's running the shared behaviours in this order:

  - 'one facet'
  - 'some other facet'
  - 'some other facet'
  - 'one facet'

Not actually a big deal; seeing as the specs don't have any side-effects and running them twice is harmless, and in any case getting rid of the nesting (putting all the specs in a single shared behaviour block) gets rid of the duplicate.

Will shortly come up with a test case that exhibits the bug. That way when this is fixed we'll have a regression test to make sure it doesn't ever creep back in.

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

>Comment By: Wincent Colaiuta (wincent)
Date: 2007-10-21 18:23

Message:
Uploading a silly test case that demonstrates the bug.

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

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

From noreply at rubyforge.org  Sun Oct 21 14:39:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 21 Oct 2007 14:39:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14824 ]
	Spec::Runner.configuration.include does not work for
	ActionController::UrlWriter
Message-ID: <20071021183927.524A41858647@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Spec::Runner.configuration.include does not work for ActionController::UrlWriter

Initial Comment:
Spec::Runner.configure do |config|
  config.include ActionController::UrlWriter
end

Inside of UrlRewriter is:
module ActionController::UrlWriter
  def self.included(base) #:nodoc:
    ActionController::Routing::Routes.named_routes.install base
    base.mattr_accessor :default_url_options
    base.default_url_options ||= default_url_options
  end
end

Here is the error message:
NoMethodError in 'BlockingsController destroy redirects on successful destroy'
undefined method `default_url_options' for #<Class:0x4cf45c8>
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.13.5/lib/action_controller/url_rewriter.rb:41:in `url_for'
(eval):19:in `user_contacts_path'
/Users/pivotal/workspace/socialitis/vendor/plugins/connections/spec/controllers/blockings_controller_spec.rb:30:
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `instance_eval'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_module.rb:171:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:65:in `run_example'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:26:in `run'
/usr/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_runner.rb:24:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:26:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/dsl/example_suite.rb:22:in `rspec_run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/test/unit/example_suite.rb:7:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:12:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `each'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/behaviour_runner.rb:11:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec/runner/options.rb:71:in `run_examples'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:18:in `run'
/Users/pivotal/workspace/socialitis/vendor/plugins/rspec/lib/spec.rb:27:
-e:1:


The following does work:
class Spec::DSL::Example
  include ActionController::UrlWriter
end

class Spec::Test::Unit::Example
  include ActionController::UrlWriter
end


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

>Comment By: Brian Takita (btakita)
Date: 2007-10-21 11:39

Message:
rev 2756

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

Comment By: Brian Takita (btakita)
Date: 2007-10-17 23:26

Message:
Well it "works" because the include happens in the context
of Object.

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

Comment By: Brian Takita (btakita)
Date: 2007-10-17 23:25

Message:
Spec::Runner.configure do |config|
  include ActionController::UrlWriter
end

also works.

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

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

From noreply at rubyforge.org  Sun Oct 21 14:47:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 21 Oct 2007 14:47:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12698 ] ::Dispatcher.reset_application!
	causes exception
Message-ID: <20071021184716.132A818585E4@rubyforge.org>

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

Category: Autotest
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: ::Dispatcher.reset_application! causes exception

Initial Comment:
Here is the backtrace. This happens in spec_server.rb

(druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:93:in `clear_reloadable_connections!': undefined method `requires_reloading?' for {}:Hash (NoMethodError)
	from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:92:in `each'
	from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/connection_adapters/abstract/connection_specification.rb:92:in `clear_reloadable_connections!'
	from (druby://localhost:8989) /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/dispatcher.rb:65:in `reset_application!'
	from (druby://localhost:8989) ./script/spec_server:21:in `run'
	from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/drb_command_line.rb:13:in `run'
	from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:188:in `parse_drb'
	from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/option_parser.rb:147:in `parse'
	from /usr/local/lib/ruby/1.8/optparse.rb:1260:in `call'
	 ... 8 levels...
	from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/lib/spec/runner/command_line.rb:14:in `run'
	from /usr/local/lib/ruby/gems/1.8/gems/rspec-1.0.5/bin/spec:3
	from /usr/local/bin/spec:16:in `load'
	from /usr/local/bin/spec:16


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

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

Message:
Here is my redefined run method that fixes this issue:

module Spec
  module Runner
    class RailsSpecServer
      def run(args, stderr, stdout)
        $stdout = stdout
        $stderr = stderr

        Dependencies.mechanism = :load
        Dependencies.clear
        
        ::Spec::Runner::CommandLine.run(args, stderr,
stdout, false, true)
      end
    end
  end
end


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

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

From noreply at rubyforge.org  Sun Oct 21 15:21:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Sun, 21 Oct 2007 15:21:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14923 ] Nested shared behaviours get
	executed twice
Message-ID: <20071021192116.88DAE18585C3@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Wincent Colaiuta (wincent)
Assigned to: Nobody (None)
Summary: Nested shared behaviours get executed twice

Initial Comment:
My original mailing list post follows:

http://rubyforge.org/pipermail/rspec-users/2007-October/003989.html

Given the following ApplicationController specs:

  describe ApplicationController, "one facet", :shared => true do
    it 'foo' ...
    it 'bar' ...
  end

  describe ApplicationController, "some other facet", :shared => true do
    it 'abc' ...
    it 'xyz' ...
  end

  describe ApplicationController, :shared => true do
    it_should_behave_like 'ApplicationController one facet'
    it_should_behave_like 'ApplicationController some other facet'
  end

And corresponding ApplicationController subclass specs:

  describe OtherController do
    it_should_behave_like 'ApplicationController'
  end

Both of the shared behaviour blocks get executed twice when running the subclass specs; the specdoc output looks like:

  OtherController
  - foo
  - bar
  - abc
  - xyz
  - abc
  - xyz
  - foo
  - bar

And note that it's running the shared behaviours in this order:

  - 'one facet'
  - 'some other facet'
  - 'some other facet'
  - 'one facet'

Not actually a big deal; seeing as the specs don't have any side-effects and running them twice is harmless, and in any case getting rid of the nesting (putting all the specs in a single shared behaviour block) gets rid of the duplicate.

Will shortly come up with a test case that exhibits the bug. That way when this is fixed we'll have a regression test to make sure it doesn't ever creep back in.

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

>Comment By: Wincent Colaiuta (wincent)
Date: 2007-10-21 19:21

Message:
On exploring further I think the problem lies in at line 44 of rspec/lib/spec/dsl/shared_behaviour.rb (here I've commented it out):

      def included(mod) # :nodoc:
        example_definitions.each { |e| mod.example_definitions << e }
        before_each_parts.each   { |p| mod.before_each_parts << p }
        after_each_parts.each    { |p| mod.after_each_parts << p }
        before_all_parts.each    { |p| mod.before_all_parts << p }
        after_all_parts.each     { |p| mod.after_all_parts << p }
        #included_modules.each    { |m| mod.__send__(:include, m) }
      end

Note that when a shared behaviour module is included, all of its included modules are explicitly included as well. This seems 
redundant, as shown in the following IRB session:

  irb> module Foo; end
  => nil
  irb> module Bar
  irb>   include Foo
  irb> end
  => Bar
  irb> Bar.included_modules
  => [Foo]
  irb> module X
  irb>   include Bar
  irb> end
  => X
  irb> X.included_modules
  => [Bar, Foo]

Notice how X includes not only Bar (which it included explicitly) but Foo as well (which it gets indirectly). Also note how the order 
of included modules is listed as "Bar, Foo"; this explains why the duplicate methods were being added in the order "A, B, B, A".

Attaching a patch which removes the redundant recursive include. Seems like a good idea as this problem will only get worse as you 
nest more and more levels deeply in nested shared behaviours. All specs still pass with this change, except for some Rails tests which 
were already broken before the changes; I suspect this breakage is unrelated and probably something to do with Edge Rails.

This patch also removes a redundant semi-colon in the same hunk of code; please let me know if you prefer this kind of unrelated 
correction to be in a separate patch.

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-10-21 18:23

Message:
Uploading a silly test case that demonstrates the bug.

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

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

From dchelimsky at gmail.com  Sun Oct 21 19:33:19 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 21 Oct 2007 18:33:19 -0500
Subject: [rspec-devel] plain text stories
Message-ID: <57c63afe0710211633s2bc18feep8660c615a974d4d1@mail.gmail.com>

Thanks to discussions on this list, suggestions from many of you and a
patch from Pat Maddox, we now have Plain Text User Stories in Story
Runner.

Read more:

http://blog.davidchelimsky.net/articles/2007/10/21/story-runner-in-plain-english

Cheers,
David

From joshuachisholm at gmail.com  Mon Oct 22 05:34:55 2007
From: joshuachisholm at gmail.com (Josh Chisholm)
Date: Mon, 22 Oct 2007 10:34:55 +0100
Subject: [rspec-devel] first cut at blockless given/when/then
In-Reply-To: <ad4f9af90710191705h322eae7apeca69ccc08ef4ba9@mail.gmail.com>
References: <ad4f9af90710191705h322eae7apeca69ccc08ef4ba9@mail.gmail.com>
Message-ID: <1126d7ae0710220234v2484d6c8qec5fd1d8f079a77a@mail.gmail.com>

I don't know if this is still open for discussion, but I had a thought
relating back to one of Pat's suggestions:

> I had thought about putting the match method on string, so it becomes
> "an addend of $addend".matcher(:given) do {blah blah}
> or something similar.  But I don't really like that because I want
> "given" to be the first thing on the line.

...so we ended up with:

step_matchers do | add |
    add.given("my savings account balance is $balance") do |balance|
      @savings_account = Account.new(balance.to_f)
    end
end

my thought is... would it be wrong to take the first word of the
matcher itself to determine its type? e.g:

step_matchers do
    "given my savings account balance is $balance".means do |balance|
      @savings_account = Account.new(balance.to_f)
    end
end

wdyt?

On 10/20/07, Ian Dees <undees at gmail.com> wrote:
> Hi, Pat.
>
> > > Thinking out loud for larger projects here....  What's the scope (or
> > > lifetime -- I'm not sure what to call it) of a step created by
> > > step_matcher?  How does it know which Story to attach to?
> >
> > I don't think that's been figured out yet.  I chatted with David a bit
> > earlier this evening and we were brainstorming a little, but the convo
> > got cut short.  If you've got ideas I'd love to hear them.
>
> I'm not sure I have a solution, but I have some puzzles.
>
> Some steps might need to work for multiple stories.  A story about
> managing users (with several scenarios) and another story about
> managing blog posts (also with several scenarios) might both benefit
> from a "when I log in as an administrator" step.  So something like a
> story_helper.rb file could get included into multiple stories.
>
> On the other hand...
>
> Some steps are definitely story-specific.  A bowling game and a
> football game (take your pick which kind of football) might each have
> a "Given a new game" step.  We'd want to avoid collision somehow,
> either by non-RSpec methods (file/directory/require organization) or
> by some kind of optional namespacing:
>
> step_helper(:given, 'A new game', :story => 'bowling') do
>   @game = BowlingGame.new
> end
>
> > step_matcher(:given, "an addend of $addend")
> >
> > stands on its own.  At a glance you can tell that it's used as a
> > given.  Contrast that with scouring hundreds of lines of
> >
> > step_matcher("an addend of $addend")
> > step_matcher("an augend of $augend")
> > step_matcher("a tightend of $tightend")
>
> I dunno, it looks to me like those are all Given steps.  I certainly
> can't imagine "when an addend of $addend" or "then an addend of
> $addend."
>
> The Given/:given capitalization and colon mismatch is actually more
> distracting to me than a lack of a prefix; I'd constantly be typing
> the wrong one.  But maybe I'm just clumsy....
>
> --Ian
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From noreply at rubyforge.org  Mon Oct 22 16:17:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Oct 2007 16:17:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14955 ] config.fixture_path= method does
	not work with Rails 2.0
Message-ID: <20071022201727.284891858601@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: config.fixture_path= method does not work with Rails 2.0

Initial Comment:
Setting config.fixture_path= does not affect where rspec looks for the fixtures.

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

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

From noreply at rubyforge.org  Mon Oct 22 19:06:45 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Oct 2007 19:06:45 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14959 ] Issues with config.before and
	config.after for the default behaviour_type
Message-ID: <20071022230645.9715C18585D7@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Issues with config.before and config.after for the default behaviour_type

Initial Comment:
These examples do not seem to work:
config.before(:each) do
end

config.after(:each) do
end


These examples do seem to work:
config.before(:each, :behaviour_type => :model) do
end

config.after(:each, :behaviour_type => :model) do
end

class Spec::Rails::DSL::ModelExample
  before(:each) do
  end

  after(:each) do
  end
end



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

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

From noreply at rubyforge.org  Mon Oct 22 20:45:40 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Oct 2007 20:45:40 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14388 ] protect_against_forgery? helper
	method not being picked up by rspec_on_rails
Message-ID: <20071023004540.764E118585D0@rubyforge.org>

Bugs item #14388, was opened at 2007-10-02 12: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

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

>Comment By: Brian Takita (btakita)
Date: 2007-10-22 17:45

Message:
There is a fundamental issue with Helper Specs. Ideally,
helper specs should call the view object that has been
properly constructed.

Perhaps we can utilize method_missing to delegate to the
view object?

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

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

From noreply at rubyforge.org  Mon Oct 22 23:15:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 22 Oct 2007 23:15:47 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14969 ] 'render' should
	support :text property like rails
Message-ID: <20071023031547.6823818585F0@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Steve V (vertebrate)
Assigned to: Nobody (None)
Summary: 'render' should support :text property like rails

Initial Comment:
The 'render' method for views should support a :text attribute similar to the 'render' method for Rails. One example of its usefulness would be in verifying that a layout calls yield.

render :text => '<div>yielded</div>', :layout => 'application'
response.should have_tag('div', 'yielded')

This is being posted as requested in the users list thread "Testing layouts with RSpec on Rails"

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

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

From noreply at rubyforge.org  Tue Oct 23 02:39:22 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 02:39:22 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14959 ] Issues with config.before and
	config.after for the default behaviour_type
Message-ID: <20071023063922.C832F18585B9@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Issues with config.before and config.after for the default behaviour_type

Initial Comment:
These examples do not seem to work:
config.before(:each) do
end

config.after(:each) do
end


These examples do seem to work:
config.before(:each, :behaviour_type => :model) do
end

config.after(:each, :behaviour_type => :model) do
end

class Spec::Rails::DSL::ModelExample
  before(:each) do
  end

  after(:each) do
  end
end



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

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

From noreply at rubyforge.org  Tue Oct 23 02:45:27 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 02:45:27 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14923 ] Nested shared behaviours get
	executed twice
Message-ID: <20071023064527.A753218585E2@rubyforge.org>

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

Category: runner module
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Wincent Colaiuta (wincent)
Assigned to: Nobody (None)
Summary: Nested shared behaviours get executed twice

Initial Comment:
My original mailing list post follows:

http://rubyforge.org/pipermail/rspec-users/2007-October/003989.html

Given the following ApplicationController specs:

  describe ApplicationController, "one facet", :shared => true do
    it 'foo' ...
    it 'bar' ...
  end

  describe ApplicationController, "some other facet", :shared => true do
    it 'abc' ...
    it 'xyz' ...
  end

  describe ApplicationController, :shared => true do
    it_should_behave_like 'ApplicationController one facet'
    it_should_behave_like 'ApplicationController some other facet'
  end

And corresponding ApplicationController subclass specs:

  describe OtherController do
    it_should_behave_like 'ApplicationController'
  end

Both of the shared behaviour blocks get executed twice when running the subclass specs; the specdoc output looks like:

  OtherController
  - foo
  - bar
  - abc
  - xyz
  - abc
  - xyz
  - foo
  - bar

And note that it's running the shared behaviours in this order:

  - 'one facet'
  - 'some other facet'
  - 'some other facet'
  - 'one facet'

Not actually a big deal; seeing as the specs don't have any side-effects and running them twice is harmless, and in any case getting rid of the nesting (putting all the specs in a single shared behaviour block) gets rid of the duplicate.

Will shortly come up with a test case that exhibits the bug. That way when this is fixed we'll have a regression test to make sure it doesn't ever creep back in.

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

>Comment By: Brian Takita (btakita)
Date: 2007-10-22 23:45

Message:
Thank you Wincent. I checked in your fix in Rev. 2769.

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

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

Message:
On exploring further I think the problem lies in at line 44 of rspec/lib/spec/dsl/shared_behaviour.rb (here I've commented it out):

      def included(mod) # :nodoc:
        example_definitions.each { |e| mod.example_definitions << e }
        before_each_parts.each   { |p| mod.before_each_parts << p }
        after_each_parts.each    { |p| mod.after_each_parts << p }
        before_all_parts.each    { |p| mod.before_all_parts << p }
        after_all_parts.each     { |p| mod.after_all_parts << p }
        #included_modules.each    { |m| mod.__send__(:include, m) }
      end

Note that when a shared behaviour module is included, all of its included modules are explicitly included as well. This seems 
redundant, as shown in the following IRB session:

  irb> module Foo; end
  => nil
  irb> module Bar
  irb>   include Foo
  irb> end
  => Bar
  irb> Bar.included_modules
  => [Foo]
  irb> module X
  irb>   include Bar
  irb> end
  => X
  irb> X.included_modules
  => [Bar, Foo]

Notice how X includes not only Bar (which it included explicitly) but Foo as well (which it gets indirectly). Also note how the order 
of included modules is listed as "Bar, Foo"; this explains why the duplicate methods were being added in the order "A, B, B, A".

Attaching a patch which removes the redundant recursive include. Seems like a good idea as this problem will only get worse as you 
nest more and more levels deeply in nested shared behaviours. All specs still pass with this change, except for some Rails tests which 
were already broken before the changes; I suspect this breakage is unrelated and probably something to do with Edge Rails.

This patch also removes a redundant semi-colon in the same hunk of code; please let me know if you prefer this kind of unrelated 
correction to be in a separate patch.

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-10-21 11:23

Message:
Uploading a silly test case that demonstrates the bug.

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

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

From noreply at rubyforge.org  Tue Oct 23 03:10:19 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 03:10:19 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14388 ] protect_against_forgery? helper
	method not being picked up by rspec_on_rails
Message-ID: <20071023071019.50AD718585EE@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
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

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

>Comment By: Brian Takita (btakita)
Date: 2007-10-23 00:10

Message:
Thank you. I applied this in revision 2769.

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

Comment By: Brian Takita (btakita)
Date: 2007-10-22 17:45

Message:
There is a fundamental issue with Helper Specs. Ideally,
helper specs should call the view object that has been
properly constructed.

Perhaps we can utilize method_missing to delegate to the
view object?

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

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

From noreply at rubyforge.org  Tue Oct 23 03:39:46 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 03:39:46 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-13098 ] Error running &quot;
	script/spec_server&quot; after upgrading from 1.0.5 to 1.0.8
Message-ID: <20071023073946.67B9818585F0@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: Mike Breen (hardbap)
Assigned to: Nobody (None)
>Summary: Error running &quot;script/spec_server&quot; after upgrading from 1.0.5 to 1.0.8

Initial Comment:
RSpec version 1.0.8
Rails version 1.2.3
ruby 1.8.5

Windows XP SP 2
I do not have TextMate installed but I am using the Windows clone eText version 1.1.135beta

After upgrading to rspec version 1.0.8 I get this error when I attempt to start the spec_server at the command line with "ruby script/spec_server":

script/spec_server:9: undefined method '+' for nil:NilClass (NoMethodError)


The code from script/spec_server causing the issue can be found on lines 9-13:

...

specmate = ENV['HOME'] + "/Library/Application\Support/TextMate/Bundles/RSpec.tmbundle/Support/lib"
if File.directory?(specmate)
  $LOAD_PATH.unshift(specmate) 
  require 'text_mate_formatter'
end

...

Please note: script/spec_server will start normally after removing this code.

I understand that this is a Windows environment issue but I thought the team would like to be aware of it anyway.

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

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

From noreply at rubyforge.org  Tue Oct 23 03:41:10 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 03:41:10 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14923 ] Nested shared behaviours get
	executed twice
Message-ID: <20071023074110.36B9F18585F5@rubyforge.org>

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

Category: runner module
Group: None
Status: Closed
Resolution: None
Priority: 3
Submitted By: Wincent Colaiuta (wincent)
Assigned to: Nobody (None)
Summary: Nested shared behaviours get executed twice

Initial Comment:
My original mailing list post follows:

http://rubyforge.org/pipermail/rspec-users/2007-October/003989.html

Given the following ApplicationController specs:

  describe ApplicationController, "one facet", :shared => true do
    it 'foo' ...
    it 'bar' ...
  end

  describe ApplicationController, "some other facet", :shared => true do
    it 'abc' ...
    it 'xyz' ...
  end

  describe ApplicationController, :shared => true do
    it_should_behave_like 'ApplicationController one facet'
    it_should_behave_like 'ApplicationController some other facet'
  end

And corresponding ApplicationController subclass specs:

  describe OtherController do
    it_should_behave_like 'ApplicationController'
  end

Both of the shared behaviour blocks get executed twice when running the subclass specs; the specdoc output looks like:

  OtherController
  - foo
  - bar
  - abc
  - xyz
  - abc
  - xyz
  - foo
  - bar

And note that it's running the shared behaviours in this order:

  - 'one facet'
  - 'some other facet'
  - 'some other facet'
  - 'one facet'

Not actually a big deal; seeing as the specs don't have any side-effects and running them twice is harmless, and in any case getting rid of the nesting (putting all the specs in a single shared behaviour block) gets rid of the duplicate.

Will shortly come up with a test case that exhibits the bug. That way when this is fixed we'll have a regression test to make sure it doesn't ever creep back in.

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

>Comment By: Wincent Colaiuta (wincent)
Date: 2007-10-23 07:41

Message:
Thanks a lot, Brian.

I notice you didn't check in the accompanying spec. Wouldn't 
that be a good idea so that we catch any possible regressions 
in the future?

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

Comment By: Brian Takita (btakita)
Date: 2007-10-23 06:45

Message:
Thank you Wincent. I checked in your fix in Rev. 2769.

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-10-21 19:21

Message:
On exploring further I think the problem lies in at line 44 of rspec/lib/spec/dsl/shared_behaviour.rb (here I've commented it out):

      def included(mod) # :nodoc:
        example_definitions.each { |e| mod.example_definitions << e }
        before_each_parts.each   { |p| mod.before_each_parts << p }
        after_each_parts.each    { |p| mod.after_each_parts << p }
        before_all_parts.each    { |p| mod.before_all_parts << p }
        after_all_parts.each     { |p| mod.after_all_parts << p }
        #included_modules.each    { |m| mod.__send__(:include, m) }
      end

Note that when a shared behaviour module is included, all of its included modules are explicitly included as well. This seems 
redundant, as shown in the following IRB session:

  irb> module Foo; end
  => nil
  irb> module Bar
  irb>   include Foo
  irb> end
  => Bar
  irb> Bar.included_modules
  => [Foo]
  irb> module X
  irb>   include Bar
  irb> end
  => X
  irb> X.included_modules
  => [Bar, Foo]

Notice how X includes not only Bar (which it included explicitly) but Foo as well (which it gets indirectly). Also note how the order 
of included modules is listed as "Bar, Foo"; this explains why the duplicate methods were being added in the order "A, B, B, A".

Attaching a patch which removes the redundant recursive include. Seems like a good idea as this problem will only get worse as you 
nest more and more levels deeply in nested shared behaviours. All specs still pass with this change, except for some Rails tests which 
were already broken before the changes; I suspect this breakage is unrelated and probably something to do with Edge Rails.

This patch also removes a redundant semi-colon in the same hunk of code; please let me know if you prefer this kind of unrelated 
correction to be in a separate patch.

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

Comment By: Wincent Colaiuta (wincent)
Date: 2007-10-21 18:23

Message:
Uploading a silly test case that demonstrates the bug.

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

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

From noreply at rubyforge.org  Tue Oct 23 04:15:51 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 04:15:51 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14980 ] Nested Behaviour --
	reopened
Message-ID: <20071023081551.8108B18585BB@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Nested Behaviour -- reopened

Initial Comment:
I'd like to reopen discussion for Nested Behaviour. On my current project, we are in a situation where nested describe blocks would be an elegant way to organize our examples.

It should be easy to implement given the current state of the source.
All that needs to be done is have Example.describe create a subclass of the current class.

Currently, here is our setup:

module AssociationMethods
  describe Person, "#games" do
  end
end

module CustomMethods
  describe Person, "#current_game" do
  end
end

Having nested describe blocks would allow:
describe Person, "association methods" do
  describe Person, "#games" do
  end
end

describe Person, "custom methods" do
  describe Person, "#current_game" do
  end
end

Also nested behaviour would allow sharing of before and after blocks.

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

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

From noreply at rubyforge.org  Tue Oct 23 09:33:47 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 09:33:47 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14980 ] Nested Behaviour --
	reopened
Message-ID: <20071023133347.517C41858608@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Nested Behaviour -- reopened

Initial Comment:
I'd like to reopen discussion for Nested Behaviour. On my current project, we are in a situation where nested describe blocks would be an elegant way to organize our examples.

It should be easy to implement given the current state of the source.
All that needs to be done is have Example.describe create a subclass of the current class.

Currently, here is our setup:

module AssociationMethods
  describe Person, "#games" do
  end
end

module CustomMethods
  describe Person, "#current_game" do
  end
end

Having nested describe blocks would allow:
describe Person, "association methods" do
  describe Person, "#games" do
  end
end

describe Person, "custom methods" do
  describe Person, "#current_game" do
  end
end

Also nested behaviour would allow sharing of before and after blocks.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 13:33

Message:
Well, as you might imagine, I am very resistant to this. First, a few questions:

What would be the order of precedence of befores and afters?
What about a before(:all) or after(:all)?
How would they relate to the befores/afters set up globally?
What would the output look like?
Would the output be nested too? How deeply? Is there a limit?
Can we have examples inside the outer spec?
What is the scope of helper methods?
What happens with the --reverse flag.

I'm sure there are more of these questions that I'm not thinking of yet. I really think that this would open up a can of procedural worms that I'd be inclined to leave closed.

Additionally, even if all of my questions are answered easily, I can guarantee that it will lead to long debugging sessions focused on specs, which is exactly the opposite of where rspec should take you. I'd really hate to see the rspec lists get flooded with questions from people who are creating deeply nested hierarchies of specs and having trouble understanding why they aren't working. That's just not what this is all about.

My vote is nay.

But I'm open :)


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

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

From noreply at rubyforge.org  Tue Oct 23 09:59:28 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 09:59:28 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14980 ] Nested Behaviour --
	reopened
Message-ID: <20071023135928.1CCCC18585F7@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Nested Behaviour -- reopened

Initial Comment:
I'd like to reopen discussion for Nested Behaviour. On my current project, we are in a situation where nested describe blocks would be an elegant way to organize our examples.

It should be easy to implement given the current state of the source.
All that needs to be done is have Example.describe create a subclass of the current class.

Currently, here is our setup:

module AssociationMethods
  describe Person, "#games" do
  end
end

module CustomMethods
  describe Person, "#current_game" do
  end
end

Having nested describe blocks would allow:
describe Person, "association methods" do
  describe Person, "#games" do
  end
end

describe Person, "custom methods" do
  describe Person, "#current_game" do
  end
end

Also nested behaviour would allow sharing of before and after blocks.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 13:59

Message:
... in fact, I'm so open that here is my proposal:

First let's close the loop on 1.1.0 issues and get that puppy out.

Once that's released, you should feel free to create a branch for this. It would be up to you to maintain it, keep it up to date w/ changes from trunk, etc. It would also be up to you to tend to questions on the mailing list related to this feature (and you can expect some from me as I'll be experimenting).

After some time, if people are using it and it is proving more beneficial than harmful, we can consider moving it into the trunk.

So a temporary fork of sorts. WDYT?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 13:33

Message:
Well, as you might imagine, I am very resistant to this. First, a few questions:

What would be the order of precedence of befores and afters?
What about a before(:all) or after(:all)?
How would they relate to the befores/afters set up globally?
What would the output look like?
Would the output be nested too? How deeply? Is there a limit?
Can we have examples inside the outer spec?
What is the scope of helper methods?
What happens with the --reverse flag.

I'm sure there are more of these questions that I'm not thinking of yet. I really think that this would open up a can of procedural worms that I'd be inclined to leave closed.

Additionally, even if all of my questions are answered easily, I can guarantee that it will lead to long debugging sessions focused on specs, which is exactly the opposite of where rspec should take you. I'd really hate to see the rspec lists get flooded with questions from people who are creating deeply nested hierarchies of specs and having trouble understanding why they aren't working. That's just not what this is all about.

My vote is nay.

But I'm open :)


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

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

From noreply at rubyforge.org  Tue Oct 23 13:19:56 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Tue, 23 Oct 2007 13:19:56 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14989 ] validate options in
	hashes passed to various methods like describe
Message-ID: <20071023171956.55DD51858675@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: validate options in hashes passed to various methods like describe

Initial Comment:
If I accidentally type :behavior_type instead of :behaviour_type, I get unexpected results and waste time debugging them.

It would be nice if the options hash passed to #describe was validated.

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

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

From dchelimsky at gmail.com  Tue Oct 23 13:20:22 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 23 Oct 2007 12:20:22 -0500
Subject: [rspec-devel] [ rspec-Feature Requests-14989 ] validate options
	in hashes passed to various methods like describe
In-Reply-To: <20071023171956.55DD51858675@rubyforge.org>
References: <20071023171956.55DD51858675@rubyforge.org>
Message-ID: <57c63afe0710231020w5eda7342u498836d623483739@mail.gmail.com>

Scott - this one's for you!

On 10/23/07, noreply at rubyforge.org <noreply at rubyforge.org> wrote:
> Feature Requests item #14989, was opened at 2007-10-23 17:19
> You can respond by visiting:
> http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14989&group_id=797
>
> Category: None
> Group: None
> Status: Open
> Priority: 3
> Submitted By: David Chelimsky (dchelimsky)
> Assigned to: Nobody (None)
> Summary: validate options in hashes passed to various methods like describe
>
> Initial Comment:
> If I accidentally type :behavior_type instead of :behaviour_type, I get unexpected results and waste time debugging them.
>
> It would be nice if the options hash passed to #describe was validated.
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> http://rubyforge.org/tracker/?func=detail&atid=3152&aid=14989&group_id=797
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From zach.dennis at gmail.com  Tue Oct 23 18:42:29 2007
From: zach.dennis at gmail.com (Zach Dennis)
Date: Tue, 23 Oct 2007 18:42:29 -0400
Subject: [rspec-devel] [rspec-users] plain text stories
In-Reply-To: <57c63afe0710211633s2bc18feep8660c615a974d4d1@mail.gmail.com>
References: <57c63afe0710211633s2bc18feep8660c615a974d4d1@mail.gmail.com>
Message-ID: <85d99afe0710231542q50a0d194hdef4f1f4dba036fa@mail.gmail.com>

Nice work David! This is a wonderful step in the right direction!
Zach Dennis
http://www.continuousthinking.com

On 10/21/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> Thanks to discussions on this list, suggestions from many of you and a
> patch from Pat Maddox, we now have Plain Text User Stories in Story
> Runner.
>
> Read more:
>
> http://blog.davidchelimsky.net/articles/2007/10/21/story
> -runner-in-plain-english
>
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>



-- 
Zach Dennis
http://www.continuousthinking.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071023/82d23387/attachment.html 

From dchelimsky at gmail.com  Wed Oct 24 01:07:03 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 24 Oct 2007 00:07:03 -0500
Subject: [rspec-devel] changes to Story Runner steps
Message-ID: <57c63afe0710232207t1bccd932n6dc68ca00fbd4e5d@mail.gmail.com>

Hi all,

The following only affects people who have bravely begun to experiment
with the 2 day-old plain text story runner and definable groups of
steps.

For those who fit that bill, I just committed a few changes that will
require you to make changes to your code.

The StepMatchers class is now the StepGroup class.

The step_matchers methods on PlainTextStoryRunner and StepGroup is now
just steps. So instead of defining a group like this:

# old - no longer supported
matchers = StepMatchers.new do
  step_matchers do |add|
    add.given(...) {...}
  end
end

# new
steps = StepGroup.new do
  steps do |add|
    add.given(...) {...}
  end
end

And actually, I've tried 'define' instead of 'add' for the block arg
and it speaks pretty nicely:

steps = StepGroup.new do
  steps do |define|
    define.given(...) {...}
  end
end

There will be more changes coming over the next few days. Just a heads up.

From noreply at rubyforge.org  Wed Oct 24 02:35:36 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 24 Oct 2007 02:35:36 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-14980 ] Nested Behaviour --
	reopened
Message-ID: <20071024063536.3406118585E1@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Nested Behaviour -- reopened

Initial Comment:
I'd like to reopen discussion for Nested Behaviour. On my current project, we are in a situation where nested describe blocks would be an elegant way to organize our examples.

It should be easy to implement given the current state of the source.
All that needs to be done is have Example.describe create a subclass of the current class.

Currently, here is our setup:

module AssociationMethods
  describe Person, "#games" do
  end
end

module CustomMethods
  describe Person, "#current_game" do
  end
end

Having nested describe blocks would allow:
describe Person, "association methods" do
  describe Person, "#games" do
  end
end

describe Person, "custom methods" do
  describe Person, "#current_game" do
  end
end

Also nested behaviour would allow sharing of before and after blocks.

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

>Comment By: Brian Takita (btakita)
Date: 2007-10-23 23:35

Message:
First, I'd like to frame this with the status of the current
implementation:
There is an Example class. In rspec on rails, there is also
a RailsExample, ModelExample, ControllerExample,
ViewExample, and HelperExample.

before and after callbacks are registered on one of the
Example classes (aka Behaviours). When we get the callbacks
for a particular class, we also get the callbacks of the
superclasses.

For example, in a ModelExample before(:each), we get the
callbacks for:
Example.before(:each)
RailsExample.before(:each)
ModelExample.before(:each)

For after(:all), the order is:
ModelExample.before(:all)
RailsExample.before(:all)
Example.before(:all)

So there is a systematic way to get the before and after
callbacks based on inheritance.

I think the Example.behaviour method (nested behaviours)
would create a subclass of whatever class it is called from.
This would then use the existing before and after callback
structure.

So in reality, nesting describe blocks would be equivalent
to subclassing, which is something that rspec handles well
right now. I don't think it would be any more difficult to
debug than ordinary subclassing once the user knows that its
really inheritance being used.

I admit that this is probably an advanced feature. I propose
that we have a switch to turn it "on". The default will be
to not have this behaviour. If somebody wants to use it,
then they can call a method in Configuration.
This way, a fork will not be necessary.
I think that both the nested describes and the switch would
be simple to implement, since rspec is already architected
in the right way.


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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 06:59

Message:
... in fact, I'm so open that here is my proposal:

First let's close the loop on 1.1.0 issues and get that puppy out.

Once that's released, you should feel free to create a branch for this. It would be up to you to maintain it, keep it up to date w/ changes from trunk, etc. It would also be up to you to tend to questions on the mailing list related to this feature (and you can expect some from me as I'll be experimenting).

After some time, if people are using it and it is proving more beneficial than harmful, we can consider moving it into the trunk.

So a temporary fork of sorts. WDYT?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-23 06:33

Message:
Well, as you might imagine, I am very resistant to this. First, a few questions:

What would be the order of precedence of befores and afters?
What about a before(:all) or after(:all)?
How would they relate to the befores/afters set up globally?
What would the output look like?
Would the output be nested too? How deeply? Is there a limit?
Can we have examples inside the outer spec?
What is the scope of helper methods?
What happens with the --reverse flag.

I'm sure there are more of these questions that I'm not thinking of yet. I really think that this would open up a can of procedural worms that I'd be inclined to leave closed.

Additionally, even if all of my questions are answered easily, I can guarantee that it will lead to long debugging sessions focused on specs, which is exactly the opposite of where rspec should take you. I'd really hate to see the rspec lists get flooded with questions from people who are creating deeply nested hierarchies of specs and having trouble understanding why they aren't working. That's just not what this is all about.

My vote is nay.

But I'm open :)


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

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

From aslak.hellesoy at gmail.com  Wed Oct 24 03:35:26 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 24 Oct 2007 09:35:26 +0200
Subject: [rspec-devel] In-browser editor for RSpec stories
Message-ID: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>

Following David, Pat and the list's great work on the new plain text
stories, I felt I had to contribute something too:

http://blog.aslakhellesoy.com/2007/10/24/in-browser-editor-for-rspec-stories

This is actually something I started fiddling with at RailsConf EU,
but left in a very half-baked state. With the new plain text stories,
I think this can actually be useful.

Here is what I'm thinking: RSpec would be equipped by a tiny WEBrick
based webapp that lets you execute stories and get the result as HTML
- very much like classic RSpec. Take a look at the HTML - it's dead
simple.

Then, when it comes to the browser, some Javascript makes it all come
alive and lets the user edit the DOM-representation of the stories.
It's not implemented yet, but what I'm thinking is that the Javascript
could re-generate the story text(s) based on the current DOM and POST
it back to the browser. This would save the text to file (over the old
one) and possibly even do an svn commit.

WDYT?

From joshuachisholm at gmail.com  Wed Oct 24 04:52:01 2007
From: joshuachisholm at gmail.com (Josh Chisholm)
Date: Wed, 24 Oct 2007 09:52:01 +0100
Subject: [rspec-devel] In-browser editor for RSpec stories
In-Reply-To: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>
References: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>
Message-ID: <1126d7ae0710240152i65e8f0f6n1fbeb0d5df9e964@mail.gmail.com>

Nice work.

It would be extra nice if the UI could give feedback on how the text
corresponds to step matchers defined in the project. Ideally you could
"expand" a step in some way to see the code in the matcher as this
would reduce the "mapping" between the plain text stories and the
code.

In any case I think the "round-trip" GUI will make this idea a real winner.



On 10/24/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> Following David, Pat and the list's great work on the new plain text
> stories, I felt I had to contribute something too:
>
> http://blog.aslakhellesoy.com/2007/10/24/in-browser-editor-for-rspec-stories
>
> This is actually something I started fiddling with at RailsConf EU,
> but left in a very half-baked state. With the new plain text stories,
> I think this can actually be useful.
>
> Here is what I'm thinking: RSpec would be equipped by a tiny WEBrick
> based webapp that lets you execute stories and get the result as HTML
> - very much like classic RSpec. Take a look at the HTML - it's dead
> simple.
>
> Then, when it comes to the browser, some Javascript makes it all come
> alive and lets the user edit the DOM-representation of the stories.
> It's not implemented yet, but what I'm thinking is that the Javascript
> could re-generate the story text(s) based on the current DOM and POST
> it back to the browser. This would save the text to file (over the old
> one) and possibly even do an svn commit.
>
> WDYT?
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From joshuachisholm at gmail.com  Wed Oct 24 04:58:35 2007
From: joshuachisholm at gmail.com (Josh Chisholm)
Date: Wed, 24 Oct 2007 09:58:35 +0100
Subject: [rspec-devel] changes to Story Runner steps
In-Reply-To: <57c63afe0710232207t1bccd932n6dc68ca00fbd4e5d@mail.gmail.com>
References: <57c63afe0710232207t1bccd932n6dc68ca00fbd4e5d@mail.gmail.com>
Message-ID: <1126d7ae0710240158y614a0951ldaa34e6a958f6477@mail.gmail.com>

Hi David,

I don't know if this is still open for discussion, but would it be
wrong (or possible) to take the first word of the matcher itself to
determine its type? e.g:

steps = StepGroup.new do
  steps do
     "given my savings account balance is $balance".means do |balance|
         @savings_account = Account.new(balance.to_f)
      end
  end
end


On 10/24/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> Hi all,
>
> The following only affects people who have bravely begun to experiment
> with the 2 day-old plain text story runner and definable groups of
> steps.
>
> For those who fit that bill, I just committed a few changes that will
> require you to make changes to your code.
>
> The StepMatchers class is now the StepGroup class.
>
> The step_matchers methods on PlainTextStoryRunner and StepGroup is now
> just steps. So instead of defining a group like this:
>
> # old - no longer supported
> matchers = StepMatchers.new do
>   step_matchers do |add|
>     add.given(...) {...}
>   end
> end
>
> # new
> steps = StepGroup.new do
>   steps do |add|
>     add.given(...) {...}
>   end
> end
>
> And actually, I've tried 'define' instead of 'add' for the block arg
> and it speaks pretty nicely:
>
> steps = StepGroup.new do
>   steps do |define|
>     define.given(...) {...}
>   end
> end
>
> There will be more changes coming over the next few days. Just a heads up.
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Wed Oct 24 05:02:07 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 24 Oct 2007 11:02:07 +0200
Subject: [rspec-devel] In-browser editor for RSpec stories
In-Reply-To: <1126d7ae0710240152i65e8f0f6n1fbeb0d5df9e964@mail.gmail.com>
References: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>
	<1126d7ae0710240152i65e8f0f6n1fbeb0d5df9e964@mail.gmail.com>
Message-ID: <8d961d900710240202y5a874d96i891f7f482d756151@mail.gmail.com>

On 10/24/07, Josh Chisholm <joshuachisholm at gmail.com> wrote:
> Nice work.
>
> It would be extra nice if the UI could give feedback on how the text
> corresponds to step matchers defined in the project. Ideally you could

If you click "New step" and start typing a "g" (or "w" or "t"), the
autocompletion of available steps will help you.

> "expand" a step in some way to see the code in the matcher as this
> would reduce the "mapping" between the plain text stories and the
> code.

This is something that I will give low priority. The target audience
for this browser tool is people who don't read (or want to read) code.

>
> In any case I think the "round-trip" GUI will make this idea a real winner.
>

I hope so too!

>
>
> On 10/24/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > Following David, Pat and the list's great work on the new plain text
> > stories, I felt I had to contribute something too:
> >
> > http://blog.aslakhellesoy.com/2007/10/24/in-browser-editor-for-rspec-stories
> >
> > This is actually something I started fiddling with at RailsConf EU,
> > but left in a very half-baked state. With the new plain text stories,
> > I think this can actually be useful.
> >
> > Here is what I'm thinking: RSpec would be equipped by a tiny WEBrick
> > based webapp that lets you execute stories and get the result as HTML
> > - very much like classic RSpec. Take a look at the HTML - it's dead
> > simple.
> >
> > Then, when it comes to the browser, some Javascript makes it all come
> > alive and lets the user edit the DOM-representation of the stories.
> > It's not implemented yet, but what I'm thinking is that the Javascript
> > could re-generate the story text(s) based on the current DOM and POST
> > it back to the browser. This would save the text to file (over the old
> > one) and possibly even do an svn commit.
> >
> > WDYT?
> > _______________________________________________
> > 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 joshuachisholm at gmail.com  Wed Oct 24 05:05:18 2007
From: joshuachisholm at gmail.com (Josh Chisholm)
Date: Wed, 24 Oct 2007 10:05:18 +0100
Subject: [rspec-devel] In-browser editor for RSpec stories
In-Reply-To: <8d961d900710240202y5a874d96i891f7f482d756151@mail.gmail.com>
References: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>
	<1126d7ae0710240152i65e8f0f6n1fbeb0d5df9e964@mail.gmail.com>
	<8d961d900710240202y5a874d96i891f7f482d756151@mail.gmail.com>
Message-ID: <1126d7ae0710240205t2a57c9bbyae7ffe35afc135fe@mail.gmail.com>

> If you click "New step" and start typing a "g" (or "w" or "t"), the
> autocompletion of available steps will help you.

Ooops... brilliant!

On 10/24/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 10/24/07, Josh Chisholm <joshuachisholm at gmail.com> wrote:
> > Nice work.
> >
> > It would be extra nice if the UI could give feedback on how the text
> > corresponds to step matchers defined in the project. Ideally you could
>
> If you click "New step" and start typing a "g" (or "w" or "t"), the
> autocompletion of available steps will help you.
>
> > "expand" a step in some way to see the code in the matcher as this
> > would reduce the "mapping" between the plain text stories and the
> > code.
>
> This is something that I will give low priority. The target audience
> for this browser tool is people who don't read (or want to read) code.
>
> >
> > In any case I think the "round-trip" GUI will make this idea a real winner.
> >
>
> I hope so too!
>
> >
> >
> > On 10/24/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > Following David, Pat and the list's great work on the new plain text
> > > stories, I felt I had to contribute something too:
> > >
> > > http://blog.aslakhellesoy.com/2007/10/24/in-browser-editor-for-rspec-stories
> > >
> > > This is actually something I started fiddling with at RailsConf EU,
> > > but left in a very half-baked state. With the new plain text stories,
> > > I think this can actually be useful.
> > >
> > > Here is what I'm thinking: RSpec would be equipped by a tiny WEBrick
> > > based webapp that lets you execute stories and get the result as HTML
> > > - very much like classic RSpec. Take a look at the HTML - it's dead
> > > simple.
> > >
> > > Then, when it comes to the browser, some Javascript makes it all come
> > > alive and lets the user edit the DOM-representation of the stories.
> > > It's not implemented yet, but what I'm thinking is that the Javascript
> > > could re-generate the story text(s) based on the current DOM and POST
> > > it back to the browser. This would save the text to file (over the old
> > > one) and possibly even do an svn commit.
> > >
> > > WDYT?
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Wed Oct 24 07:58:02 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 24 Oct 2007 06:58:02 -0500
Subject: [rspec-devel] In-browser editor for RSpec stories
In-Reply-To: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>
References: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>
Message-ID: <57c63afe0710240458y45eb8928nb9cbce1ddc51890d@mail.gmail.com>

On 10/24/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> Following David, Pat and the list's great work on the new plain text
> stories, I felt I had to contribute something too:
>
> http://blog.aslakhellesoy.com/2007/10/24/in-browser-editor-for-rspec-stories

OMG. The future is upon us!

From dchelimsky at gmail.com  Wed Oct 24 08:53:47 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 24 Oct 2007 07:53:47 -0500
Subject: [rspec-devel] changes to Story Runner steps
In-Reply-To: <1126d7ae0710240158y614a0951ldaa34e6a958f6477@mail.gmail.com>
References: <57c63afe0710232207t1bccd932n6dc68ca00fbd4e5d@mail.gmail.com>
	<1126d7ae0710240158y614a0951ldaa34e6a958f6477@mail.gmail.com>
Message-ID: <57c63afe0710240553l40cae6ga23ba805f6833c91@mail.gmail.com>

On 10/24/07, Josh Chisholm <joshuachisholm at gmail.com> wrote:
> Hi David,
>
> I don't know if this is still open for discussion, but would it be
> wrong (or possible) to take the first word of the matcher itself to
> determine its type? e.g:
>
> steps = StepGroup.new do
>   steps do
>      "given my savings account balance is $balance".means do |balance|
>          @savings_account = Account.new(balance.to_f)
>       end
>   end
> end
Possible, yes. Wrong, no. Does that mean we should? Maybe. Maybe not.

First - we'll be doing something more in line with the rest of RSpec
to hide the SpecMatcher class. Dan and I have been batting this around
and I'm leaning towards something like this (Dan, please comment if
you're reading this):

steps_for :accounts do
  Given "my savings account balance is $balance" do |balance|
    @savings_account = Account.new(balance.to_f)
  end
end

Keep in mind that Ruby stories won't go away, so this means that
whether you're defining steps for a tag (more on that below) or
defining a Story in Ruby, you use the same Given/When/Then syntax.
While it would be sexy to bend String to our will as in your proposal,
I think this consistency is going to be important.

The tags would replace the need for defining subclasses of StepGroup.
In rake-like fashion, we can nest groups of steps like this:

steps_for :interest_bearing_accounts => [:accounts] do
  Given "my interest rate is $rate" { |rate| ... }
end

Then we could use them like this (not yet - this is all hypothetical):

using_steps_for :login, :navigation, :accounts do
  run 'path/to/story'
end

Thoughts?

David

From dchelimsky at gmail.com  Wed Oct 24 08:59:49 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 24 Oct 2007 07:59:49 -0500
Subject: [rspec-devel] changes to Story Runner steps
In-Reply-To: <57c63afe0710240553l40cae6ga23ba805f6833c91@mail.gmail.com>
References: <57c63afe0710232207t1bccd932n6dc68ca00fbd4e5d@mail.gmail.com>
	<1126d7ae0710240158y614a0951ldaa34e6a958f6477@mail.gmail.com>
	<57c63afe0710240553l40cae6ga23ba805f6833c91@mail.gmail.com>
Message-ID: <57c63afe0710240559w7c835569ia0dba988e7cfe40e@mail.gmail.com>

On 10/24/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> The tags would replace the need for defining subclasses of StepGroup.
> In rake-like fashion, we can nest groups of steps like this:
>
> steps_for :interest_bearing_accounts => [:accounts] do
>   Given "my interest rate is $rate" { |rate| ... }
> end

Or in a more rails like fashion, we could do this:

with_steps_for :accounts do
  define_steps_for :savings_accounts do
    Given "my interest rate is $rate" { |rate| ... }
  end
end

In fact - we could run stories in that context as well:

with_steps_for :accounts do
  Given "my interest rate is $rate" { |rate| ... }
  run 'path/to/story'
end

So with_steps_for would provide context for:

1. defining new groups of steps
2. defining steps that would only be used for one Story
3. running a Story

More thoughts?

From joshuachisholm at gmail.com  Wed Oct 24 09:43:22 2007
From: joshuachisholm at gmail.com (Josh Chisholm)
Date: Wed, 24 Oct 2007 14:43:22 +0100
Subject: [rspec-devel] changes to Story Runner steps
In-Reply-To: <57c63afe0710240559w7c835569ia0dba988e7cfe40e@mail.gmail.com>
References: <57c63afe0710232207t1bccd932n6dc68ca00fbd4e5d@mail.gmail.com>
	<1126d7ae0710240158y614a0951ldaa34e6a958f6477@mail.gmail.com>
	<57c63afe0710240553l40cae6ga23ba805f6833c91@mail.gmail.com>
	<57c63afe0710240559w7c835569ia0dba988e7cfe40e@mail.gmail.com>
Message-ID: <1126d7ae0710240643u438cf0b8y4fd9dcbfefb51145@mail.gmail.com>

Yeah this all makes sense.

The suggestion was less about sexy and more about mapping between the
story and the matcher. String bending lets you copy/paste the story
line (unaltered) into your matcher, which makes for a nice workflow
for the first few stories. But I totally buy the consistency argument,
I was thinking in plain text mode :-)


On 10/24/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 10/24/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > The tags would replace the need for defining subclasses of StepGroup.
> > In rake-like fashion, we can nest groups of steps like this:
> >
> > steps_for :interest_bearing_accounts => [:accounts] do
> >   Given "my interest rate is $rate" { |rate| ... }
> > end
>
> Or in a more rails like fashion, we could do this:
>
> with_steps_for :accounts do
>   define_steps_for :savings_accounts do
>     Given "my interest rate is $rate" { |rate| ... }
>   end
> end
>
> In fact - we could run stories in that context as well:
>
> with_steps_for :accounts do
>   Given "my interest rate is $rate" { |rate| ... }
>   run 'path/to/story'
> end
>
> So with_steps_for would provide context for:
>
> 1. defining new groups of steps
> 2. defining steps that would only be used for one Story
> 3. running a Story
>
> More thoughts?
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From me at johnwlong.com  Wed Oct 24 08:56:16 2007
From: me at johnwlong.com (John W. Long)
Date: Wed, 24 Oct 2007 08:56:16 -0400
Subject: [rspec-devel] [rspec-users] plain text stories
In-Reply-To: <57c63afe0710211633s2bc18feep8660c615a974d4d1@mail.gmail.com>
References: <57c63afe0710211633s2bc18feep8660c615a974d4d1@mail.gmail.com>
Message-ID: <471F40F0.4030308@johnwlong.com>

David Chelimsky wrote:
> Thanks to discussions on this list, suggestions from many of you and a
> patch from Pat Maddox, we now have Plain Text User Stories in Story
> Runner.

I'm having a lot of trouble understanding why stories are nice for me as 
a programmer? It seems targeted towards people who don't want to write 
code. Generally speaking, I don't see the need for that on the projects 
I'm working on.

Is it possible for this to be a separate library from RSpec so that 
RSpec core doesn't become bloated?

--
John Long
http://wiseheartdesign.com

From james at imaj.es  Wed Oct 24 03:40:22 2007
From: james at imaj.es (James Cox)
Date: Wed, 24 Oct 2007 08:40:22 +0100
Subject: [rspec-devel] In-browser editor for RSpec stories
In-Reply-To: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>
References: <8d961d900710240035o386f0181t7aaea3bff8101c5f@mail.gmail.com>
Message-ID: <CF1D604A-94FE-40E7-AA20-FF80D3F3877E@imaj.es>

Awesome.... looking forward to seeing a real working version :)

- james

On 24 Oct 2007, at 08:35, aslak hellesoy wrote:

> Following David, Pat and the list's great work on the new plain text
> stories, I felt I had to contribute something too:
>
> http://blog.aslakhellesoy.com/2007/10/24/in-browser-editor-for- 
> rspec-stories
>
> This is actually something I started fiddling with at RailsConf EU,
> but left in a very half-baked state. With the new plain text stories,
> I think this can actually be useful.
>
> Here is what I'm thinking: RSpec would be equipped by a tiny WEBrick
> based webapp that lets you execute stories and get the result as HTML
> - very much like classic RSpec. Take a look at the HTML - it's dead
> simple.
>
> Then, when it comes to the browser, some Javascript makes it all come
> alive and lets the user edit the DOM-representation of the stories.
> It's not implemented yet, but what I'm thinking is that the Javascript
> could re-generate the story text(s) based on the current DOM and POST
> it back to the browser. This would save the text to file (over the old
> one) and possibly even do an svn commit.
>
> WDYT?
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

--

James Cox,
Internet Consultant
t: 07968 349990  e: james at imaj.es w: http://imaj.es/



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

From 6mrxtt03 at sneakemail.com  Fri Oct 26 08:54:22 2007
From: 6mrxtt03 at sneakemail.com (Venkat)
Date: Fri, 26 Oct 2007 18:24:22 +0530
Subject: [rspec-devel] [#15082] Support for running Spec::UI in Linux
	platform using firewatir
Message-ID: <14923-79597@sneakemail.com>

Dear RSpec Devs:

Here is a small patch that may be useful to others. It is #15082 that
can be found in the rspec-ext project's tracker. I am posting it here
as I don't yet see any activity in the rspec-ext mailing list and this
may see more eyeballs.

Currently Spec::UI doesn't support running under Linux.

To support it you need to take care of two issues:

Issue #1:

Watir only runs on Windows and SafariWatir only on OS X. Thankfully
there is Firewatir which runs well on Linux (I tested
on Ubuntu Feisty). Firewatir can be found here:
http://code.google.com/p/firewatir/

This patch adds Linux support using Firewatir.

Issue #2:

You need a tool to take screenshot in Linux as well. This patch uses
ImageMagick's import command line tool for taking screen shots.

For a multi-monitor scenario, use something like devilspie to bring
the screen to foreground. In single monitor setup launching Firefox
automatically brings to foreground to aid screen shot taking.

If imagemagick is not found, a stub image indicating that fact is used
in place of screen shots.

Regards,
Venkat.

From noreply at rubyforge.org  Fri Oct 26 14:33:04 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 26 Oct 2007 14:33:04 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14955 ] config.fixture_path= method does
	not work with Rails 2.0
Message-ID: <20071026183304.7F1111858660@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: config.fixture_path= method does not work with Rails 2.0

Initial Comment:
Setting config.fixture_path= does not affect where rspec looks for the fixtures.

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

>Comment By: Brian Takita (btakita)
Date: 2007-10-26 11:33

Message:
It doesn't work with current Rails version either.
The problem is there is some code that expects
Test::Unit::TestCase.fixture_path to be written to.

Having Configuration#fixture_path= set
Test::Unit::TestCase.fixture_path would fix this.

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

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

From noreply at rubyforge.org  Fri Oct 26 14:34:08 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 26 Oct 2007 14:34:08 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12215 ] Misleading error message when
	passing string as first argument to raise_error
Message-ID: <20071026183408.3D4EB1858660@rubyforge.org>

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

Category: expectation module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Misleading error message when passing string as first argument to raise_error

Initial Comment:
describe "An example with raise_error" do
    it "should provide a nice error message when passed a string as a first argument" do
      proc do
        proc do
          raise "foobar"
        end.should raise_error("Called 4 times. Expected at most 3 times.")
      end.should raise_error(ArgumentError, "raise_error expects an Exception Class as its first argument")
    end
end

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

>Comment By: Brian Takita (btakita)
Date: 2007-10-26 11:34

Message:
lol. That sounds great. It only took me 3 months to respond.

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-23 05:22

Message:
Bueller? Bueller?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-11 22:44

Message:
How about allowing the first argument to be a String? That way, especially nice for RuntimeErrors, you can just specify the message and be done with it, unless you want to be more specific.

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

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

From noreply at rubyforge.org  Fri Oct 26 15:05:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 26 Oct 2007 15:05:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14955 ] config.fixture_path= method does
	not work with Rails 2.0
Message-ID: <20071026190558.4F75F185865E@rubyforge.org>

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

Category: rails plugin
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: config.fixture_path= method does not work with Rails 2.0

Initial Comment:
Setting config.fixture_path= does not affect where rspec looks for the fixtures.

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

>Comment By: Brian Takita (btakita)
Date: 2007-10-26 12:05

Message:
Actually setting Spec::Rails::DSL::Example.fixture_path
would be better.

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

Comment By: Brian Takita (btakita)
Date: 2007-10-26 11:33

Message:
It doesn't work with current Rails version either.
The problem is there is some code that expects
Test::Unit::TestCase.fixture_path to be written to.

Having Configuration#fixture_path= set
Test::Unit::TestCase.fixture_path would fix this.

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

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

From noreply at rubyforge.org  Fri Oct 26 15:16:12 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Fri, 26 Oct 2007 15:16:12 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-15088 ] Nested behaviour
	descriptions
Message-ID: <20071026191612.7929A1858662@rubyforge.org>

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

Category: None
Group: None
Status: Open
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Nested behaviour descriptions

Initial Comment:
This is a prerequisite to the Nested behaviour story.

class FooSpec < Spec::DSL::Example
  describe Foo
end

class DoingThisSpec < FooSpec
  describe "doing this"
  it "should blah" {}
end

class DoingThatSpec < FooSpec
  describe "doing that"
end

Would generate something like:
Foo:
- doing this:
-- should blah
- doing that:
-- should halb


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

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

From brian.takita at gmail.com  Fri Oct 26 17:29:30 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Fri, 26 Oct 2007 14:29:30 -0700
Subject: [rspec-devel] Rcov is failing
Message-ID: <1d7ddd110710261429g273dc430he7dd82057c72a9b4@mail.gmail.com>

Hey, I'm not sure what happened but the rcov part of the pre commit is
failing for me.
Does anybody else have the same issue?

From aslak.hellesoy at gmail.com  Sun Oct 28 18:28:00 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 28 Oct 2007 23:28:00 +0100
Subject: [rspec-devel] Concordion
Message-ID: <8d961d900710281528k153902far84394745c3ade9d3@mail.gmail.com>

I just stumbled across this:

http://www.concordion.org/

While I don't like the tight coupling to HTML and special tags, it's
interesting to see more tools in this space.

Aslak

From noreply at rubyforge.org  Mon Oct 29 00:30:48 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 29 Oct 2007 00:30:48 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-12215 ] Misleading error message when
	passing string as first argument to raise_error
Message-ID: <20071029043048.453CC18585D2@rubyforge.org>

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

Category: expectation module
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: Misleading error message when passing string as first argument to raise_error

Initial Comment:
describe "An example with raise_error" do
    it "should provide a nice error message when passed a string as a first argument" do
      proc do
        proc do
          raise "foobar"
        end.should raise_error("Called 4 times. Expected at most 3 times.")
      end.should raise_error(ArgumentError, "raise_error expects an Exception Class as its first argument")
    end
end

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-29 04:30

Message:
Actually, effective r2107 (6/23/07), should_raise accepts a string as the first arg. Closing this.

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

Comment By: Brian Takita (btakita)
Date: 2007-10-26 18:34

Message:
lol. That sounds great. It only took me 3 months to respond.

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

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

Message:
Bueller? Bueller?

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-07-12 05:44

Message:
How about allowing the first argument to be a String? That way, especially nice for RuntimeErrors, you can just specify the message and be done with it, unless you want to be more specific.

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

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

From brian.takita at gmail.com  Mon Oct 29 01:15:14 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 28 Oct 2007 22:15:14 -0700
Subject: [rspec-devel] Rcov is failing
In-Reply-To: <1d7ddd110710261429g273dc430he7dd82057c72a9b4@mail.gmail.com>
References: <1d7ddd110710261429g273dc430he7dd82057c72a9b4@mail.gmail.com>
Message-ID: <1d7ddd110710282215q39f1d97emd72f622278427694@mail.gmail.com>

I was using an old version of ParseTree. Updating it fixed the issue.

On 10/26/07, Brian Takita <brian.takita at gmail.com> wrote:
> Hey, I'm not sure what happened but the rcov part of the pre commit is
> failing for me.
> Does anybody else have the same issue?
>

From noreply at rubyforge.org  Mon Oct 29 03:28:01 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Mon, 29 Oct 2007 03:28:01 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14955 ] config.fixture_path= method does
	not work with Rails 2.0
Message-ID: <20071029072801.EEE5118585C0@rubyforge.org>

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

Category: rails plugin
Group: None
>Status: Deleted
Resolution: None
Priority: 3
Submitted By: Brian Takita (btakita)
Assigned to: Nobody (None)
Summary: config.fixture_path= method does not work with Rails 2.0

Initial Comment:
Setting config.fixture_path= does not affect where rspec looks for the fixtures.

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

Comment By: Brian Takita (btakita)
Date: 2007-10-26 12:05

Message:
Actually setting Spec::Rails::DSL::Example.fixture_path
would be better.

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

Comment By: Brian Takita (btakita)
Date: 2007-10-26 11:33

Message:
It doesn't work with current Rails version either.
The problem is there is some code that expects
Test::Unit::TestCase.fixture_path to be written to.

Having Configuration#fixture_path= set
Test::Unit::TestCase.fixture_path would fix this.

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

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

From tastapod at gmail.com  Mon Oct 29 12:08:07 2007
From: tastapod at gmail.com (Dan North)
Date: Mon, 29 Oct 2007 12:08:07 -0400
Subject: [rspec-devel] changes to Story Runner steps
In-Reply-To: <57c63afe0710240553l40cae6ga23ba805f6833c91@mail.gmail.com>
References: <57c63afe0710232207t1bccd932n6dc68ca00fbd4e5d@mail.gmail.com>
	<1126d7ae0710240158y614a0951ldaa34e6a958f6477@mail.gmail.com>
	<57c63afe0710240553l40cae6ga23ba805f6833c91@mail.gmail.com>
Message-ID: <d559d8430710290908m39175c4h9f8f576a4e6e51d9@mail.gmail.com>

Hi there.

Just catching up with the rspec lists. It looks like this happened only five
days ago, which is a lifetime in rspec trunk terms :)

Briefly, I'm loving what I'm seeing. David: you have very much captured the
flavour of what we discussed with groups and groups-of-groups. It's possible
the words will change, but the idea in principle is exactly right.
(Translation: people using trunk may find we go through a couple of
iterations of different method names and/or structures before it settles
down.)

Great stuff.

Cheers,
Dan


On 10/24/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 10/24/07, Josh Chisholm <joshuachisholm at gmail.com> wrote:
> > Hi David,
> >
> > I don't know if this is still open for discussion, but would it be
> > wrong (or possible) to take the first word of the matcher itself to
> > determine its type? e.g:
> >
> > steps = StepGroup.new do
> >   steps do
> >      "given my savings account balance is $balance".means do |balance|
> >          @savings_account = Account.new(balance.to_f)
> >       end
> >   end
> > end
> Possible, yes. Wrong, no. Does that mean we should? Maybe. Maybe not.
>
> First - we'll be doing something more in line with the rest of RSpec
> to hide the SpecMatcher class. Dan and I have been batting this around
> and I'm leaning towards something like this (Dan, please comment if
> you're reading this):
>
> steps_for :accounts do
>   Given "my savings account balance is $balance" do |balance|
>     @savings_account = Account.new(balance.to_f)
>   end
> end
>
> Keep in mind that Ruby stories won't go away, so this means that
> whether you're defining steps for a tag (more on that below) or
> defining a Story in Ruby, you use the same Given/When/Then syntax.
> While it would be sexy to bend String to our will as in your proposal,
> I think this consistency is going to be important.
>
> The tags would replace the need for defining subclasses of StepGroup.
> In rake-like fashion, we can nest groups of steps like this:
>
> steps_for :interest_bearing_accounts => [:accounts] do
>   Given "my interest rate is $rate" { |rate| ... }
> end
>
> Then we could use them like this (not yet - this is all hypothetical):
>
> using_steps_for :login, :navigation, :accounts do
>   run 'path/to/story'
> end
>
> Thoughts?
>
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20071029/73c213d3/attachment-0001.html 

From brian.takita at gmail.com  Tue Oct 30 02:31:37 2007
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 29 Oct 2007 23:31:37 -0700
Subject: [rspec-devel] Facets and/or Nested Describes
Message-ID: <1d7ddd110710292331l18b5fech86ce281005eb9d92@mail.gmail.com>

I have to confess that I did not know about facets before reading
Ashley Moran's post:
http://aviewfromafar.net/2007/10/21/quick-and-dirty-facets-in-rspec-trunk

Not knowing about the facets solution, I made a couple of feature
requests for nested describes:
http://rubyforge.org/tracker/index.php?func=detail&aid=14980&group_id=797&atid=3152
http://rubyforge.org/tracker/index.php?func=detail&aid=15088&group_id=797&atid=3152

Currently in trunk, Example is the base class and other examples
subclass. My proposal for the feature request is to have the
Behaviour#describe method creates a subclass of itself when passed a
block.

The subclass then walks up its superclass chain and composes its
description from its part and the parts of its superclasses.

So facets are being used out there. How is that working out?

There seems to be some overlap between the facets and nested describe
block solution.
Is facets a better solution than nested describes, (i.e. more
semantically useful)?

Implementation-wise, it seems that Example subclassing can be a
solution to implementing facets. In addition, you would get before and
after callbacks. Does that make sense for facets?

Thanks,
Brian

From noreply at rubyforge.org  Wed Oct 31 07:54:16 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 31 Oct 2007 07:54:16 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15232 ] heckle is not working correctly
	in trunk (as of r2801)
Message-ID: <20071031115416.6DB6318585DA@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: heckle is not working correctly in trunk (as of r2801)

Initial Comment:
# From trunk
$ cd rspec
$ ruby bin/spec examples/greeter_spec.rb --heckle Greeter
..

Finished in 0.030025 seconds

2 examples, 0 failures
**********************************************************************
***  Greeter#greet loaded with 3 possible mutations
**********************************************************************

3 mutations remaining...
2 mutations remaining...
1 mutations remaining...
No mutants survived. Cool!


Seems fine, except that it should be failing the heckling.

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

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

From noreply at rubyforge.org  Wed Oct 31 08:01:38 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 31 Oct 2007 08:01:38 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15232 ] heckle is not working correctly
	in trunk (as of r2801)
Message-ID: <20071031120138.3E36F18585DA@rubyforge.org>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
Assigned to: Nobody (None)
Summary: heckle is not working correctly in trunk (as of r2801)

Initial Comment:
# From trunk
$ cd rspec
$ ruby bin/spec examples/greeter_spec.rb --heckle Greeter
..

Finished in 0.030025 seconds

2 examples, 0 failures
**********************************************************************
***  Greeter#greet loaded with 3 possible mutations
**********************************************************************

3 mutations remaining...
2 mutations remaining...
1 mutations remaining...
No mutants survived. Cool!


Seems fine, except that it should be failing the heckling.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-31 12:01

Message:
It's because Spec::Runner::Options was changed to return success or failure instead of a number of failures, upon which heckle relies.

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

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

From noreply at rubyforge.org  Wed Oct 31 08:15:05 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 31 Oct 2007 08:15:05 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15232 ] heckle is not working correctly
	in trunk (as of r2801)
Message-ID: <20071031121505.8D2CB18585DA@rubyforge.org>

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

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: David Chelimsky (dchelimsky)
>Assigned to: David Chelimsky (dchelimsky)
Summary: heckle is not working correctly in trunk (as of r2801)

Initial Comment:
# From trunk
$ cd rspec
$ ruby bin/spec examples/greeter_spec.rb --heckle Greeter
..

Finished in 0.030025 seconds

2 examples, 0 failures
**********************************************************************
***  Greeter#greet loaded with 3 possible mutations
**********************************************************************

3 mutations remaining...
2 mutations remaining...
1 mutations remaining...
No mutants survived. Cool!


Seems fine, except that it should be failing the heckling.

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

>Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-31 12:15

Message:
Actually, heckle does not rely on it - it's RSpec's override of heckle's tests_pass? method that relies on it. A simple tweak to that method (driven by specs, of course) solves the problem.

Fixed in r2803

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

Comment By: David Chelimsky (dchelimsky)
Date: 2007-10-31 12:01

Message:
It's because Spec::Runner::Options was changed to return success or failure instead of a number of failures, upon which heckle relies.

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

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

From noreply at rubyforge.org  Wed Oct 31 08:39:17 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 31 Oct 2007 08:39:17 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-14406 ] rake spec:plugins:rspec_on_rails
	fails with Rails 2.0 preview release
Message-ID: <20071031123917.AB92218585CF@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: David Chelimsky (dchelimsky)
Date: 2007-10-31 12:39

Message:
OK - I've really resolved the first problem (trying to load helpers that don't exist). I had gotten it to work in rspec's pre_commit process based on env vars that get set during that process. Obviously that doesn't help when another app is using the plugin.

The problem of fixtures remains, but I see the path. Should have this fixed soon.

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

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 dchelimsky at gmail.com  Wed Oct 31 11:07:16 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 31 Oct 2007 10:07:16 -0500
Subject: [rspec-devel] Dev Process (was Am I missing something with Heckle?)
Message-ID: <57c63afe0710310807l9c69031neb12d6dfaa0692@mail.gmail.com>

[moving this over to the rspec-devel list]

On Oct 31, 2007 9:56 AM, Wincent Colaiuta <win at wincent.com> wrote:
> El 31/10/2007, a las 15:40, "David Chelimsky" <dchelimsky at gmail.com>
> escribi?:
>
> Recently with all of the activity on the story runner front I've
> thought that RSpec could benefit from a slightly more "branched"
> development process. At the moment it appears that *all* development
> activity occurs on the trunk, which means that when there are long
> periods between releases you have no choice but to live with the old
> version or sit on the bleeding edge.
>
> If RSpec had a "development" and "maintenance" branch (or "stable" and
> "devel"; "master" and "maint"; call them what you will) then it would
> be easier to contemplate intermediate maintenance releases while
> working on big new features which take a long time to get "baked in",
> like the story runner.

Actually, the pause has had little to do with the Story Runner. It's
been more closely related to a refactoring that started in a branch
and I OK'd merging into trunk long before it was ready.

> As an example, consider how the Rails 2.0 preview release came out and
> the trunk wasn't really ready to have a release cut from it for
> compatibility, so people have had to follow the trunk. It would have
> been nice to be able to cut a 1.0.9 release from a maintenance branch
> instead.

Yes, that's true.

> If the suckiness of Subversion's merge functionality is a problem then
> RSpec should consider moving to a different SCM, or at least layering
> one on top of the existing Subversion repo (ie. "the" Subversion repo
> continues to be the centralized distribution point, but the devs do
> the "real work" using Git).

We've been thinking of mercurial actually.

These are good ideas Wincent and we'll consider them. Keep in mind
that right now there are other priorities and this wouldn't happen
likely until early '08. But the door is certainly open for this
discussion.

Cheers,
David

From dchelimsky at gmail.com  Wed Oct 31 12:53:11 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 31 Oct 2007 11:53:11 -0500
Subject: [rspec-devel] Rspec Release Plan (was Am I missing something with
	Heckle?)
Message-ID: <57c63afe0710310953g5ed40c26v5aecb111a227c84d@mail.gmail.com>

On Oct 31, 2007 11:36 AM, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> When can we expect the next release of rspec?

Definitely by the end of November.
Likely by mid-November.
Hopefully in a matter of days.

The next release will be 1.1.0.

We're going to a release model in which 1.odd.x will be considered
experimental. This means that while we will document code-breaking
changes in subsequent releases (so you know what to do to move
forward), we will not commit to backwards compatibility to these
releases.

When we're ready to commit to a given API, we'll release 1.2.0. After
that we will be committed to backwards compatibility to 1.2.x (which
will implicitly remain compatible with 1.0.x).

Hope that all makes sense. This will give us the best opportunity to
get features out early with an understanding that they are subject to
change, while still allowing people who choose not to absorb that risk
to get features as they become less volatile.

Cheers,
David

From win at wincent.com  Wed Oct 31 14:10:09 2007
From: win at wincent.com (Wincent Colaiuta)
Date: Wed, 31 Oct 2007 19:10:09 +0100
Subject: [rspec-devel] Dev Process (was Am I missing something with
	Heckle?)
Message-ID: <234EEDF7-1141-4DA5-BF52-837169166E20@wincent.com>

On Oct 31, 2007, David Chelimsky wrote:

> These are good ideas Wincent and we'll consider them. Keep in mind
> that right now there are other priorities and this wouldn't happen
> likely until early '08. But the door is certainly open for this
> discussion.

Well, really just wanted to get it on the table, that's all. My main  
concern is that when things happen outside of the control of the RSpec  
team (eg. a compatibility-breaking Rails release) and the trunk isn't  
ready for it then we have a problem. And the obvious solution is to  
either:

- always keep the trunk in a releasable state (and do "risky" work on  
other branches); or:

- do the "risky" work on the trunk but also have a stable, maintenance  
branch that is ready to roll at any given time.

Personally *I* don't mind following the trunk when necessary, but I  
still think it's important to cater for those people who only install  
official releases.

Cheers,
Wincent


From noreply at rubyforge.org  Wed Oct 31 16:44:14 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 31 Oct 2007 16:44:14 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15244 ] spec --heckle command does not
	return error code to shell if heckling fails
Message-ID: <20071031204414.A29AB18585DA@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Nobody (None)
Summary: spec --heckle command does not return error code to shell if heckling fails

Initial Comment:
rev 2804

spec --heckle returns 0 in all cases, even when heckling flags unspecced code




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

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

From noreply at rubyforge.org  Wed Oct 31 16:45:18 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 31 Oct 2007 16:45:18 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15245 ] spec --heckle runs heckle even
	when there are initially failing specs fails
Message-ID: <20071031204518.8F60218585ED@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Nobody (None)
Summary: spec --heckle runs heckle even when there are initially failing specs fails

Initial Comment:
rev 2804


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

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

From noreply at rubyforge.org  Wed Oct 31 17:46:45 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 31 Oct 2007 17:46:45 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Feature Requests-15247 ] Heckle task
Message-ID: <20071031214645.5F76818585C9@rubyforge.org>

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

Category: Rake
Group: None
Status: Open
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Aslak Helles?y (aslak_hellesoy)
Summary: Heckle task

Initial Comment:
Any chance of a heckle option in Spec::Rake::SpecTask, similar to the way you can use rcov?

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

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

From noreply at rubyforge.org  Wed Oct 31 17:48:58 2007
From: noreply at rubyforge.org (noreply at rubyforge.org)
Date: Wed, 31 Oct 2007 17:48:58 -0400 (EDT)
Subject: [rspec-devel] [ rspec-Bugs-15248 ] Typo in spec --help
Message-ID: <20071031214858.B8EED18585C9@rubyforge.org>

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

Category: runner module
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Ashley Moran (ashleymoran)
Assigned to: Nobody (None)
Summary: Typo in spec --help

Initial Comment:
-l, --line LINE_NUMBER           Execute behaviout

Aren't you glad there are pedants like me around :)

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

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