From pergesu at gmail.com  Fri Sep 12 10:44:40 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Fri, 12 Sep 2008 10:44:40 -0400
Subject: [rspec-devel] If you set an expectation on something that's already
	stubbed, should it return the stubbed value?
Message-ID: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>

Hey guys,

Here's a pretty simple spec

describe AccountService do
  before(:each) do
    @account = stub("account", :balance => 12345)
    @service = AccoutnService.new
  end

  it "should check the balance" do
    @account.should_receive(:balance)
    @service.get_balance(@account)
  end
end

Ignore the fact that it's totally lame :)

Right now, in the example, @account.balance will return nil.  Any
other specs that call it will get back 12345.  What do you guys think
about making it return the same value by default, instead of nil?  So
basically, instead of totally shadowing that method, we simply tighten
up the constraints on the mock object by adding an expectation.

Pros:
- Less verbose - it expresses intent better, I think.  You don't
really care what it returns in that case.  Just that it gets that
method called, and everything works
- No duplication.  I can't think of a single instance where I stubbed
a call, and then in my expectation I wanted it to return nil.  I
*always* duplicate it

Cons:
- Less verbose :)  maybe some people would think it's not explicit enough?

Personally, I'm all for it.  What do you guys think?

Pat

From dchelimsky at gmail.com  Fri Sep 12 10:48:56 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 12 Sep 2008 09:48:56 -0500
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
Message-ID: <57c63afe0809120748x21e3a5c4xfc924ef607ea3cb5@mail.gmail.com>

On Fri, Sep 12, 2008 at 9:44 AM, Pat Maddox <pergesu at gmail.com> wrote:
> Hey guys,
>
> Here's a pretty simple spec
>
> describe AccountService do
>  before(:each) do
>    @account = stub("account", :balance => 12345)
>    @service = AccoutnService.new
>  end
>
>  it "should check the balance" do
>    @account.should_receive(:balance)
>    @service.get_balance(@account)
>  end
> end
>
> Ignore the fact that it's totally lame :)
>
> Right now, in the example, @account.balance will return nil.  Any
> other specs that call it will get back 12345.  What do you guys think
> about making it return the same value by default, instead of nil?  So
> basically, instead of totally shadowing that method, we simply tighten
> up the constraints on the mock object by adding an expectation.
>
> Pros:
> - Less verbose - it expresses intent better, I think.  You don't
> really care what it returns in that case.  Just that it gets that
> method called, and everything works
> - No duplication.  I can't think of a single instance where I stubbed
> a call, and then in my expectation I wanted it to return nil.  I
> *always* duplicate it
>
> Cons:
> - Less verbose :)  maybe some people would think it's not explicit enough?
>
> Personally, I'm all for it.  What do you guys think?

My instinct is +1, but I want to think about it a bit. My only concern
would be "what is the risk of breaking existing examples?"

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

From blake at near-time.com  Fri Sep 12 11:12:28 2008
From: blake at near-time.com (Blake Watters)
Date: Fri, 12 Sep 2008 11:12:28 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
Message-ID: <b90035d60809120812l18187b66ob5b08e1a77291327@mail.gmail.com>

+1

If I approached RSpec without any existing knowledge, my assumption would be
that the stubbed method would return the value. Anything we can do to
preserve that sort of learning via discovery is a win.

On Fri, Sep 12, 2008 at 10:44 AM, Pat Maddox <pergesu at gmail.com> wrote:

> Hey guys,
>
> Here's a pretty simple spec
>
> describe AccountService do
>  before(:each) do
>    @account = stub("account", :balance => 12345)
>    @service = AccoutnService.new
>  end
>
>  it "should check the balance" do
>    @account.should_receive(:balance)
>    @service.get_balance(@account)
>  end
> end
>
> Ignore the fact that it's totally lame :)
>
> Right now, in the example, @account.balance will return nil.  Any
> other specs that call it will get back 12345.  What do you guys think
> about making it return the same value by default, instead of nil?  So
> basically, instead of totally shadowing that method, we simply tighten
> up the constraints on the mock object by adding an expectation.
>
> Pros:
> - Less verbose - it expresses intent better, I think.  You don't
> really care what it returns in that case.  Just that it gets that
> method called, and everything works
> - No duplication.  I can't think of a single instance where I stubbed
> a call, and then in my expectation I wanted it to return nil.  I
> *always* duplicate it
>
> Cons:
> - Less verbose :)  maybe some people would think it's not explicit enough?
>
> Personally, I'm all for it.  What do you guys think?
>
> Pat
> _______________________________________________
> 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/20080912/e2c5a5ee/attachment.html>

From bryansray at gmail.com  Fri Sep 12 11:19:32 2008
From: bryansray at gmail.com (Bryan Ray)
Date: Fri, 12 Sep 2008 10:19:32 -0500
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <b90035d60809120812l18187b66ob5b08e1a77291327@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<b90035d60809120812l18187b66ob5b08e1a77291327@mail.gmail.com>
Message-ID: <54B768C8-6752-4052-9547-7080B7CED4D3@gmail.com>

I think it sounds useful, but I do agree that is is not as explicit as  
I personally like.

I think it might lead to more scrolling up and down to figure out what  
is being setup in the before :each blocks to be able to understand the  
spec blocks ... which I am not a fan of.

+1/-1 (neutral) :)

On Sep 12, 2008, at 10:12 AM, Blake Watters wrote:

> +1
>
> If I approached RSpec without any existing knowledge, my assumption  
> would be that the stubbed method would return the value. Anything we  
> can do to preserve that sort of learning via discovery is a win.
>
> On Fri, Sep 12, 2008 at 10:44 AM, Pat Maddox <pergesu at gmail.com>  
> wrote:
> Hey guys,
>
> Here's a pretty simple spec
>
> describe AccountService do
>  before(:each) do
>    @account = stub("account", :balance => 12345)
>    @service = AccoutnService.new
>  end
>
>  it "should check the balance" do
>    @account.should_receive(:balance)
>    @service.get_balance(@account)
>  end
> end
>
> Ignore the fact that it's totally lame :)
>
> Right now, in the example, @account.balance will return nil.  Any
> other specs that call it will get back 12345.  What do you guys think
> about making it return the same value by default, instead of nil?  So
> basically, instead of totally shadowing that method, we simply tighten
> up the constraints on the mock object by adding an expectation.
>
> Pros:
> - Less verbose - it expresses intent better, I think.  You don't
> really care what it returns in that case.  Just that it gets that
> method called, and everything works
> - No duplication.  I can't think of a single instance where I stubbed
> a call, and then in my expectation I wanted it to return nil.  I
> *always* duplicate it
>
> Cons:
> - Less verbose :)  maybe some people would think it's not explicit  
> enough?
>
> Personally, I'm all for it.  What do you guys think?
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080912/02e5f02f/attachment-0001.html>

From zach.dennis at gmail.com  Fri Sep 12 12:22:44 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Fri, 12 Sep 2008 12:22:44 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
Message-ID: <85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>

On Fri, Sep 12, 2008 at 10:44 AM, Pat Maddox <pergesu at gmail.com> wrote:
> Hey guys,
>
> Here's a pretty simple spec
>
> describe AccountService do
>  before(:each) do
>    @account = stub("account", :balance => 12345)
>    @service = AccoutnService.new
>  end
>
>  it "should check the balance" do
>    @account.should_receive(:balance)
>    @service.get_balance(@account)
>  end
> end
>
> Ignore the fact that it's totally lame :)
>
> Right now, in the example, @account.balance will return nil.  Any
> other specs that call it will get back 12345.  What do you guys think
> about making it return the same value by default, instead of nil?  So
> basically, instead of totally shadowing that method, we simply tighten
> up the constraints on the mock object by adding an expectation.
>
> Pros:
> - Less verbose - it expresses intent better, I think.  You don't
> really care what it returns in that case.  Just that it gets that
> method called, and everything works
> - No duplication.  I can't think of a single instance where I stubbed
> a call, and then in my expectation I wanted it to return nil.  I
> *always* duplicate it
>
> Cons:
> - Less verbose :)  maybe some people would think it's not explicit enough?
>
> Personally, I'm all for it.  What do you guys think?

-1. This works against clearly expressing the intent in each example.
I vote for keeping the explicit values used by an example (if that is
what is being tested) inside each example. Clarity over saving a few
keystrokes on this one,


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

From pergesu at gmail.com  Sat Sep 13 13:44:08 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Sat, 13 Sep 2008 13:44:08 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	(Zach Dennis's message of "Fri, 12 Sep 2008 12:22:44 -0400")
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
Message-ID: <m2k5dgc55j.fsf@gmail.com>

"Zach Dennis" <zach.dennis at gmail.com> writes:

> On Fri, Sep 12, 2008 at 10:44 AM, Pat Maddox <pergesu at gmail.com> wrote:
>> Hey guys,
>>
>> Here's a pretty simple spec
>>
>> describe AccountService do
>>  before(:each) do
>>    @account = stub("account", :balance => 12345)
>>    @service = AccoutnService.new
>>  end
>>
>>  it "should check the balance" do
>>    @account.should_receive(:balance)
>>    @service.get_balance(@account)
>>  end
>> end
>>
>> Ignore the fact that it's totally lame :)
>>
>> Right now, in the example, @account.balance will return nil.  Any
>> other specs that call it will get back 12345.  What do you guys think
>> about making it return the same value by default, instead of nil?  So
>> basically, instead of totally shadowing that method, we simply tighten
>> up the constraints on the mock object by adding an expectation.
>>
>> Pros:
>> - Less verbose - it expresses intent better, I think.  You don't
>> really care what it returns in that case.  Just that it gets that
>> method called, and everything works
>> - No duplication.  I can't think of a single instance where I stubbed
>> a call, and then in my expectation I wanted it to return nil.  I
>> *always* duplicate it
>>
>> Cons:
>> - Less verbose :)  maybe some people would think it's not explicit enough?
>>
>> Personally, I'm all for it.  What do you guys think?
>
> -1. This works against clearly expressing the intent in each example.
> I vote for keeping the explicit values used by an example (if that is
> what is being tested) inside each example. Clarity over saving a few
> keystrokes on this one,

I actually think it expresses the intent *more* clearly.  Consider this
example from a controller spec:

it "should find the book" do
  Book.should_receive(:find).with("1")
  get :show, :id => "1"
end

"and_return" simply adds noise to the example.  The giveaway is that the
description doesn't say "should find and return the book."  We could
change that obviously...but *why* do we want to specify what book gets
returned?  So that we can display it on the page, of course!  So let's
write an example for that:

it "should assign the book to the view" do
  get :show, :id => "1"
  assigns[:book].should == @mock_book
end

Now we've got one example that says we should find the proper book, and
another one that says we should assign it to the view.  And with these
two, we can be confident everything is set up properly because there'd
be no way for @mock_book to make it to the view were it not the same
object returned by Book.find.

This is less an issue of duplication than one of Least Surprise, in my
opinion.  If you look at .should_receive...and_return in the example I
gave, you might naturally think "well of COURSE it returns the mock book
- I already stubbed it!"  Book is set up to do the right thing, we're
just tightening the constraints on it for a single example in order to
verify the desired behavior.  Also related to Least Surprise is what
happens right now if you forget to specify a return value: you get back
nil and tests fail.  When you've run into this problem several times
before it's no big deal...but for someone new to the framework it's a
head-scratcher.  And good luck if you accidentally return the wrong
object (think @mock_book2 vs @mock_book1) - you won't get somewhat
obvious errors about nils, instead you'll just git different behavior
altogether.

Finally, consider how much *better* your intent is expressed when you DO
add and_return to return a different value - you know in that particular
example that you're expecting the behavior to be different as a result
of the indirect input.

Here's my modified pros and cons list:

Pros
* Less noise in should_receive examples
* Example is less coupled to setup - changing the value returned by the
  stub doesn't make you change the value for the mock
* Principle of least surprise - no weird errors from forgetting to
  return the correct value from the mock
* Setting and_return clearly points to when you're overriding the
  default behavior

Cons
* Might break some existing examples

Honestly I think that the con is not likely to be much of a problem.  I
bet 99% of examples that use the stub-in-setup/expect-in-example pattern
use the same value both times.  And even if it does break your test, I'd
say you were asking for it anyway:

before(:each) do
  @mock_book = mock_model("book")
  Book.stub!(:find).and_return @mock_book
end

it "should render a 404 when the book is not found" do
  Book.should_receive(:find).with("1")
  get :show, :id => "1"
  response.code.should == "404"
end

Why on earth were you relying on the reader's knowledge of subtleties of
the mocking framework?  Express your intent!

Book.should_receive(:find).with("1").and_return nil

Ahhhhh... that's better.

Pat

From pergesu at gmail.com  Sat Sep 13 13:56:37 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Sat, 13 Sep 2008 13:56:37 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <m2k5dgc55j.fsf@gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
Message-ID: <810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>

I'm pretty set on this (though I'll hold off on making changes
until I feel all opinions are given thorough discussion).  But there's
one case where it's not 100% clear to me what to do were we to make
these changes.

Here's an example I wrote in my previous email:
it "should render a 404 when the book is not found" do
  Book.should_receive(:find).with("1").and_return nil
  get :show, :id => "1"
  response.code.should == "404"
end

Now, I actually wouldn't write that example.  I'd write it as:
it "should render a 404 when the book is not found" do
  Book.stub!(:find).and_return nil
  get :show, :id => "1"
  response.code.should == "404"
end

There's no reason to set an expectation there, the best way to express
the intent of that example is to stub it and return nil, indicating
that we expect different behavior when it's nil.  Anyway, I used
should_receive in the previous email in case anyone picked up on this
and discussed that instead instead of the intent of the email.

So this begs the question, in my mind, what happens when you do:
it "should render a 404 when the book is not found" do
  Book.stub!(:find)
  get :show, :id => "1"
  response.code.should == "404"
end

My inclination is that it would work the same as the expectation - it
would just return the same value as was originally stubbed.  The
difference is that doing this stub would effectively be a noop.  Now I
CAN see the point that you're re-stubbing this method and it would
maybe clear out any existing stubs...but again I think it's a bad idea
to rely on the reader's knowledge that stub!, by default, returns nil.
Then again, it is a tad weird that stub! would set it up to return nil
in one context, but some different value in another context.

Over all, I think consistency with the expectation API, as well as
encouraging developers to express intent better in their examples,
wins out.

Pat

From cdemyanovich at gmail.com  Sat Sep 13 16:52:53 2008
From: cdemyanovich at gmail.com (Craig Demyanovich)
Date: Sat, 13 Sep 2008 16:52:53 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
Message-ID: <61c885db0809131352t3d41c671u46e0021e26493fd9@mail.gmail.com>

Pat,

In an earlier message, you wrote:

it "should find the book" do
 Book.should_receive(:find).with("1")
 get :show, :id => "1"
end

[snip]

it "should assign the book to the view" do
 get :show, :id => "1"
 assigns[:book].should == @mock_book
end

Now we've got one example that says we should find the proper book, and
another one that says we should assign it to the view.  And with these
two, we can be confident everything is set up properly because there'd
be no way for @mock_book to make it to the view were it not the same
object returned by Book.find.

Where does @mock_book come from? A before block?

Thanks,
Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080913/f2af31e6/attachment.html>

From pergesu at gmail.com  Sat Sep 13 17:23:07 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Sat, 13 Sep 2008 17:23:07 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <61c885db0809131352t3d41c671u46e0021e26493fd9@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<61c885db0809131352t3d41c671u46e0021e26493fd9@mail.gmail.com>
Message-ID: <810a540e0809131423s5aa10aaayd947ae949c2396e3@mail.gmail.com>

On Sat, Sep 13, 2008 at 4:52 PM, Craig Demyanovich
<cdemyanovich at gmail.com> wrote:
> Pat,
>
> In an earlier message, you wrote:
>
> it "should find the book" do
>  Book.should_receive(:find).with("1")
>  get :show, :id => "1"
> end
>
> [snip]
>
> it "should assign the book to the view" do
>  get :show, :id => "1"
>  assigns[:book].should == @mock_book
> end
>
> Now we've got one example that says we should find the proper book, and
> another one that says we should assign it to the view.  And with these
> two, we can be confident everything is set up properly because there'd
> be no way for @mock_book to make it to the view were it not the same
> object returned by Book.find.
>
> Where does @mock_book come from? A before block?

Yes.  I was just showing a snippet of an example since I was lazy and
didn't want to write a whole spec.

Pat

From pergesu at gmail.com  Sat Sep 13 17:42:02 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Sat, 13 Sep 2008 17:42:02 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809131423s5aa10aaayd947ae949c2396e3@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<61c885db0809131352t3d41c671u46e0021e26493fd9@mail.gmail.com>
	<810a540e0809131423s5aa10aaayd947ae949c2396e3@mail.gmail.com>
Message-ID: <810a540e0809131442k4d9a4b2x71bd4cbc6c9c6e45@mail.gmail.com>

Okay folks, I've implemented this and pushed it to
http://github.com/pat-maddox/rspec/tree/no-stub-shadowing

The interesting commit is at
http://github.com/pat-maddox/rspec/commit/72facc08b9a5df6da84c50f4f04cebc77bdfa613

RSpec suite is green.  I've also run this against
* giternal
* cucumber
* merb
* three rails apps

and all are green.  So my suspicion that it shouldn't break anything
seems to be right in my case, as well as a couple other projects.  I'd
be interested to know how it affects other people.

Pat

From zach.dennis at gmail.com  Sun Sep 14 22:34:54 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Sun, 14 Sep 2008 22:34:54 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
Message-ID: <85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>

On Sat, Sep 13, 2008 at 1:56 PM, Pat Maddox <pergesu at gmail.com> wrote:
> I'm pretty set on this (though I'll hold off on making changes
> until I feel all opinions are given thorough discussion).  But there's
> one case where it's not 100% clear to me what to do were we to make
> these changes.
>
> Here's an example I wrote in my previous email:
> it "should render a 404 when the book is not found" do
>  Book.should_receive(:find).with("1").and_return nil
>  get :show, :id => "1"
>  response.code.should == "404"
> end
>
> Now, I actually wouldn't write that example.  I'd write it as:
> it "should render a 404 when the book is not found" do
>  Book.stub!(:find).and_return nil
>  get :show, :id => "1"
>  response.code.should == "404"
> end
>
> There's no reason to set an expectation there, the best way to express
> the intent of that example is to stub it and return nil, indicating
> that we expect different behavior when it's nil.  Anyway, I used
> should_receive in the previous email in case anyone picked up on this
> and discussed that instead instead of the intent of the email.
>
> So this begs the question, in my mind, what happens when you do:
> it "should render a 404 when the book is not found" do
>  Book.stub!(:find)
>  get :show, :id => "1"
>  response.code.should == "404"
> end
>
> My inclination is that it would work the same as the expectation - it
> would just return the same value as was originally stubbed.  The
> difference is that doing this stub would effectively be a noop.  Now I
> CAN see the point that you're re-stubbing this method and it would
> maybe clear out any existing stubs...but again I think it's a bad idea
> to rely on the reader's knowledge that stub!, by default, returns nil.
> Then again, it is a tad weird that stub! would set it up to return nil
> in one context, but some different value in another context.
>
> Over all, I think consistency with the expectation API, as well as
> encouraging developers to express intent better in their examples,
> wins out.
>

I'm pretty sure I misread your first email thinking that you wanted to
replace the usage of and_return with reliance on the stubbed out
values from the befores, which I gave a -1 to since I felt that would
provide confusion and lack of clarity. But I don't think that is at
all what you were suggesting.

To communicate back to you what I think you're suggesting... you'd
like to remove unnecessary usages of and_return when it isn't used to
exemplify the intent of an example. And your argument for principle of
least surprise I do agree with. Not that it matters, but +1.

Thanks for taking the time to share what you're thinking more than once. ;)


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

From tmhaines at gmail.com  Sun Sep 14 23:25:29 2008
From: tmhaines at gmail.com (Tim Haines)
Date: Mon, 15 Sep 2008 15:25:29 +1200
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
Message-ID: <df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>

Took me a couple of reads to understand this aswell - but I'm very much in
favour of it.

On Mon, Sep 15, 2008 at 2:34 PM, Zach Dennis <zach.dennis at gmail.com> wrote:

> On Sat, Sep 13, 2008 at 1:56 PM, Pat Maddox <pergesu at gmail.com> wrote:
> > I'm pretty set on this (though I'll hold off on making changes
> > until I feel all opinions are given thorough discussion).  But there's
> > one case where it's not 100% clear to me what to do were we to make
> > these changes.
> >
> > Here's an example I wrote in my previous email:
> > it "should render a 404 when the book is not found" do
> >  Book.should_receive(:find).with("1").and_return nil
> >  get :show, :id => "1"
> >  response.code.should == "404"
> > end
> >
> > Now, I actually wouldn't write that example.  I'd write it as:
> > it "should render a 404 when the book is not found" do
> >  Book.stub!(:find).and_return nil
> >  get :show, :id => "1"
> >  response.code.should == "404"
> > end
> >
> > There's no reason to set an expectation there, the best way to express
> > the intent of that example is to stub it and return nil, indicating
> > that we expect different behavior when it's nil.  Anyway, I used
> > should_receive in the previous email in case anyone picked up on this
> > and discussed that instead instead of the intent of the email.
> >
> > So this begs the question, in my mind, what happens when you do:
> > it "should render a 404 when the book is not found" do
> >  Book.stub!(:find)
> >  get :show, :id => "1"
> >  response.code.should == "404"
> > end
> >
> > My inclination is that it would work the same as the expectation - it
> > would just return the same value as was originally stubbed.  The
> > difference is that doing this stub would effectively be a noop.  Now I
> > CAN see the point that you're re-stubbing this method and it would
> > maybe clear out any existing stubs...but again I think it's a bad idea
> > to rely on the reader's knowledge that stub!, by default, returns nil.
> > Then again, it is a tad weird that stub! would set it up to return nil
> > in one context, but some different value in another context.
> >
> > Over all, I think consistency with the expectation API, as well as
> > encouraging developers to express intent better in their examples,
> > wins out.
> >
>
> I'm pretty sure I misread your first email thinking that you wanted to
> replace the usage of and_return with reliance on the stubbed out
> values from the befores, which I gave a -1 to since I felt that would
> provide confusion and lack of clarity. But I don't think that is at
> all what you were suggesting.
>
> To communicate back to you what I think you're suggesting... you'd
> like to remove unnecessary usages of and_return when it isn't used to
> exemplify the intent of an example. And your argument for principle of
> least surprise I do agree with. Not that it matters, but +1.
>
> Thanks for taking the time to share what you're thinking more than once. ;)
>
>
> --
> Zach Dennis
> http://www.continuousthinking.com
> http://www.mutuallyhuman.com
> _______________________________________________
> 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/20080915/cc718fd3/attachment.html>

From pergesu at gmail.com  Sun Sep 14 23:33:32 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Sun, 14 Sep 2008 23:33:32 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
	<df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>
Message-ID: <810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>

Sorry about that...I really am trying to become a better writer. I'll
keep working at it.

Anyway, cool, it sounds like I can merge it in to trunk soon.

Pat



On 9/14/08, Tim Haines <tmhaines at gmail.com> wrote:
> Took me a couple of reads to understand this aswell - but I'm very much in
> favour of it.
>
> On Mon, Sep 15, 2008 at 2:34 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>
>> On Sat, Sep 13, 2008 at 1:56 PM, Pat Maddox <pergesu at gmail.com> wrote:
>> > I'm pretty set on this (though I'll hold off on making changes
>> > until I feel all opinions are given thorough discussion).  But there's
>> > one case where it's not 100% clear to me what to do were we to make
>> > these changes.
>> >
>> > Here's an example I wrote in my previous email:
>> > it "should render a 404 when the book is not found" do
>> >  Book.should_receive(:find).with("1").and_return nil
>> >  get :show, :id => "1"
>> >  response.code.should == "404"
>> > end
>> >
>> > Now, I actually wouldn't write that example.  I'd write it as:
>> > it "should render a 404 when the book is not found" do
>> >  Book.stub!(:find).and_return nil
>> >  get :show, :id => "1"
>> >  response.code.should == "404"
>> > end
>> >
>> > There's no reason to set an expectation there, the best way to express
>> > the intent of that example is to stub it and return nil, indicating
>> > that we expect different behavior when it's nil.  Anyway, I used
>> > should_receive in the previous email in case anyone picked up on this
>> > and discussed that instead instead of the intent of the email.
>> >
>> > So this begs the question, in my mind, what happens when you do:
>> > it "should render a 404 when the book is not found" do
>> >  Book.stub!(:find)
>> >  get :show, :id => "1"
>> >  response.code.should == "404"
>> > end
>> >
>> > My inclination is that it would work the same as the expectation - it
>> > would just return the same value as was originally stubbed.  The
>> > difference is that doing this stub would effectively be a noop.  Now I
>> > CAN see the point that you're re-stubbing this method and it would
>> > maybe clear out any existing stubs...but again I think it's a bad idea
>> > to rely on the reader's knowledge that stub!, by default, returns nil.
>> > Then again, it is a tad weird that stub! would set it up to return nil
>> > in one context, but some different value in another context.
>> >
>> > Over all, I think consistency with the expectation API, as well as
>> > encouraging developers to express intent better in their examples,
>> > wins out.
>> >
>>
>> I'm pretty sure I misread your first email thinking that you wanted to
>> replace the usage of and_return with reliance on the stubbed out
>> values from the befores, which I gave a -1 to since I felt that would
>> provide confusion and lack of clarity. But I don't think that is at
>> all what you were suggesting.
>>
>> To communicate back to you what I think you're suggesting... you'd
>> like to remove unnecessary usages of and_return when it isn't used to
>> exemplify the intent of an example. And your argument for principle of
>> least surprise I do agree with. Not that it matters, but +1.
>>
>> Thanks for taking the time to share what you're thinking more than once.
>> ;)
>>
>>
>> --
>> Zach Dennis
>> http://www.continuousthinking.com
>> http://www.mutuallyhuman.com
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>

From mlangenberg at gmail.com  Mon Sep 15 05:11:42 2008
From: mlangenberg at gmail.com (Matthijs Langenberg)
Date: Mon, 15 Sep 2008 11:11:42 +0200
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
	<df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>
	<810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>
Message-ID: <27c0ac6d0809150211j30e27297m46cf0aa86227452@mail.gmail.com>

+1 It's really confusing when you get an error on 'nil.destroy' after
doing Page.should_receive(:find); Page.find().destroy

On Mon, Sep 15, 2008 at 5:33 AM, Pat Maddox <pergesu at gmail.com> wrote:
> Sorry about that...I really am trying to become a better writer. I'll
> keep working at it.
>
> Anyway, cool, it sounds like I can merge it in to trunk soon.
>
> Pat
>
>
>
> On 9/14/08, Tim Haines <tmhaines at gmail.com> wrote:
>> Took me a couple of reads to understand this aswell - but I'm very much in
>> favour of it.
>>
>> On Mon, Sep 15, 2008 at 2:34 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>>
>>> On Sat, Sep 13, 2008 at 1:56 PM, Pat Maddox <pergesu at gmail.com> wrote:
>>> > I'm pretty set on this (though I'll hold off on making changes
>>> > until I feel all opinions are given thorough discussion).  But there's
>>> > one case where it's not 100% clear to me what to do were we to make
>>> > these changes.
>>> >
>>> > Here's an example I wrote in my previous email:
>>> > it "should render a 404 when the book is not found" do
>>> >  Book.should_receive(:find).with("1").and_return nil
>>> >  get :show, :id => "1"
>>> >  response.code.should == "404"
>>> > end
>>> >
>>> > Now, I actually wouldn't write that example.  I'd write it as:
>>> > it "should render a 404 when the book is not found" do
>>> >  Book.stub!(:find).and_return nil
>>> >  get :show, :id => "1"
>>> >  response.code.should == "404"
>>> > end
>>> >
>>> > There's no reason to set an expectation there, the best way to express
>>> > the intent of that example is to stub it and return nil, indicating
>>> > that we expect different behavior when it's nil.  Anyway, I used
>>> > should_receive in the previous email in case anyone picked up on this
>>> > and discussed that instead instead of the intent of the email.
>>> >
>>> > So this begs the question, in my mind, what happens when you do:
>>> > it "should render a 404 when the book is not found" do
>>> >  Book.stub!(:find)
>>> >  get :show, :id => "1"
>>> >  response.code.should == "404"
>>> > end
>>> >
>>> > My inclination is that it would work the same as the expectation - it
>>> > would just return the same value as was originally stubbed.  The
>>> > difference is that doing this stub would effectively be a noop.  Now I
>>> > CAN see the point that you're re-stubbing this method and it would
>>> > maybe clear out any existing stubs...but again I think it's a bad idea
>>> > to rely on the reader's knowledge that stub!, by default, returns nil.
>>> > Then again, it is a tad weird that stub! would set it up to return nil
>>> > in one context, but some different value in another context.
>>> >
>>> > Over all, I think consistency with the expectation API, as well as
>>> > encouraging developers to express intent better in their examples,
>>> > wins out.
>>> >
>>>
>>> I'm pretty sure I misread your first email thinking that you wanted to
>>> replace the usage of and_return with reliance on the stubbed out
>>> values from the befores, which I gave a -1 to since I felt that would
>>> provide confusion and lack of clarity. But I don't think that is at
>>> all what you were suggesting.
>>>
>>> To communicate back to you what I think you're suggesting... you'd
>>> like to remove unnecessary usages of and_return when it isn't used to
>>> exemplify the intent of an example. And your argument for principle of
>>> least surprise I do agree with. Not that it matters, but +1.
>>>
>>> Thanks for taking the time to share what you're thinking more than once.
>>> ;)
>>>
>>>
>>> --
>>> Zach Dennis
>>> http://www.continuousthinking.com
>>> http://www.mutuallyhuman.com
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Mon Sep 15 09:35:36 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 15 Sep 2008 08:35:36 -0500
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
	<df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>
	<810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>
Message-ID: <57c63afe0809150635m3f2c6182vfb2621946216f238@mail.gmail.com>

On Sun, Sep 14, 2008 at 10:33 PM, Pat Maddox <pergesu at gmail.com> wrote:
> Sorry about that...I really am trying to become a better writer. I'll
> keep working at it.
>
> Anyway, cool, it sounds like I can merge it in to trunk soon.

Hey Pat - looks like message expectations that inherit (for lack of a
better term) the return value from a previously defined stub ignore
the block, expected_from, and any subsequent arguments passed to the
message expectation. Can you add examples for those and make sure they
pass before committing this. I added one for blocks (which fails) to
get you started - patch attached.

Cheers,
David

>
> Pat
>
>
>
> On 9/14/08, Tim Haines <tmhaines at gmail.com> wrote:
>> Took me a couple of reads to understand this aswell - but I'm very much in
>> favour of it.
>>
>> On Mon, Sep 15, 2008 at 2:34 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>>
>>> On Sat, Sep 13, 2008 at 1:56 PM, Pat Maddox <pergesu at gmail.com> wrote:
>>> > I'm pretty set on this (though I'll hold off on making changes
>>> > until I feel all opinions are given thorough discussion).  But there's
>>> > one case where it's not 100% clear to me what to do were we to make
>>> > these changes.
>>> >
>>> > Here's an example I wrote in my previous email:
>>> > it "should render a 404 when the book is not found" do
>>> >  Book.should_receive(:find).with("1").and_return nil
>>> >  get :show, :id => "1"
>>> >  response.code.should == "404"
>>> > end
>>> >
>>> > Now, I actually wouldn't write that example.  I'd write it as:
>>> > it "should render a 404 when the book is not found" do
>>> >  Book.stub!(:find).and_return nil
>>> >  get :show, :id => "1"
>>> >  response.code.should == "404"
>>> > end
>>> >
>>> > There's no reason to set an expectation there, the best way to express
>>> > the intent of that example is to stub it and return nil, indicating
>>> > that we expect different behavior when it's nil.  Anyway, I used
>>> > should_receive in the previous email in case anyone picked up on this
>>> > and discussed that instead instead of the intent of the email.
>>> >
>>> > So this begs the question, in my mind, what happens when you do:
>>> > it "should render a 404 when the book is not found" do
>>> >  Book.stub!(:find)
>>> >  get :show, :id => "1"
>>> >  response.code.should == "404"
>>> > end
>>> >
>>> > My inclination is that it would work the same as the expectation - it
>>> > would just return the same value as was originally stubbed.  The
>>> > difference is that doing this stub would effectively be a noop.  Now I
>>> > CAN see the point that you're re-stubbing this method and it would
>>> > maybe clear out any existing stubs...but again I think it's a bad idea
>>> > to rely on the reader's knowledge that stub!, by default, returns nil.
>>> > Then again, it is a tad weird that stub! would set it up to return nil
>>> > in one context, but some different value in another context.
>>> >
>>> > Over all, I think consistency with the expectation API, as well as
>>> > encouraging developers to express intent better in their examples,
>>> > wins out.
>>> >
>>>
>>> I'm pretty sure I misread your first email thinking that you wanted to
>>> replace the usage of and_return with reliance on the stubbed out
>>> values from the befores, which I gave a -1 to since I felt that would
>>> provide confusion and lack of clarity. But I don't think that is at
>>> all what you were suggesting.
>>>
>>> To communicate back to you what I think you're suggesting... you'd
>>> like to remove unnecessary usages of and_return when it isn't used to
>>> exemplify the intent of an example. And your argument for principle of
>>> least surprise I do agree with. Not that it matters, but +1.
>>>
>>> Thanks for taking the time to share what you're thinking more than once.
>>> ;)
>>>
>>>
>>> --
>>> Zach Dennis
>>> http://www.continuousthinking.com
>>> http://www.mutuallyhuman.com
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-added-failing-example-of-a-post-stub-mock-receiving.patch
Type: application/octet-stream
Size: 955 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080915/e8838b06/attachment-0001.obj>

From mailing_lists at railsnewbie.com  Tue Sep 16 21:15:05 2008
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Tue, 16 Sep 2008 21:15:05 -0400
Subject: [rspec-devel] Cucumber - mailing list?
Message-ID: <03F2D5F4-5684-46D7-A0E2-C5C4044E2260@railsnewbie.com>


Aslak (or David, Pat, or one of the other project admins) -

Could we create a new mailing list for cucumber?

Scott



From dchelimsky at gmail.com  Tue Sep 16 21:16:27 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 16 Sep 2008 20:16:27 -0500
Subject: [rspec-devel] Cucumber - mailing list?
In-Reply-To: <03F2D5F4-5684-46D7-A0E2-C5C4044E2260@railsnewbie.com>
References: <03F2D5F4-5684-46D7-A0E2-C5C4044E2260@railsnewbie.com>
Message-ID: <57c63afe0809161816n27da05d6r6e4666557bf94a1c@mail.gmail.com>

On Tue, Sep 16, 2008 at 8:15 PM, Scott Taylor
<mailing_lists at railsnewbie.com> wrote:
>
> Aslak (or David, Pat, or one of the other project admins) -
>
> Could we create a new mailing list for cucumber?

Why would you want a separate mailing list? We've already got one too many :)

From mailing_lists at railsnewbie.com  Tue Sep 16 21:20:03 2008
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Tue, 16 Sep 2008 21:20:03 -0400
Subject: [rspec-devel] Cucumber - mailing list?
In-Reply-To: <57c63afe0809161816n27da05d6r6e4666557bf94a1c@mail.gmail.com>
References: <03F2D5F4-5684-46D7-A0E2-C5C4044E2260@railsnewbie.com>
	<57c63afe0809161816n27da05d6r6e4666557bf94a1c@mail.gmail.com>
Message-ID: <3FE073B2-CA1C-4E0B-AB55-9B3966E29A2B@railsnewbie.com>


On Sep 16, 2008, at 9:16 PM, David Chelimsky wrote:

> On Tue, Sep 16, 2008 at 8:15 PM, Scott Taylor
> <mailing_lists at railsnewbie.com> wrote:
>>
>> Aslak (or David, Pat, or one of the other project admins) -
>>
>> Could we create a new mailing list for cucumber?
>
> Why would you want a separate mailing list? We've already got one  
> too many :)

Well, honestly I was never a big fan of the Story Runner, and found it  
quite annoying to be getting lots of mail on a subject I cared nothing  
about, and didn't sign up for.

Now I am interested in Cucumber so it's not that big of a deal,  
although it seems sort of strange that everyone is titling their  
subjects "Cucumber: ..." instead of just posting to a cucumber mailing  
list.

Scott


From pergesu at gmail.com  Tue Sep 16 21:23:11 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Tue, 16 Sep 2008 21:23:11 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <57c63afe0809150635m3f2c6182vfb2621946216f238@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
	<df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>
	<810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>
	<57c63afe0809150635m3f2c6182vfb2621946216f238@mail.gmail.com>
Message-ID: <810a540e0809161823k4e35f586ue56e5642c3bb2876@mail.gmail.com>

> Hey Pat - looks like message expectations that inherit (for lack of a
> better term) the return value from a previously defined stub ignore
> the block, expected_from, and any subsequent arguments passed to the
> message expectation. Can you add examples for those and make sure they
> pass before committing this. I added one for blocks (which fails) to
> get you started - patch attached.

Took care of the blocks and expected_from... I'm not sure what you
mean by "any subsequent arguments passed to the message expectation
though" ?  My best guess is that you're talking about the options
hash...

To tell you the truth, I've never used it before :)  I figured the
best way to test this was to look at the options_hash_spec (since that
seems like the only place where it's really used?).  But what I found
is that those examples seem to be broken...I changed the spec around
to make it clearly fail, but it still passed.  I've attached a patch
that shows it (apply it with "git apply").  Do you have any idea
what's going on?

Pat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: false_positive.patch
Type: application/octet-stream
Size: 642 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080916/fec1bd89/attachment.obj>

From pergesu at gmail.com  Tue Sep 16 21:32:38 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Tue, 16 Sep 2008 21:32:38 -0400
Subject: [rspec-devel] Cucumber - mailing list?
In-Reply-To: <57c63afe0809161816n27da05d6r6e4666557bf94a1c@mail.gmail.com>
References: <03F2D5F4-5684-46D7-A0E2-C5C4044E2260@railsnewbie.com>
	<57c63afe0809161816n27da05d6r6e4666557bf94a1c@mail.gmail.com>
Message-ID: <810a540e0809161832p4fdbcf43pad55f6daddc00017@mail.gmail.com>

On Tue, Sep 16, 2008 at 9:16 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Tue, Sep 16, 2008 at 8:15 PM, Scott Taylor
> <mailing_lists at railsnewbie.com> wrote:
>>
>> Aslak (or David, Pat, or one of the other project admins) -
>>
>> Could we create a new mailing list for cucumber?
>
> Why would you want a separate mailing list? We've already got one too many :)

Yeah, I actually like having cucumber stuff on here.  Acceptance
testing is a critical part of BDD, and even if cucumber never gets
merged into rspec (though I hope it does), it's nice having a one-stop
shop for Ruby BDDers.

Pat

From pergesu at gmail.com  Tue Sep 16 21:35:49 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Tue, 16 Sep 2008 21:35:49 -0400
Subject: [rspec-devel] Cucumber - mailing list?
In-Reply-To: <3FE073B2-CA1C-4E0B-AB55-9B3966E29A2B@railsnewbie.com>
References: <03F2D5F4-5684-46D7-A0E2-C5C4044E2260@railsnewbie.com>
	<57c63afe0809161816n27da05d6r6e4666557bf94a1c@mail.gmail.com>
	<3FE073B2-CA1C-4E0B-AB55-9B3966E29A2B@railsnewbie.com>
Message-ID: <810a540e0809161835x2ae3f3fcn2c6ee185bd23ab39@mail.gmail.com>

On Tue, Sep 16, 2008 at 9:20 PM, Scott Taylor
<mailing_lists at railsnewbie.com> wrote:
>
> On Sep 16, 2008, at 9:16 PM, David Chelimsky wrote:
>
>> On Tue, Sep 16, 2008 at 8:15 PM, Scott Taylor
>> <mailing_lists at railsnewbie.com> wrote:
>>>
>>> Aslak (or David, Pat, or one of the other project admins) -
>>>
>>> Could we create a new mailing list for cucumber?
>>
>> Why would you want a separate mailing list? We've already got one too many
>> :)
>
> Well, honestly I was never a big fan of the Story Runner, and found it quite
> annoying to be getting lots of mail on a subject I cared nothing about, and
> didn't sign up for.

Set up a filter to automatically move them to the trash?


> Now I am interested in Cucumber so it's not that big of a deal, although it
> seems sort of strange that everyone is titling their subjects "Cucumber:
> ..." instead of just posting to a cucumber mailing list.

Well, people always say 'story runner' in their titles also.  It's a
consequence of RSpec being several frameworks in one (developer
testing, customer testing, mock objects).  But that's one of RSpec's
main selling points for me.  It's a fully integrated BDD stack, and
modular enough that you can pick and choose the parts you want.

Pat

From ben at benmabey.com  Tue Sep 16 22:04:01 2008
From: ben at benmabey.com (Ben Mabey)
Date: Tue, 16 Sep 2008 20:04:01 -0600
Subject: [rspec-devel] Cucumber - mailing list?
In-Reply-To: <810a540e0809161832p4fdbcf43pad55f6daddc00017@mail.gmail.com>
References: <03F2D5F4-5684-46D7-A0E2-C5C4044E2260@railsnewbie.com>	<57c63afe0809161816n27da05d6r6e4666557bf94a1c@mail.gmail.com>
	<810a540e0809161832p4fdbcf43pad55f6daddc00017@mail.gmail.com>
Message-ID: <48D06591.9020606@benmabey.com>

Pat Maddox wrote:
> On Tue, Sep 16, 2008 at 9:16 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
>   
>> On Tue, Sep 16, 2008 at 8:15 PM, Scott Taylor
>> <mailing_lists at railsnewbie.com> wrote:
>>     
>>> Aslak (or David, Pat, or one of the other project admins) -
>>>
>>> Could we create a new mailing list for cucumber?
>>>       
>> Why would you want a separate mailing list? We've already got one too many :)
>>     
>
> Yeah, I actually like having cucumber stuff on here.  Acceptance
> testing is a critical part of BDD, and even if cucumber never gets
> merged into rspec (though I hope it does), it's nice having a one-stop
> shop for Ruby BDDers.
>
> Pat
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>   
+1 for keeping the lists the same.  I think the rspec-users list is a
great resource for ruby people learning BDD in general and a lot of
non-specific rspec questions are answered all the time.  By splitting
the list I think we would be diminishing the number of contributors to
those types of questions.. and in the end, like Pat said, it is all part
of the bigger BDD picture.  When cucumber emails are answered the
example framework is usually brought up and vice-versa.. so it just
seems natural to keep them on the same list.

Ben

From dchelimsky at gmail.com  Tue Sep 16 22:14:29 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 16 Sep 2008 21:14:29 -0500
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809161823k4e35f586ue56e5642c3bb2876@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
	<df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>
	<810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>
	<57c63afe0809150635m3f2c6182vfb2621946216f238@mail.gmail.com>
	<810a540e0809161823k4e35f586ue56e5642c3bb2876@mail.gmail.com>
Message-ID: <57c63afe0809161914l56eec5cake47554c4cf4e315b@mail.gmail.com>

On Tue, Sep 16, 2008 at 8:23 PM, Pat Maddox <pergesu at gmail.com> wrote:
>> Hey Pat - looks like message expectations that inherit (for lack of a
>> better term) the return value from a previously defined stub ignore
>> the block, expected_from, and any subsequent arguments passed to the
>> message expectation. Can you add examples for those and make sure they
>> pass before committing this. I added one for blocks (which fails) to
>> get you started - patch attached.
>
> Took care of the blocks and expected_from... I'm not sure what you
> mean by "any subsequent arguments passed to the message expectation
> though" ?  My best guess is that you're talking about the options
> hash...
>
> To tell you the truth, I've never used it before :)  I figured the
> best way to test this was to look at the options_hash_spec (since that
> seems like the only place where it's really used?).  But what I found
> is that those examples seem to be broken...I changed the spec around
> to make it clearly fail, but it still passed.  I've attached a patch
> that shows it (apply it with "git apply").  Do you have any idea
> what's going on?

Yeah - those code examples sucked. They are now greatly improved (and
unable to reproduce the false positives you saw):

http://github.com/dchelimsky/rspec/commit/5043400

Cheers,
David

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

From blake at near-time.com  Wed Sep 17 10:42:32 2008
From: blake at near-time.com (Blake Watters)
Date: Wed, 17 Sep 2008 10:42:32 -0400
Subject: [rspec-devel] Cucumber - mailing list?
In-Reply-To: <48D06591.9020606@benmabey.com>
References: <03F2D5F4-5684-46D7-A0E2-C5C4044E2260@railsnewbie.com>
	<57c63afe0809161816n27da05d6r6e4666557bf94a1c@mail.gmail.com>
	<810a540e0809161832p4fdbcf43pad55f6daddc00017@mail.gmail.com>
	<48D06591.9020606@benmabey.com>
Message-ID: <b90035d60809170742y1b12b17aw7e4021901bd5748b@mail.gmail.com>

Another +1 for staying on list. I am interested in the holistic Ruby BDD
picture, don't want to atomize and manage filters/subscriptions for
different fragments of RSpec

On Tue, Sep 16, 2008 at 10:04 PM, Ben Mabey <ben at benmabey.com> wrote:

> Pat Maddox wrote:
> > On Tue, Sep 16, 2008 at 9:16 PM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
> >
> >> On Tue, Sep 16, 2008 at 8:15 PM, Scott Taylor
> >> <mailing_lists at railsnewbie.com> wrote:
> >>
> >>> Aslak (or David, Pat, or one of the other project admins) -
> >>>
> >>> Could we create a new mailing list for cucumber?
> >>>
> >> Why would you want a separate mailing list? We've already got one too
> many :)
> >>
> >
> > Yeah, I actually like having cucumber stuff on here.  Acceptance
> > testing is a critical part of BDD, and even if cucumber never gets
> > merged into rspec (though I hope it does), it's nice having a one-stop
> > shop for Ruby BDDers.
> >
> > Pat
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> +1 for keeping the lists the same.  I think the rspec-users list is a
> great resource for ruby people learning BDD in general and a lot of
> non-specific rspec questions are answered all the time.  By splitting
> the list I think we would be diminishing the number of contributors to
> those types of questions.. and in the end, like Pat said, it is all part
> of the bigger BDD picture.  When cucumber emails are answered the
> example framework is usually brought up and vice-versa.. so it just
> seems natural to keep them on the same list.
>
> Ben
> _______________________________________________
> 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/20080917/e1117eca/attachment-0001.html>

From pergesu at gmail.com  Wed Sep 17 11:49:56 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Wed, 17 Sep 2008 11:49:56 -0400
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <57c63afe0809161914l56eec5cake47554c4cf4e315b@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<85d99afe0809120922l4c95d24ep9bcc7ed355fdeff7@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
	<df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>
	<810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>
	<57c63afe0809150635m3f2c6182vfb2621946216f238@mail.gmail.com>
	<810a540e0809161823k4e35f586ue56e5642c3bb2876@mail.gmail.com>
	<57c63afe0809161914l56eec5cake47554c4cf4e315b@mail.gmail.com>
Message-ID: <810a540e0809170849h2a435b0atfebc501f090d767a@mail.gmail.com>

On Tue, Sep 16, 2008 at 10:14 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Tue, Sep 16, 2008 at 8:23 PM, Pat Maddox <pergesu at gmail.com> wrote:
>>> Hey Pat - looks like message expectations that inherit (for lack of a
>>> better term) the return value from a previously defined stub ignore
>>> the block, expected_from, and any subsequent arguments passed to the
>>> message expectation. Can you add examples for those and make sure they
>>> pass before committing this. I added one for blocks (which fails) to
>>> get you started - patch attached.
>>
>> Took care of the blocks and expected_from... I'm not sure what you
>> mean by "any subsequent arguments passed to the message expectation
>> though" ?  My best guess is that you're talking about the options
>> hash...
>>
>> To tell you the truth, I've never used it before :)  I figured the
>> best way to test this was to look at the options_hash_spec (since that
>> seems like the only place where it's really used?).  But what I found
>> is that those examples seem to be broken...I changed the spec around
>> to make it clearly fail, but it still passed.  I've attached a patch
>> that shows it (apply it with "git apply").  Do you have any idea
>> what's going on?
>
> Yeah - those code examples sucked. They are now greatly improved (and
> unable to reproduce the false positives you saw):
>
> http://github.com/dchelimsky/rspec/commit/5043400

Okay, so I think http://github.com/pat-maddox/rspec/commit/fab5ddf62
ought to finish it all off.  How's it look to you?

Pat

From dchelimsky at gmail.com  Wed Sep 17 11:58:20 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 17 Sep 2008 10:58:20 -0500
Subject: [rspec-devel] If you set an expectation on something that's
	already stubbed, should it return the stubbed value?
In-Reply-To: <810a540e0809170849h2a435b0atfebc501f090d767a@mail.gmail.com>
References: <810a540e0809120744iadbcbd5o13295cdec10e369f@mail.gmail.com>
	<m2k5dgc55j.fsf@gmail.com>
	<810a540e0809131056q262549f0x2f7c9bf3e7b80b70@mail.gmail.com>
	<85d99afe0809141934o4ce5553ahcc01b8020442d1c4@mail.gmail.com>
	<df2118760809142025v90c32fev2885b1e444f2b0b9@mail.gmail.com>
	<810a540e0809142033h1844423cv2a208c2f531d6a24@mail.gmail.com>
	<57c63afe0809150635m3f2c6182vfb2621946216f238@mail.gmail.com>
	<810a540e0809161823k4e35f586ue56e5642c3bb2876@mail.gmail.com>
	<57c63afe0809161914l56eec5cake47554c4cf4e315b@mail.gmail.com>
	<810a540e0809170849h2a435b0atfebc501f090d767a@mail.gmail.com>
Message-ID: <57c63afe0809170858i490ac594kc7fa072e3a90cf94@mail.gmail.com>

On Wed, Sep 17, 2008 at 10:49 AM, Pat Maddox <pergesu at gmail.com> wrote:
> On Tue, Sep 16, 2008 at 10:14 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On Tue, Sep 16, 2008 at 8:23 PM, Pat Maddox <pergesu at gmail.com> wrote:
>>>> Hey Pat - looks like message expectations that inherit (for lack of a
>>>> better term) the return value from a previously defined stub ignore
>>>> the block, expected_from, and any subsequent arguments passed to the
>>>> message expectation. Can you add examples for those and make sure they
>>>> pass before committing this. I added one for blocks (which fails) to
>>>> get you started - patch attached.
>>>
>>> Took care of the blocks and expected_from... I'm not sure what you
>>> mean by "any subsequent arguments passed to the message expectation
>>> though" ?  My best guess is that you're talking about the options
>>> hash...
>>>
>>> To tell you the truth, I've never used it before :)  I figured the
>>> best way to test this was to look at the options_hash_spec (since that
>>> seems like the only place where it's really used?).  But what I found
>>> is that those examples seem to be broken...I changed the spec around
>>> to make it clearly fail, but it still passed.  I've attached a patch
>>> that shows it (apply it with "git apply").  Do you have any idea
>>> what's going on?
>>
>> Yeah - those code examples sucked. They are now greatly improved (and
>> unable to reproduce the false positives you saw):
>>
>> http://github.com/dchelimsky/rspec/commit/5043400
>
> Okay, so I think http://github.com/pat-maddox/rspec/commit/fab5ddf62
> ought to finish it all off.  How's it look to you?

Great. Ship it!

Thanks for playing,
David

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

From dchelimsky at gmail.com  Mon Sep 22 09:52:27 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 22 Sep 2008 08:52:27 -0500
Subject: [rspec-devel] plans for cucumber
Message-ID: <57c63afe0809220652p583efd03l9feccb3c1ffaab47@mail.gmail.com>

Hey all,

Let's make this official. We're planning to replace the RSpec Story
Runner with Cucumber. The rspec-1.1.5 release will still include the
Story Runner (several fixes since the last release). So if you're not
already using stories and you want to start, start with cucumber
(http://github.com/aslakhellesoy/cucumber).

For those of you already using stories, we're going to take steps to
make this as simple as possible.

1. We're going to do one more release with things as they are
currently structured (with Story Runner as part of the gem/plugin).
2. Aslak has posted the current migration path at
http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories
and we'll work to make it simpler if we can.
3. Story Runner will be released as a separate gem/plugin that you are
free to use, however we're not putting any additional development
effort into it once cucumber is released. It will be up on github and
anyone who wishes to use/maintain it is free to do so.

Feel free to respond with questions/concerns (praise is welcome too!).
We're really excited about Cucumber and all the benefits it brings
(see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
to make the transition as easy as we can for the pioneers among you
who are already using stories.

Cheers,
David

From dchelimsky at gmail.com  Mon Sep 22 10:10:07 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 22 Sep 2008 09:10:07 -0500
Subject: [rspec-devel] directory structure/naming
Message-ID: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>

Hey all - we seem to have landed on "features", "scenarios" and "code
examples" as the proper names for talking about ... well ... features,
scenarios and code examples. If you don't know what I mean by those
things, then maybe we still have a problem, but I'm guessing most of
you do.

So I'm thinking of a new directory structure:

app-root
> behaviour
> > code-examples
> > features

I've always wanted to group these things together, but
behaviour/examples never worked for me as behaviour/code-examples
does.

WDYT?

From ben at benmabey.com  Mon Sep 22 12:20:51 2008
From: ben at benmabey.com (Ben Mabey)
Date: Mon, 22 Sep 2008 10:20:51 -0600
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
Message-ID: <48D7C5E3.3030007@benmabey.com>

David Chelimsky wrote:
> Hey all - we seem to have landed on "features", "scenarios" and "code
> examples" as the proper names for talking about ... well ... features,
> scenarios and code examples. If you don't know what I mean by those
> things, then maybe we still have a problem, but I'm guessing most of
> you do.
>
> So I'm thinking of a new directory structure:
>
> app-root
>   
>> behaviour
>>     
>>> code-examples
>>> features
>>>       
>
> I've always wanted to group these things together, but
> behaviour/examples never worked for me as behaviour/code-examples
> does.
>
> WDYT?
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>   

 I really like the idea of grouping the two in a 'behaviour' directory. 
I tend to have helpers that I use in both my examples and my features so
placing them both in the same directory makes sense from an organization
point of view.  (Plus, I really like having the name be 'behaviour'--
even if it is spelled wrong. :p) 

I agree that the term code-examples is far less ambiguous than just
plain 'examples'.  The fact that we refer to them as examples and even
rspec internally treats them as examples does beg the question on how we
got stuck with specs in the first place.  While I like the idea of
code-examples I think that will be a much harder transition because so
many people are used to the name 'spec' at this point (including
myself.)  What is the main argument for ditching spec in favor of
code-example?  Less baggage?

-Ben

From dchelimsky at gmail.com  Mon Sep 22 12:31:14 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 22 Sep 2008 11:31:14 -0500
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <48D7C5E3.3030007@benmabey.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
	<48D7C5E3.3030007@benmabey.com>
Message-ID: <57c63afe0809220931i6301574ep9fa6e23bb59fc792@mail.gmail.com>

On Mon, Sep 22, 2008 at 11:20 AM, Ben Mabey <ben at benmabey.com> wrote:
> David Chelimsky wrote:
>> Hey all - we seem to have landed on "features", "scenarios" and "code
>> examples" as the proper names for talking about ... well ... features,
>> scenarios and code examples. If you don't know what I mean by those
>> things, then maybe we still have a problem, but I'm guessing most of
>> you do.
>>
>> So I'm thinking of a new directory structure:
>>
>> app-root
>>
>>> behaviour
>>>
>>>> code-examples
>>>> features
>>>>
>>
>> I've always wanted to group these things together, but
>> behaviour/examples never worked for me as behaviour/code-examples
>> does.
>>
>> WDYT?
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
>  I really like the idea of grouping the two in a 'behaviour' directory.
> I tend to have helpers that I use in both my examples and my features so
> placing them both in the same directory makes sense from an organization
> point of view.  (Plus, I really like having the name be 'behaviour'--
> even if it is spelled wrong. :p)
>
> I agree that the term code-examples is far less ambiguous than just
> plain 'examples'.  The fact that we refer to them as examples and even
> rspec internally treats them as examples does beg the question on how we
> got stuck with specs in the first place.

Steve Baker noted that Uncle Bob was saying "specify, don't verify"
and took that to heart when he named it. We all just rolled with it
and now it's a sorta well known brand. Changing the name would suck.

That said, I think we can keep the name of the library while changing
the underlying conventions. Though I'm sure Dan would like it to
become rbehave :)

> While I like the idea of
> code-examples I think that will be a much harder transition because so
> many people are used to the name 'spec' at this point (including
> myself.)  What is the main argument for ditching spec in favor of
> code-example?  Less baggage?

Baggage, yes. Spec means "specification" as in "4 months of meetings
before writing any code" to a lot of people. It also means "system" to
a lot of people. Then again, the scenarios are examples too :)

Suggestions welcome, but spec doesn't really tell the right story. Of
course, we'll continue to support existing structures.

David

>
> -Ben

From linojon at gmail.com  Mon Sep 22 12:30:46 2008
From: linojon at gmail.com (linojon)
Date: Mon, 22 Sep 2008 12:30:46 -0400
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <48D7C5E3.3030007@benmabey.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
	<48D7C5E3.3030007@benmabey.com>
Message-ID: <732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>


On Sep 22, 2008, at 12:20 PM, Ben Mabey wrote:

> David Chelimsky wrote:
>> Hey all - we seem to have landed on "features", "scenarios" and "code
>> examples" as the proper names for talking about ... well ...  
>> features,
>> scenarios and code examples. If you don't know what I mean by those
>> things, then maybe we still have a problem, but I'm guessing most of
>> you do.
>>
>> So I'm thinking of a new directory structure:
>>
>> app-root
>>
>>> behaviour
>>>
>>>> code-examples
>>>> features
>>>>
>>
>> I've always wanted to group these things together, but
>> behaviour/examples never worked for me as behaviour/code-examples
>> does.
>>
>> WDYT?
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
>  I really like the idea of grouping the two in a 'behaviour'  
> directory.
> I tend to have helpers that I use in both my examples and my  
> features so
> placing them both in the same directory makes sense from an  
> organization
> point of view.  (Plus, I really like having the name be 'behaviour'--
> even if it is spelled wrong. :p)
>
> I agree that the term code-examples is far less ambiguous than just
> plain 'examples'.  The fact that we refer to them as examples and even
> rspec internally treats them as examples does beg the question on  
> how we
> got stuck with specs in the first place.  While I like the idea of
> code-examples I think that will be a much harder transition because so
> many people are used to the name 'spec' at this point (including
> myself.)  What is the main argument for ditching spec in favor of
> code-example?  Less baggage?
>
> -Ben

features is to scenarios
as
specs is to examples

therefore the directories:

behaviour
	features
	specs

besides, i like less typing
:)

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


From luislavena at gmail.com  Mon Sep 22 20:04:31 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 22 Sep 2008 21:04:31 -0300
Subject: [rspec-devel] Fwd: Changes in edge rspec render colored output
	useless on Windows
In-Reply-To: <71166b3b0809161815w3daa0416vd0cf661fcdaedca@mail.gmail.com>
References: <71166b3b0809161815w3daa0416vd0cf661fcdaedca@mail.gmail.com>
Message-ID: <71166b3b0809221704r3ac1f26dp7ac72cfe7fb4f132@mail.gmail.com>

Hey Guys, for some reason this message never got into the list. I'm
forwarding it again just in case.

---------- Forwarded message ----------
Date: Tue, Sep 16, 2008 at 10:15 PM
Subject: Changes in edge rspec render colored output useless on Windows

Hello Guys,

Doing a series of updates in some project just to find out that
colored output under Windows is no longer working.

win32console, which is the gem that allows ANSI emulation under
Windows need to grab references and replace STDOUT and STDERR.

After playing with git bisect, I found the offending commit:

Only use color codes on tty; override for autospec
http://github.com/dchelimsky/rspec/commit/4692fc0140f2c5ff3d25be5991db5336caefe15b

Previous this commit, the output was correct, after it, not.

The originating ticket with the discussion:
http://rspec.lighthouseapp.com/projects/5645/tickets/413-disable-color-codes-on-stdout-when-stdout-tty-is-false

It seems this change also introduced hacks for making AUTOTEST to work:
http://rspec.lighthouseapp.com/projects/5645/tickets/422

And we can now add it break windows fancy colored output.

Suggestions?
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From dchelimsky at gmail.com  Mon Sep 22 20:07:25 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 22 Sep 2008 19:07:25 -0500
Subject: [rspec-devel] Fwd: Changes in edge rspec render colored output
	useless on Windows
In-Reply-To: <71166b3b0809221704r3ac1f26dp7ac72cfe7fb4f132@mail.gmail.com>
References: <71166b3b0809161815w3daa0416vd0cf661fcdaedca@mail.gmail.com>
	<71166b3b0809221704r3ac1f26dp7ac72cfe7fb4f132@mail.gmail.com>
Message-ID: <57c63afe0809221707h36496edax3e555d4221b31847@mail.gmail.com>

I've re-opened the ticket - can you please add your comments there?

http://rspec.lighthouseapp.com/projects/5645/tickets/413

On Mon, Sep 22, 2008 at 7:04 PM, Luis Lavena <luislavena at gmail.com> wrote:
> Hey Guys, for some reason this message never got into the list. I'm
> forwarding it again just in case.
>
> ---------- Forwarded message ----------
> Date: Tue, Sep 16, 2008 at 10:15 PM
> Subject: Changes in edge rspec render colored output useless on Windows
>
> Hello Guys,
>
> Doing a series of updates in some project just to find out that
> colored output under Windows is no longer working.
>
> win32console, which is the gem that allows ANSI emulation under
> Windows need to grab references and replace STDOUT and STDERR.
>
> After playing with git bisect, I found the offending commit:
>
> Only use color codes on tty; override for autospec
> http://github.com/dchelimsky/rspec/commit/4692fc0140f2c5ff3d25be5991db5336caefe15b
>
> Previous this commit, the output was correct, after it, not.
>
> The originating ticket with the discussion:
> http://rspec.lighthouseapp.com/projects/5645/tickets/413-disable-color-codes-on-stdout-when-stdout-tty-is-false
>
> It seems this change also introduced hacks for making AUTOTEST to work:
> http://rspec.lighthouseapp.com/projects/5645/tickets/422
>
> And we can now add it break windows fancy colored output.
>
> Suggestions?
> --
> Luis Lavena
> AREA 17
> -
> Human beings, who are almost unique in having the ability to learn from
> the experience of others, are also remarkable for their apparent
> disinclination to do so.
> Douglas Adams
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From luislavena at gmail.com  Mon Sep 22 20:11:10 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 22 Sep 2008 21:11:10 -0300
Subject: [rspec-devel] Fwd: Changes in edge rspec render colored output
	useless on Windows
In-Reply-To: <57c63afe0809221707h36496edax3e555d4221b31847@mail.gmail.com>
References: <71166b3b0809161815w3daa0416vd0cf661fcdaedca@mail.gmail.com>
	<71166b3b0809221704r3ac1f26dp7ac72cfe7fb4f132@mail.gmail.com>
	<57c63afe0809221707h36496edax3e555d4221b31847@mail.gmail.com>
Message-ID: <71166b3b0809221711y31a8920fr27d1008338dffe09@mail.gmail.com>

On Mon, Sep 22, 2008 at 9:07 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> I've re-opened the ticket - can you please add your comments there?
>
> http://rspec.lighthouseapp.com/projects/5645/tickets/413
>

Thank you David, I just added my comments there :-)

Regards,
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From dchelimsky at gmail.com  Mon Sep 22 21:30:16 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 22 Sep 2008 20:30:16 -0500
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
	<48D7C5E3.3030007@benmabey.com>
	<732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>
Message-ID: <57c63afe0809221830k366ecc49w4c3003d0f211a9fc@mail.gmail.com>

On Mon, Sep 22, 2008 at 11:30 AM, linojon <linojon at gmail.com> wrote:
>
> On Sep 22, 2008, at 12:20 PM, Ben Mabey wrote:
>
>> David Chelimsky wrote:
>>>
>>> Hey all - we seem to have landed on "features", "scenarios" and "code
>>> examples" as the proper names for talking about ... well ... features,
>>> scenarios and code examples. If you don't know what I mean by those
>>> things, then maybe we still have a problem, but I'm guessing most of
>>> you do.
>>>
>>> So I'm thinking of a new directory structure:
>>>
>>> app-root
>>>
>>>> behaviour
>>>>
>>>>> code-examples
>>>>> features
>>>>>
>>>
>>> I've always wanted to group these things together, but
>>> behaviour/examples never worked for me as behaviour/code-examples
>>> does.
>>>
>>> WDYT?
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>>
>>  I really like the idea of grouping the two in a 'behaviour' directory.
>> I tend to have helpers that I use in both my examples and my features so
>> placing them both in the same directory makes sense from an organization
>> point of view.  (Plus, I really like having the name be 'behaviour'--
>> even if it is spelled wrong. :p)
>>
>> I agree that the term code-examples is far less ambiguous than just
>> plain 'examples'.  The fact that we refer to them as examples and even
>> rspec internally treats them as examples does beg the question on how we
>> got stuck with specs in the first place.  While I like the idea of
>> code-examples I think that will be a much harder transition because so
>> many people are used to the name 'spec' at this point (including
>> myself.)  What is the main argument for ditching spec in favor of
>> code-example?  Less baggage?
>>
>> -Ben
>
> features is to scenarios
> as
> specs is to examples

or example_groups is to examples ;)

> therefore the directories:
>
> behaviour
>        features
>        specs
>
> besides, i like less typing


How about this:

behaviour
  code
  features

That's one less char for you :)

> :)

From zach.dennis at gmail.com  Mon Sep 22 21:36:29 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Mon, 22 Sep 2008 21:36:29 -0400
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
	<48D7C5E3.3030007@benmabey.com>
	<732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>
Message-ID: <85d99afe0809221836xef600e6s74d85996782520e@mail.gmail.com>

On Mon, Sep 22, 2008 at 12:30 PM, linojon <linojon at gmail.com> wrote:
>
> On Sep 22, 2008, at 12:20 PM, Ben Mabey wrote:
>
>> David Chelimsky wrote:
>>>
>>> Hey all - we seem to have landed on "features", "scenarios" and "code
>>> examples" as the proper names for talking about ... well ... features,
>>> scenarios and code examples. If you don't know what I mean by those
>>> things, then maybe we still have a problem, but I'm guessing most of
>>> you do.
>>>
>>> So I'm thinking of a new directory structure:
>>>
>>> app-root
>>>
>>>> behaviour
>>>>
>>>>> code-examples
>>>>> features
>>>>>
>>>
>>> I've always wanted to group these things together, but
>>> behaviour/examples never worked for me as behaviour/code-examples
>>> does.
>>>
>>> WDYT?
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>
>>
>>  I really like the idea of grouping the two in a 'behaviour' directory.
>> I tend to have helpers that I use in both my examples and my features so
>> placing them both in the same directory makes sense from an organization
>> point of view.  (Plus, I really like having the name be 'behaviour'--
>> even if it is spelled wrong. :p)
>>
>> I agree that the term code-examples is far less ambiguous than just
>> plain 'examples'.  The fact that we refer to them as examples and even
>> rspec internally treats them as examples does beg the question on how we
>> got stuck with specs in the first place.  While I like the idea of
>> code-examples I think that will be a much harder transition because so
>> many people are used to the name 'spec' at this point (including
>> myself.)  What is the main argument for ditching spec in favor of
>> code-example?  Less baggage?
>>
>> -Ben
>
> features is to scenarios
> as
> specs is to examples
>
> therefore the directories:
>
> behaviour
>        features
>        specs
>
> besides, i like less typing
> :)

Have we learned nothing from prioritizing the number of characters
over a meaningful name? :)

Any good shell will tab auto-complete anyways, and in an actual IDE
you almost never have actually type in the name of the directory
unless you're creating it.

I like:

behaviour
   examples
   features

I think "code" communicates poorly. I like "code-examples", but I
think if we drop "code" the same intent is expressed. I know that like
"specs" whatever becomes convention will be cemented in everyone's
heads very shortly. But while we're trying to get the words right,
let's try to get the words right.

-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

From dchelimsky at gmail.com  Mon Sep 22 21:47:22 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 22 Sep 2008 20:47:22 -0500
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <85d99afe0809221836xef600e6s74d85996782520e@mail.gmail.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
	<48D7C5E3.3030007@benmabey.com>
	<732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>
	<85d99afe0809221836xef600e6s74d85996782520e@mail.gmail.com>
Message-ID: <57c63afe0809221847y1ce31275hfb4e349688c168e5@mail.gmail.com>

On Mon, Sep 22, 2008 at 8:36 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
> On Mon, Sep 22, 2008 at 12:30 PM, linojon <linojon at gmail.com> wrote:
>>
>> On Sep 22, 2008, at 12:20 PM, Ben Mabey wrote:
>>
>>> David Chelimsky wrote:
>>>>
>>>> Hey all - we seem to have landed on "features", "scenarios" and "code
>>>> examples" as the proper names for talking about ... well ... features,
>>>> scenarios and code examples. If you don't know what I mean by those
>>>> things, then maybe we still have a problem, but I'm guessing most of
>>>> you do.
>>>>
>>>> So I'm thinking of a new directory structure:
>>>>
>>>> app-root
>>>>
>>>>> behaviour
>>>>>
>>>>>> code-examples
>>>>>> features
>>>>>>
>>>>
>>>> I've always wanted to group these things together, but
>>>> behaviour/examples never worked for me as behaviour/code-examples
>>>> does.
>>>>
>>>> WDYT?
>>>> _______________________________________________
>>>> rspec-devel mailing list
>>>> rspec-devel at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>
>>>
>>>  I really like the idea of grouping the two in a 'behaviour' directory.
>>> I tend to have helpers that I use in both my examples and my features so
>>> placing them both in the same directory makes sense from an organization
>>> point of view.  (Plus, I really like having the name be 'behaviour'--
>>> even if it is spelled wrong. :p)
>>>
>>> I agree that the term code-examples is far less ambiguous than just
>>> plain 'examples'.  The fact that we refer to them as examples and even
>>> rspec internally treats them as examples does beg the question on how we
>>> got stuck with specs in the first place.  While I like the idea of
>>> code-examples I think that will be a much harder transition because so
>>> many people are used to the name 'spec' at this point (including
>>> myself.)  What is the main argument for ditching spec in favor of
>>> code-example?  Less baggage?
>>>
>>> -Ben
>>
>> features is to scenarios
>> as
>> specs is to examples
>>
>> therefore the directories:
>>
>> behaviour
>>        features
>>        specs
>>
>> besides, i like less typing
>> :)
>
> Have we learned nothing from prioritizing the number of characters
> over a meaningful name? :)
>
> Any good shell will tab auto-complete anyways, and in an actual IDE
> you almost never have actually type in the name of the directory
> unless you're creating it.
>
> I like:
>
> behaviour
>   examples
>   features
>
> I think "code" communicates poorly. I like "code-examples", but I
> think if we drop "code" the same intent is expressed. I know that like
> "specs" whatever becomes convention will be cemented in everyone's
> heads very shortly. But while we're trying to get the words right,
> let's try to get the words right.

Agreed on the goal. I think the problem we have to solve is to come up
with words that reveal the differences between examples of features
and examples of code.

The problem I have with 'examples' by itself is that scenarios are
examples too, just at a higher level.

Also, examples appear in many, many libraries, and in most cases ... I
don't think that word means what you think it means ... at least not
in our context.

The reason I like 'features' and 'code' is that what we've got are
examples of features and code ;)

I'm not sold on the 'code' idea, but so far it speaks better to me
than any other.

More thoughts?

From zach.dennis at gmail.com  Mon Sep 22 21:58:08 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Mon, 22 Sep 2008 21:58:08 -0400
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <57c63afe0809221847y1ce31275hfb4e349688c168e5@mail.gmail.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
	<48D7C5E3.3030007@benmabey.com>
	<732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>
	<85d99afe0809221836xef600e6s74d85996782520e@mail.gmail.com>
	<57c63afe0809221847y1ce31275hfb4e349688c168e5@mail.gmail.com>
Message-ID: <85d99afe0809221858p3f8ba2edtf75a414bbd4c863e@mail.gmail.com>

On Mon, Sep 22, 2008 at 9:47 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Mon, Sep 22, 2008 at 8:36 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>> On Mon, Sep 22, 2008 at 12:30 PM, linojon <linojon at gmail.com> wrote:
>>>
>>> On Sep 22, 2008, at 12:20 PM, Ben Mabey wrote:
>>>
>>>> David Chelimsky wrote:
>>>>>
>>>>> Hey all - we seem to have landed on "features", "scenarios" and "code
>>>>> examples" as the proper names for talking about ... well ... features,
>>>>> scenarios and code examples. If you don't know what I mean by those
>>>>> things, then maybe we still have a problem, but I'm guessing most of
>>>>> you do.
>>>>>
>>>>> So I'm thinking of a new directory structure:
>>>>>
>>>>> app-root
>>>>>
>>>>>> behaviour
>>>>>>
>>>>>>> code-examples
>>>>>>> features
>>>>>>>
>>>>>
>>>>> I've always wanted to group these things together, but
>>>>> behaviour/examples never worked for me as behaviour/code-examples
>>>>> does.
>>>>>
>>>>> WDYT?
>>>>> _______________________________________________
>>>>> rspec-devel mailing list
>>>>> rspec-devel at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>>
>>>>
>>>>  I really like the idea of grouping the two in a 'behaviour' directory.
>>>> I tend to have helpers that I use in both my examples and my features so
>>>> placing them both in the same directory makes sense from an organization
>>>> point of view.  (Plus, I really like having the name be 'behaviour'--
>>>> even if it is spelled wrong. :p)
>>>>
>>>> I agree that the term code-examples is far less ambiguous than just
>>>> plain 'examples'.  The fact that we refer to them as examples and even
>>>> rspec internally treats them as examples does beg the question on how we
>>>> got stuck with specs in the first place.  While I like the idea of
>>>> code-examples I think that will be a much harder transition because so
>>>> many people are used to the name 'spec' at this point (including
>>>> myself.)  What is the main argument for ditching spec in favor of
>>>> code-example?  Less baggage?
>>>>
>>>> -Ben
>>>
>>> features is to scenarios
>>> as
>>> specs is to examples
>>>
>>> therefore the directories:
>>>
>>> behaviour
>>>        features
>>>        specs
>>>
>>> besides, i like less typing
>>> :)
>>
>> Have we learned nothing from prioritizing the number of characters
>> over a meaningful name? :)
>>
>> Any good shell will tab auto-complete anyways, and in an actual IDE
>> you almost never have actually type in the name of the directory
>> unless you're creating it.
>>
>> I like:
>>
>> behaviour
>>   examples
>>   features
>>
>> I think "code" communicates poorly. I like "code-examples", but I
>> think if we drop "code" the same intent is expressed. I know that like
>> "specs" whatever becomes convention will be cemented in everyone's
>> heads very shortly. But while we're trying to get the words right,
>> let's try to get the words right.
>
> Agreed on the goal. I think the problem we have to solve is to come up
> with words that reveal the differences between examples of features
> and examples of code.
>
> The problem I have with 'examples' by itself is that scenarios are
> examples too, just at a higher level.
>
> Also, examples appear in many, many libraries, and in most cases ... I
> don't think that word means what you think it means ... at least not
> in our context.
>
> The reason I like 'features' and 'code' is that what we've got are
> examples of features and code ;)

Touche.

> I'm not sold on the 'code' idea, but so far it speaks better to me
> than any other.
>
> More thoughts?

Right now I can't think of anything better then the features/ and
code/. The hamster still runs however.


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

From ben at benmabey.com  Mon Sep 22 22:00:21 2008
From: ben at benmabey.com (Ben Mabey)
Date: Mon, 22 Sep 2008 20:00:21 -0600
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <57c63afe0809221847y1ce31275hfb4e349688c168e5@mail.gmail.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>	<48D7C5E3.3030007@benmabey.com>	<732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>	<85d99afe0809221836xef600e6s74d85996782520e@mail.gmail.com>
	<57c63afe0809221847y1ce31275hfb4e349688c168e5@mail.gmail.com>
Message-ID: <48D84DB5.6070405@benmabey.com>

David Chelimsky wrote:
> On Mon, Sep 22, 2008 at 8:36 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>   
>> On Mon, Sep 22, 2008 at 12:30 PM, linojon <linojon at gmail.com> wrote:
>>     
>>> On Sep 22, 2008, at 12:20 PM, Ben Mabey wrote:
>>>
>>>       
>>>> David Chelimsky wrote:
>>>>         
>>>>> Hey all - we seem to have landed on "features", "scenarios" and "code
>>>>> examples" as the proper names for talking about ... well ... features,
>>>>> scenarios and code examples. If you don't know what I mean by those
>>>>> things, then maybe we still have a problem, but I'm guessing most of
>>>>> you do.
>>>>>
>>>>> So I'm thinking of a new directory structure:
>>>>>
>>>>> app-root
>>>>>
>>>>>           
>>>>>> behaviour
>>>>>>
>>>>>>             
>>>>>>> code-examples
>>>>>>> features
>>>>>>>
>>>>>>>               
>>>>> I've always wanted to group these things together, but
>>>>> behaviour/examples never worked for me as behaviour/code-examples
>>>>> does.
>>>>>
>>>>> WDYT?
>>>>> _______________________________________________
>>>>> rspec-devel mailing list
>>>>> rspec-devel at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>>
>>>>>           
>>>>  I really like the idea of grouping the two in a 'behaviour' directory.
>>>> I tend to have helpers that I use in both my examples and my features so
>>>> placing them both in the same directory makes sense from an organization
>>>> point of view.  (Plus, I really like having the name be 'behaviour'--
>>>> even if it is spelled wrong. :p)
>>>>
>>>> I agree that the term code-examples is far less ambiguous than just
>>>> plain 'examples'.  The fact that we refer to them as examples and even
>>>> rspec internally treats them as examples does beg the question on how we
>>>> got stuck with specs in the first place.  While I like the idea of
>>>> code-examples I think that will be a much harder transition because so
>>>> many people are used to the name 'spec' at this point (including
>>>> myself.)  What is the main argument for ditching spec in favor of
>>>> code-example?  Less baggage?
>>>>
>>>> -Ben
>>>>         
>>> features is to scenarios
>>> as
>>> specs is to examples
>>>
>>> therefore the directories:
>>>
>>> behaviour
>>>        features
>>>        specs
>>>
>>> besides, i like less typing
>>> :)
>>>       
>> Have we learned nothing from prioritizing the number of characters
>> over a meaningful name? :)
>>
>> Any good shell will tab auto-complete anyways, and in an actual IDE
>> you almost never have actually type in the name of the directory
>> unless you're creating it.
>>
>> I like:
>>
>> behaviour
>>   examples
>>   features
>>
>> I think "code" communicates poorly. I like "code-examples", but I
>> think if we drop "code" the same intent is expressed. I know that like
>> "specs" whatever becomes convention will be cemented in everyone's
>> heads very shortly. But while we're trying to get the words right,
>> let's try to get the words right.
>>     
>
> Agreed on the goal. I think the problem we have to solve is to come up
> with words that reveal the differences between examples of features
> and examples of code.
>
> The problem I have with 'examples' by itself is that scenarios are
> examples too, just at a higher level.
>
> Also, examples appear in many, many libraries, and in most cases ... I
> don't think that word means what you think it means ... at least not
> in our context.
>
> The reason I like 'features' and 'code' is that what we've got are
> examples of features and code ;)
>
> I'm not sold on the 'code' idea, but so far it speaks better to me
> than any other.
>
> More thoughts?
>
>   
How about object-examples?  It seems like the example framework is more
geared toward, and is used more, on the object level so maybe that
naming would reinforce that.  That could be a good or bad thing... Just
thought I would throw that out there.

-Ben

From dchelimsky at gmail.com  Mon Sep 22 22:03:18 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 22 Sep 2008 21:03:18 -0500
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <48D84DB5.6070405@benmabey.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
	<48D7C5E3.3030007@benmabey.com>
	<732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>
	<85d99afe0809221836xef600e6s74d85996782520e@mail.gmail.com>
	<57c63afe0809221847y1ce31275hfb4e349688c168e5@mail.gmail.com>
	<48D84DB5.6070405@benmabey.com>
Message-ID: <57c63afe0809221903q2eaf5b40y2048fc7424fae488@mail.gmail.com>

On Mon, Sep 22, 2008 at 9:00 PM, Ben Mabey <ben at benmabey.com> wrote:
> David Chelimsky wrote:
>> On Mon, Sep 22, 2008 at 8:36 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>>
>>> On Mon, Sep 22, 2008 at 12:30 PM, linojon <linojon at gmail.com> wrote:
>>>
>>>> On Sep 22, 2008, at 12:20 PM, Ben Mabey wrote:
>>>>
>>>>
>>>>> David Chelimsky wrote:
>>>>>
>>>>>> Hey all - we seem to have landed on "features", "scenarios" and "code
>>>>>> examples" as the proper names for talking about ... well ... features,
>>>>>> scenarios and code examples. If you don't know what I mean by those
>>>>>> things, then maybe we still have a problem, but I'm guessing most of
>>>>>> you do.
>>>>>>
>>>>>> So I'm thinking of a new directory structure:
>>>>>>
>>>>>> app-root
>>>>>>
>>>>>>
>>>>>>> behaviour
>>>>>>>
>>>>>>>
>>>>>>>> code-examples
>>>>>>>> features
>>>>>>>>
>>>>>>>>
>>>>>> I've always wanted to group these things together, but
>>>>>> behaviour/examples never worked for me as behaviour/code-examples
>>>>>> does.
>>>>>>
>>>>>> WDYT?
>>>>>> _______________________________________________
>>>>>> rspec-devel mailing list
>>>>>> rspec-devel at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>>>
>>>>>>
>>>>>  I really like the idea of grouping the two in a 'behaviour' directory.
>>>>> I tend to have helpers that I use in both my examples and my features so
>>>>> placing them both in the same directory makes sense from an organization
>>>>> point of view.  (Plus, I really like having the name be 'behaviour'--
>>>>> even if it is spelled wrong. :p)
>>>>>
>>>>> I agree that the term code-examples is far less ambiguous than just
>>>>> plain 'examples'.  The fact that we refer to them as examples and even
>>>>> rspec internally treats them as examples does beg the question on how we
>>>>> got stuck with specs in the first place.  While I like the idea of
>>>>> code-examples I think that will be a much harder transition because so
>>>>> many people are used to the name 'spec' at this point (including
>>>>> myself.)  What is the main argument for ditching spec in favor of
>>>>> code-example?  Less baggage?
>>>>>
>>>>> -Ben
>>>>>
>>>> features is to scenarios
>>>> as
>>>> specs is to examples
>>>>
>>>> therefore the directories:
>>>>
>>>> behaviour
>>>>        features
>>>>        specs
>>>>
>>>> besides, i like less typing
>>>> :)
>>>>
>>> Have we learned nothing from prioritizing the number of characters
>>> over a meaningful name? :)
>>>
>>> Any good shell will tab auto-complete anyways, and in an actual IDE
>>> you almost never have actually type in the name of the directory
>>> unless you're creating it.
>>>
>>> I like:
>>>
>>> behaviour
>>>   examples
>>>   features
>>>
>>> I think "code" communicates poorly. I like "code-examples", but I
>>> think if we drop "code" the same intent is expressed. I know that like
>>> "specs" whatever becomes convention will be cemented in everyone's
>>> heads very shortly. But while we're trying to get the words right,
>>> let's try to get the words right.
>>>
>>
>> Agreed on the goal. I think the problem we have to solve is to come up
>> with words that reveal the differences between examples of features
>> and examples of code.
>>
>> The problem I have with 'examples' by itself is that scenarios are
>> examples too, just at a higher level.
>>
>> Also, examples appear in many, many libraries, and in most cases ... I
>> don't think that word means what you think it means ... at least not
>> in our context.
>>
>> The reason I like 'features' and 'code' is that what we've got are
>> examples of features and code ;)
>>
>> I'm not sold on the 'code' idea, but so far it speaks better to me
>> than any other.
>>
>> More thoughts?
>>
>>
> How about object-examples?  It seems like the example framework is more
> geared toward, and is used more, on the object level so maybe that
> naming would reinforce that.  That could be a good or bad thing... Just
> thought I would throw that out there.

We've certainly slung around the name "object specification framework"
before, so "object example framework" could work ... in theory.

More voices?

>
> -Ben

From mlangenberg at gmail.com  Tue Sep 23 11:32:55 2008
From: mlangenberg at gmail.com (Matthijs Langenberg)
Date: Tue, 23 Sep 2008 17:32:55 +0200
Subject: [rspec-devel] plans for cucumber
In-Reply-To: <57c63afe0809220652p583efd03l9feccb3c1ffaab47@mail.gmail.com>
References: <57c63afe0809220652p583efd03l9feccb3c1ffaab47@mail.gmail.com>
Message-ID: <27c0ac6d0809230832t19fabdb0wc531c6cc7f7dbc95@mail.gmail.com>

David,

I haven't used the story runner on a project yet, but I'm planning to
use Cucumber on a Merb project (if actually possible).
I'm really excited about Cucumber I'll toy around with in the next days.


- Matthijs

On Mon, Sep 22, 2008 at 3:52 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> Hey all,
>
> Let's make this official. We're planning to replace the RSpec Story
> Runner with Cucumber. The rspec-1.1.5 release will still include the
> Story Runner (several fixes since the last release). So if you're not
> already using stories and you want to start, start with cucumber
> (http://github.com/aslakhellesoy/cucumber).
>
> For those of you already using stories, we're going to take steps to
> make this as simple as possible.
>
> 1. We're going to do one more release with things as they are
> currently structured (with Story Runner as part of the gem/plugin).
> 2. Aslak has posted the current migration path at
> http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories
> and we'll work to make it simpler if we can.
> 3. Story Runner will be released as a separate gem/plugin that you are
> free to use, however we're not putting any additional development
> effort into it once cucumber is released. It will be up on github and
> anyone who wishes to use/maintain it is free to do so.
>
> Feel free to respond with questions/concerns (praise is welcome too!).
> We're really excited about Cucumber and all the benefits it brings
> (see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
> to make the transition as easy as we can for the pioneers among you
> who are already using stories.
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Tue Sep 23 11:37:32 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 23 Sep 2008 10:37:32 -0500
Subject: [rspec-devel] plans for cucumber
In-Reply-To: <27c0ac6d0809230832t19fabdb0wc531c6cc7f7dbc95@mail.gmail.com>
References: <57c63afe0809220652p583efd03l9feccb3c1ffaab47@mail.gmail.com>
	<27c0ac6d0809230832t19fabdb0wc531c6cc7f7dbc95@mail.gmail.com>
Message-ID: <57c63afe0809230837p11c1489ew46789d1b84661b66@mail.gmail.com>

On Tue, Sep 23, 2008 at 10:32 AM, Matthijs Langenberg
<mlangenberg at gmail.com> wrote:
> David,
>
> I haven't used the story runner on a project yet, but I'm planning to
> use Cucumber on a Merb project (if actually possible).

Anything's possible, though you'll have to provide some of your own
magic. Cucumber is already wired to deal w/ rolling back AR
transactions between each scenario, but that's only for AR.

> I'm really excited about Cucumber I'll toy around with in the next days.

Let us know how it works.

Thanks,
David

>
>
> - Matthijs
>
> On Mon, Sep 22, 2008 at 3:52 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> Hey all,
>>
>> Let's make this official. We're planning to replace the RSpec Story
>> Runner with Cucumber. The rspec-1.1.5 release will still include the
>> Story Runner (several fixes since the last release). So if you're not
>> already using stories and you want to start, start with cucumber
>> (http://github.com/aslakhellesoy/cucumber).
>>
>> For those of you already using stories, we're going to take steps to
>> make this as simple as possible.
>>
>> 1. We're going to do one more release with things as they are
>> currently structured (with Story Runner as part of the gem/plugin).
>> 2. Aslak has posted the current migration path at
>> http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories
>> and we'll work to make it simpler if we can.
>> 3. Story Runner will be released as a separate gem/plugin that you are
>> free to use, however we're not putting any additional development
>> effort into it once cucumber is released. It will be up on github and
>> anyone who wishes to use/maintain it is free to do so.
>>
>> Feel free to respond with questions/concerns (praise is welcome too!).
>> We're really excited about Cucumber and all the benefits it brings
>> (see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
>> to make the transition as easy as we can for the pioneers among you
>> who are already using stories.
>>
>> 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 wycats at gmail.com  Tue Sep 23 17:14:25 2008
From: wycats at gmail.com (Yehuda Katz)
Date: Tue, 23 Sep 2008 14:14:25 -0700
Subject: [rspec-devel] plans for cucumber
In-Reply-To: <57c63afe0809230837p11c1489ew46789d1b84661b66@mail.gmail.com>
References: <57c63afe0809220652p583efd03l9feccb3c1ffaab47@mail.gmail.com>
	<27c0ac6d0809230832t19fabdb0wc531c6cc7f7dbc95@mail.gmail.com>
	<57c63afe0809230837p11c1489ew46789d1b84661b66@mail.gmail.com>
Message-ID: <245fb4700809231414n28d88a8re7554a383b651883@mail.gmail.com>

I'm also really excited about cucumber/merb combos and might be looking into
adding some support for common stories. I'd love to take a look at anything
you do first so I could potentially integrate it :)
-- Yehuda

On Tue, Sep 23, 2008 at 8:37 AM, David Chelimsky <dchelimsky at gmail.com>wrote:

> On Tue, Sep 23, 2008 at 10:32 AM, Matthijs Langenberg
> <mlangenberg at gmail.com> wrote:
> > David,
> >
> > I haven't used the story runner on a project yet, but I'm planning to
> > use Cucumber on a Merb project (if actually possible).
>
> Anything's possible, though you'll have to provide some of your own
> magic. Cucumber is already wired to deal w/ rolling back AR
> transactions between each scenario, but that's only for AR.
>
> > I'm really excited about Cucumber I'll toy around with in the next days.
>
> Let us know how it works.
>
> Thanks,
> David
>
> >
> >
> > - Matthijs
> >
> > On Mon, Sep 22, 2008 at 3:52 PM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
> >> Hey all,
> >>
> >> Let's make this official. We're planning to replace the RSpec Story
> >> Runner with Cucumber. The rspec-1.1.5 release will still include the
> >> Story Runner (several fixes since the last release). So if you're not
> >> already using stories and you want to start, start with cucumber
> >> (http://github.com/aslakhellesoy/cucumber).
> >>
> >> For those of you already using stories, we're going to take steps to
> >> make this as simple as possible.
> >>
> >> 1. We're going to do one more release with things as they are
> >> currently structured (with Story Runner as part of the gem/plugin).
> >> 2. Aslak has posted the current migration path at
> >>
> http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories
> >> and we'll work to make it simpler if we can.
> >> 3. Story Runner will be released as a separate gem/plugin that you are
> >> free to use, however we're not putting any additional development
> >> effort into it once cucumber is released. It will be up on github and
> >> anyone who wishes to use/maintain it is free to do so.
> >>
> >> Feel free to respond with questions/concerns (praise is welcome too!).
> >> We're really excited about Cucumber and all the benefits it brings
> >> (see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
> >> to make the transition as easy as we can for the pioneers among you
> >> who are already using stories.
> >>
> >> 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
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080923/8d82c5c2/attachment-0001.html>

From aslak.hellesoy at gmail.com  Tue Sep 23 17:54:01 2008
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 23 Sep 2008 23:54:01 +0200
Subject: [rspec-devel] plans for cucumber
In-Reply-To: <245fb4700809231414n28d88a8re7554a383b651883@mail.gmail.com>
References: <57c63afe0809220652p583efd03l9feccb3c1ffaab47@mail.gmail.com>
	<27c0ac6d0809230832t19fabdb0wc531c6cc7f7dbc95@mail.gmail.com>
	<57c63afe0809230837p11c1489ew46789d1b84661b66@mail.gmail.com>
	<245fb4700809231414n28d88a8re7554a383b651883@mail.gmail.com>
Message-ID: <8d961d900809231454n2ed39d1vd233d9cefb9da184@mail.gmail.com>

On Tue, Sep 23, 2008 at 11:14 PM, Yehuda Katz <wycats at gmail.com> wrote:
> I'm also really excited about cucumber/merb combos and might be looking into
> adding some support for common stories. I'd love to take a look at anything
> you do first so I could potentially integrate it :)
> -- Yehuda
>

That's great! I'd add be happy to have some Merb glue in the Cucumber
codebase - similar to what's there for Rails:
http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/rails

Aslak

> On Tue, Sep 23, 2008 at 8:37 AM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
>>
>> On Tue, Sep 23, 2008 at 10:32 AM, Matthijs Langenberg
>> <mlangenberg at gmail.com> wrote:
>> > David,
>> >
>> > I haven't used the story runner on a project yet, but I'm planning to
>> > use Cucumber on a Merb project (if actually possible).
>>
>> Anything's possible, though you'll have to provide some of your own
>> magic. Cucumber is already wired to deal w/ rolling back AR
>> transactions between each scenario, but that's only for AR.
>>
>> > I'm really excited about Cucumber I'll toy around with in the next days.
>>
>> Let us know how it works.
>>
>> Thanks,
>> David
>>
>> >
>> >
>> > - Matthijs
>> >
>> > On Mon, Sep 22, 2008 at 3:52 PM, David Chelimsky <dchelimsky at gmail.com>
>> > wrote:
>> >> Hey all,
>> >>
>> >> Let's make this official. We're planning to replace the RSpec Story
>> >> Runner with Cucumber. The rspec-1.1.5 release will still include the
>> >> Story Runner (several fixes since the last release). So if you're not
>> >> already using stories and you want to start, start with cucumber
>> >> (http://github.com/aslakhellesoy/cucumber).
>> >>
>> >> For those of you already using stories, we're going to take steps to
>> >> make this as simple as possible.
>> >>
>> >> 1. We're going to do one more release with things as they are
>> >> currently structured (with Story Runner as part of the gem/plugin).
>> >> 2. Aslak has posted the current migration path at
>> >>
>> >> http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories
>> >> and we'll work to make it simpler if we can.
>> >> 3. Story Runner will be released as a separate gem/plugin that you are
>> >> free to use, however we're not putting any additional development
>> >> effort into it once cucumber is released. It will be up on github and
>> >> anyone who wishes to use/maintain it is free to do so.
>> >>
>> >> Feel free to respond with questions/concerns (praise is welcome too!).
>> >> We're really excited about Cucumber and all the benefits it brings
>> >> (see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
>> >> to make the transition as easy as we can for the pioneers among you
>> >> who are already using stories.
>> >>
>> >> 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
>
>
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From wycats at gmail.com  Tue Sep 23 19:47:33 2008
From: wycats at gmail.com (Yehuda Katz)
Date: Tue, 23 Sep 2008 16:47:33 -0700
Subject: [rspec-devel] plans for cucumber
In-Reply-To: <8d961d900809231454n2ed39d1vd233d9cefb9da184@mail.gmail.com>
References: <57c63afe0809220652p583efd03l9feccb3c1ffaab47@mail.gmail.com>
	<27c0ac6d0809230832t19fabdb0wc531c6cc7f7dbc95@mail.gmail.com>
	<57c63afe0809230837p11c1489ew46789d1b84661b66@mail.gmail.com>
	<245fb4700809231414n28d88a8re7554a383b651883@mail.gmail.com>
	<8d961d900809231454n2ed39d1vd233d9cefb9da184@mail.gmail.com>
Message-ID: <245fb4700809231647m45099c7dt2715a91f43c5dbbb@mail.gmail.com>

Seems a lot simpler than what I'd want to add. I'd want to add some story
templates (or whatever they're called) to make it easy to do common tasks.
-- Yehuda

On Tue, Sep 23, 2008 at 2:54 PM, aslak hellesoy <aslak.hellesoy at gmail.com>wrote:

> On Tue, Sep 23, 2008 at 11:14 PM, Yehuda Katz <wycats at gmail.com> wrote:
> > I'm also really excited about cucumber/merb combos and might be looking
> into
> > adding some support for common stories. I'd love to take a look at
> anything
> > you do first so I could potentially integrate it :)
> > -- Yehuda
> >
>
> That's great! I'd add be happy to have some Merb glue in the Cucumber
> codebase - similar to what's there for Rails:
> http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/rails
>
> Aslak
>
> > On Tue, Sep 23, 2008 at 8:37 AM, David Chelimsky <dchelimsky at gmail.com>
> > wrote:
> >>
> >> On Tue, Sep 23, 2008 at 10:32 AM, Matthijs Langenberg
> >> <mlangenberg at gmail.com> wrote:
> >> > David,
> >> >
> >> > I haven't used the story runner on a project yet, but I'm planning to
> >> > use Cucumber on a Merb project (if actually possible).
> >>
> >> Anything's possible, though you'll have to provide some of your own
> >> magic. Cucumber is already wired to deal w/ rolling back AR
> >> transactions between each scenario, but that's only for AR.
> >>
> >> > I'm really excited about Cucumber I'll toy around with in the next
> days.
> >>
> >> Let us know how it works.
> >>
> >> Thanks,
> >> David
> >>
> >> >
> >> >
> >> > - Matthijs
> >> >
> >> > On Mon, Sep 22, 2008 at 3:52 PM, David Chelimsky <
> dchelimsky at gmail.com>
> >> > wrote:
> >> >> Hey all,
> >> >>
> >> >> Let's make this official. We're planning to replace the RSpec Story
> >> >> Runner with Cucumber. The rspec-1.1.5 release will still include the
> >> >> Story Runner (several fixes since the last release). So if you're not
> >> >> already using stories and you want to start, start with cucumber
> >> >> (http://github.com/aslakhellesoy/cucumber).
> >> >>
> >> >> For those of you already using stories, we're going to take steps to
> >> >> make this as simple as possible.
> >> >>
> >> >> 1. We're going to do one more release with things as they are
> >> >> currently structured (with Story Runner as part of the gem/plugin).
> >> >> 2. Aslak has posted the current migration path at
> >> >>
> >> >>
> http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories
> >> >> and we'll work to make it simpler if we can.
> >> >> 3. Story Runner will be released as a separate gem/plugin that you
> are
> >> >> free to use, however we're not putting any additional development
> >> >> effort into it once cucumber is released. It will be up on github and
> >> >> anyone who wishes to use/maintain it is free to do so.
> >> >>
> >> >> Feel free to respond with questions/concerns (praise is welcome
> too!).
> >> >> We're really excited about Cucumber and all the benefits it brings
> >> >> (see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
> >> >> to make the transition as easy as we can for the pioneers among you
> >> >> who are already using stories.
> >> >>
> >> >> 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
> >
> >
> >
> > --
> > Yehuda Katz
> > Developer | Engine Yard
> > (ph) 718.877.1325
> >
> > _______________________________________________
> > 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
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080923/44279014/attachment.html>

From dchelimsky at gmail.com  Tue Sep 23 21:16:32 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 23 Sep 2008 20:16:32 -0500
Subject: [rspec-devel] plans for cucumber
In-Reply-To: <245fb4700809231647m45099c7dt2715a91f43c5dbbb@mail.gmail.com>
References: <57c63afe0809220652p583efd03l9feccb3c1ffaab47@mail.gmail.com>
	<27c0ac6d0809230832t19fabdb0wc531c6cc7f7dbc95@mail.gmail.com>
	<57c63afe0809230837p11c1489ew46789d1b84661b66@mail.gmail.com>
	<245fb4700809231414n28d88a8re7554a383b651883@mail.gmail.com>
	<8d961d900809231454n2ed39d1vd233d9cefb9da184@mail.gmail.com>
	<245fb4700809231647m45099c7dt2715a91f43c5dbbb@mail.gmail.com>
Message-ID: <57c63afe0809231816q43636dddv1b7feee1723a3713@mail.gmail.com>

On Tue, Sep 23, 2008 at 6:47 PM, Yehuda Katz <wycats at gmail.com> wrote:
> Seems a lot simpler than what I'd want to add. I'd want to add some story
> templates (or whatever they're called)

Step definitions.

>to make it easy to do common tasks.
> -- Yehuda
>
> On Tue, Sep 23, 2008 at 2:54 PM, aslak hellesoy <aslak.hellesoy at gmail.com>
> wrote:
>>
>> On Tue, Sep 23, 2008 at 11:14 PM, Yehuda Katz <wycats at gmail.com> wrote:
>> > I'm also really excited about cucumber/merb combos and might be looking
>> > into
>> > adding some support for common stories. I'd love to take a look at
>> > anything
>> > you do first so I could potentially integrate it :)
>> > -- Yehuda
>> >
>>
>> That's great! I'd add be happy to have some Merb glue in the Cucumber
>> codebase - similar to what's there for Rails:
>> http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/rails
>>
>> Aslak
>>
>> > On Tue, Sep 23, 2008 at 8:37 AM, David Chelimsky <dchelimsky at gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Sep 23, 2008 at 10:32 AM, Matthijs Langenberg
>> >> <mlangenberg at gmail.com> wrote:
>> >> > David,
>> >> >
>> >> > I haven't used the story runner on a project yet, but I'm planning to
>> >> > use Cucumber on a Merb project (if actually possible).
>> >>
>> >> Anything's possible, though you'll have to provide some of your own
>> >> magic. Cucumber is already wired to deal w/ rolling back AR
>> >> transactions between each scenario, but that's only for AR.
>> >>
>> >> > I'm really excited about Cucumber I'll toy around with in the next
>> >> > days.
>> >>
>> >> Let us know how it works.
>> >>
>> >> Thanks,
>> >> David
>> >>
>> >> >
>> >> >
>> >> > - Matthijs
>> >> >
>> >> > On Mon, Sep 22, 2008 at 3:52 PM, David Chelimsky
>> >> > <dchelimsky at gmail.com>
>> >> > wrote:
>> >> >> Hey all,
>> >> >>
>> >> >> Let's make this official. We're planning to replace the RSpec Story
>> >> >> Runner with Cucumber. The rspec-1.1.5 release will still include the
>> >> >> Story Runner (several fixes since the last release). So if you're
>> >> >> not
>> >> >> already using stories and you want to start, start with cucumber
>> >> >> (http://github.com/aslakhellesoy/cucumber).
>> >> >>
>> >> >> For those of you already using stories, we're going to take steps to
>> >> >> make this as simple as possible.
>> >> >>
>> >> >> 1. We're going to do one more release with things as they are
>> >> >> currently structured (with Story Runner as part of the gem/plugin).
>> >> >> 2. Aslak has posted the current migration path at
>> >> >>
>> >> >>
>> >> >> http://github.com/aslakhellesoy/cucumber/wikis/migration-from-rspec-stories
>> >> >> and we'll work to make it simpler if we can.
>> >> >> 3. Story Runner will be released as a separate gem/plugin that you
>> >> >> are
>> >> >> free to use, however we're not putting any additional development
>> >> >> effort into it once cucumber is released. It will be up on github
>> >> >> and
>> >> >> anyone who wishes to use/maintain it is free to do so.
>> >> >>
>> >> >> Feel free to respond with questions/concerns (praise is welcome
>> >> >> too!).
>> >> >> We're really excited about Cucumber and all the benefits it brings
>> >> >> (see http://blog.davidchelimsky.net/2008/9/22/cucumber), and we want
>> >> >> to make the transition as easy as we can for the pioneers among you
>> >> >> who are already using stories.
>> >> >>
>> >> >> 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
>> >
>> >
>> >
>> > --
>> > Yehuda Katz
>> > Developer | Engine Yard
>> > (ph) 718.877.1325
>> >
>> > _______________________________________________
>> > 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
>
>
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From linojon at gmail.com  Wed Sep 24 20:44:46 2008
From: linojon at gmail.com (linojon)
Date: Wed, 24 Sep 2008 20:44:46 -0400
Subject: [rspec-devel] directory structure/naming
In-Reply-To: <57c63afe0809221903q2eaf5b40y2048fc7424fae488@mail.gmail.com>
References: <57c63afe0809220710w26fc6863o5103a03421e969b0@mail.gmail.com>
	<48D7C5E3.3030007@benmabey.com>
	<732EF7AB-A241-446F-912A-B8B3A17E7A89@gmail.com>
	<85d99afe0809221836xef600e6s74d85996782520e@mail.gmail.com>
	<57c63afe0809221847y1ce31275hfb4e349688c168e5@mail.gmail.com>
	<48D84DB5.6070405@benmabey.com>
	<57c63afe0809221903q2eaf5b40y2048fc7424fae488@mail.gmail.com>
Message-ID: <FFD086E9-D97D-4C01-B57D-A934FA71D129@gmail.com>

btw, it occurs to me that my specs read more like 'rules'
while scenarios read more like 'examples'

linoj

From mailing_lists at railsnewbie.com  Wed Sep 24 21:49:35 2008
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Wed, 24 Sep 2008 21:49:35 -0400
Subject: [rspec-devel] Cucumber transactions
Message-ID: <482924CB-06B8-4E42-B33C-5A5F863594AC@railsnewbie.com>


How often are transactions rolled back in Cucumber?  Is it once a  
scenario, or once for a whole story file?

Scott


From dchelimsky at gmail.com  Wed Sep 24 21:55:32 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 24 Sep 2008 20:55:32 -0500
Subject: [rspec-devel] Cucumber transactions
In-Reply-To: <482924CB-06B8-4E42-B33C-5A5F863594AC@railsnewbie.com>
References: <482924CB-06B8-4E42-B33C-5A5F863594AC@railsnewbie.com>
Message-ID: <57c63afe0809241855q10493bdfy9b648b5dfca90294@mail.gmail.com>

On Wed, Sep 24, 2008 at 8:49 PM, Scott Taylor
<mailing_lists at railsnewbie.com> wrote:
>
> How often are transactions rolled back in Cucumber?  Is it once a scenario,
> or once for a whole story file?

Scenarios. Take a look at
http://github.com/aslakhellesoy/cucumber/tree/master/lib/cucumber/rails/world.rb.
Before and After happen at Scenario boundaries

Cheers,
David

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

From dchelimsky at gmail.com  Thu Sep 25 10:01:43 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 25 Sep 2008 09:01:43 -0500
Subject: [rspec-devel] interesting idea about GivenScenario
Message-ID: <57c63afe0809250701h21a3cf10j736b739adb679b3b@mail.gmail.com>

Hey all,

For those interested in cucumber development, please check out
http://rspec.lighthouseapp.com/projects/16211/tickets/3 and feel free
to add your comments.

Thanks,
David

From dchelimsky at gmail.com  Sun Sep 28 22:07:55 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 28 Sep 2008 21:07:55 -0500
Subject: [rspec-devel] [ANN] RSpec-1.1.5 has been released
Message-ID: <57c63afe0809281907o154d7388p3396383e4671ee9c@mail.gmail.com>

RSpec-1.1.5 has been released

RSpec is a Behaviour Driven Development framework for Ruby.

RSpec-1.1.5 has a ton of minor changes and bug fixes, and a few major ones.

Please see the following for more information:

http://rspec.info/rdoc/files/History_txt.html
http://rspec.info/rdoc-rails/files/History_txt.html
http://rspec.info
http://github.com/dchelimsky/rspec/wikis
http://rspec.lighthouseapp.com

Thanks,
The RSpec Development Team

From dchelimsky at gmail.com  Mon Sep 29 23:22:50 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 29 Sep 2008 22:22:50 -0500
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
Message-ID: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>

The convention for gems is that the top level module shares a name
with the gem, but rspec uses 'spec' instead, resulting in things like
this:

require 'rubygems'
gem 'rspec'
require 'spec'

I'd like to propose that we change the 'spec' namespace to 'rspec'.
We'd have to continue to support 'spec' for backwards compatibility
for a long time, but we can do that with a few extra files that just
require other files.

Thoughts?

From jim.weirich at gmail.com  Mon Sep 29 23:28:07 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Mon, 29 Sep 2008 23:28:07 -0400
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
Message-ID: <9476C1F2-D9DB-4D3F-8BD4-D5D19223BE8E@gmail.com>


On Sep 29, 2008, at 11:22 PM, David Chelimsky wrote:

> The convention for gems is that the top level module shares a name
> with the gem, but rspec uses 'spec' instead, resulting in things like
> this:
>
> require 'rubygems'
> gem 'rspec'
> require 'spec'
>
> I'd like to propose that we change the 'spec' namespace to 'rspec'.
> We'd have to continue to support 'spec' for backwards compatibility
> for a long time, but we can do that with a few extra files that just
> require other files.

The second line has no effect.  The following is equivalent:

   require 'rubygems'
   require 'spec'

In which case, it might be a good thing to get the library name (gem  
name) on the require.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From deanwampler at gmail.com  Mon Sep 29 23:28:39 2008
From: deanwampler at gmail.com (Dean Wampler)
Date: Mon, 29 Sep 2008 22:28:39 -0500
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
Message-ID: <6cf2a94f0809292028pe24484do7409314846406c78@mail.gmail.com>

+1

On Mon, Sep 29, 2008 at 10:22 PM, David Chelimsky <dchelimsky at gmail.com>wrote:

> The convention for gems is that the top level module shares a name
> with the gem, but rspec uses 'spec' instead, resulting in things like
> this:
>
> require 'rubygems'
> gem 'rspec'
> require 'spec'
>
> I'd like to propose that we change the 'spec' namespace to 'rspec'.
> We'd have to continue to support 'spec' for backwards compatibility
> for a long time, but we can do that with a few extra files that just
> require other files.
>
> Thoughts?
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Dean Wampler
http://www.objectmentor.com
http://www.polyglotprogramming.com
http://www.aspectprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080929/898b8859/attachment.html>

From luislavena at gmail.com  Mon Sep 29 23:29:46 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 30 Sep 2008 01:29:46 -0200
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <9476C1F2-D9DB-4D3F-8BD4-D5D19223BE8E@gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<9476C1F2-D9DB-4D3F-8BD4-D5D19223BE8E@gmail.com>
Message-ID: <71166b3b0809292029r733d3184t3ef6be695046a340@mail.gmail.com>

On Tue, Sep 30, 2008 at 1:28 AM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Sep 29, 2008, at 11:22 PM, David Chelimsky wrote:
>
>> The convention for gems is that the top level module shares a name
>> with the gem, but rspec uses 'spec' instead, resulting in things like
>> this:
>>
>> require 'rubygems'
>> gem 'rspec'
>> require 'spec'
>>
>> I'd like to propose that we change the 'spec' namespace to 'rspec'.
>> We'd have to continue to support 'spec' for backwards compatibility
>> for a long time, but we can do that with a few extra files that just
>> require other files.
>
> The second line has no effect.  The following is equivalent:
>
>  require 'rubygems'
>  require 'spec'
>
> In which case, it might be a good thing to get the library name (gem name)
> on the require.
>

Unless you're creating a RSpec extension or plugin that depends on a
specific RSpec version, and you will require gem method to enable that
specific one and not the lastest one (as default behavior or
RubyGems).

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Mon Sep 29 23:29:55 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 30 Sep 2008 01:29:55 -0200
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
Message-ID: <71166b3b0809292029p5e771a2dl88b8ee9d00bfee8c@mail.gmail.com>

On Tue, Sep 30, 2008 at 1:22 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> The convention for gems is that the top level module shares a name
> with the gem, but rspec uses 'spec' instead, resulting in things like
> this:
>
> require 'rubygems'
> gem 'rspec'
> require 'spec'
>
> I'd like to propose that we change the 'spec' namespace to 'rspec'.
> We'd have to continue to support 'spec' for backwards compatibility
> for a long time, but we can do that with a few extra files that just
> require other files.
>
> Thoughts?

That recommendation is just to change the require, or the namespace also?

Spec::*

Becames RSpec::*

For the initial require: +1
For the namespace change: -1

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From dchelimsky at gmail.com  Mon Sep 29 23:30:03 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 29 Sep 2008 22:30:03 -0500
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <9476C1F2-D9DB-4D3F-8BD4-D5D19223BE8E@gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<9476C1F2-D9DB-4D3F-8BD4-D5D19223BE8E@gmail.com>
Message-ID: <57c63afe0809292030l41325153p74b053961f3ffc38@mail.gmail.com>

On Mon, Sep 29, 2008 at 10:28 PM, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On Sep 29, 2008, at 11:22 PM, David Chelimsky wrote:
>
>> The convention for gems is that the top level module shares a name
>> with the gem, but rspec uses 'spec' instead, resulting in things like
>> this:
>>
>> require 'rubygems'
>> gem 'rspec'
>> require 'spec'
>>
>> I'd like to propose that we change the 'spec' namespace to 'rspec'.
>> We'd have to continue to support 'spec' for backwards compatibility
>> for a long time, but we can do that with a few extra files that just
>> require other files.
>
> The second line has no effect.  The following is equivalent:
>
>  require 'rubygems'
>  require 'spec'

Wouldn't the 2nd line have an effect if you wanted to specify a version?

require 'rubygems'
gem 'rspec', '=1.1.5'
require 'spec'

> In which case, it might be a good thing to get the library name (gem name)
> on the require.
>
> --
> -- Jim Weirich
> -- jim.weirich at gmail.com

From pergesu at gmail.com  Mon Sep 29 23:35:35 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Mon, 29 Sep 2008 20:35:35 -0700
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	(David Chelimsky's message of "Mon\,
	29 Sep 2008 22\:22\:50 -0500")
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
Message-ID: <m2k5cufgqg.fsf@gmail.com>

"David Chelimsky" <dchelimsky at gmail.com> writes:

> The convention for gems is that the top level module shares a name
> with the gem, but rspec uses 'spec' instead, resulting in things like
> this:
>
> require 'rubygems'
> gem 'rspec'
> require 'spec'
>
> I'd like to propose that we change the 'spec' namespace to 'rspec'.
> We'd have to continue to support 'spec' for backwards compatibility
> for a long time, but we can do that with a few extra files that just
> require other files.
>
> Thoughts?

I nearly always write
require 'rspec'

when I start a new app, and am confused for a bit before I remember that
it's just spec.  It was kind of funny when I was pairing one time:
me: *types require 'rspec'*
pair: "Isn't it just require 'spec'?"
me: "oh right"
pair: "aren't you on the rspec team?"

:)

Pat

From dchelimsky at gmail.com  Mon Sep 29 23:42:37 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 29 Sep 2008 22:42:37 -0500
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <71166b3b0809292029p5e771a2dl88b8ee9d00bfee8c@mail.gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<71166b3b0809292029p5e771a2dl88b8ee9d00bfee8c@mail.gmail.com>
Message-ID: <57c63afe0809292042h24fc51d6mdce81cf243817555@mail.gmail.com>

On Mon, Sep 29, 2008 at 10:29 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Tue, Sep 30, 2008 at 1:22 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> The convention for gems is that the top level module shares a name
>> with the gem, but rspec uses 'spec' instead, resulting in things like
>> this:
>>
>> require 'rubygems'
>> gem 'rspec'
>> require 'spec'
>>
>> I'd like to propose that we change the 'spec' namespace to 'rspec'.
>> We'd have to continue to support 'spec' for backwards compatibility
>> for a long time, but we can do that with a few extra files that just
>> require other files.
>>
>> Thoughts?
>
> That recommendation is just to change the require, or the namespace also?
>
> Spec::*
>
> Becames RSpec::*
>
> For the initial require: +1
> For the namespace change: -1

I didn't really mention that, did I? I think it's the right thing to
do, but obviously there are other opinions. Can you explain why you'd
not want them to move together, as long as we also aliased the RSpec
module with Spec?

> --
> Luis Lavena

From luislavena at gmail.com  Mon Sep 29 23:49:02 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 30 Sep 2008 01:49:02 -0200
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <57c63afe0809292042h24fc51d6mdce81cf243817555@mail.gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<71166b3b0809292029p5e771a2dl88b8ee9d00bfee8c@mail.gmail.com>
	<57c63afe0809292042h24fc51d6mdce81cf243817555@mail.gmail.com>
Message-ID: <71166b3b0809292049u21ece5cfpe16cc88355b3afea@mail.gmail.com>

On Tue, Sep 30, 2008 at 1:42 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Mon, Sep 29, 2008 at 10:29 PM, Luis Lavena <luislavena at gmail.com> wrote:
>> On Tue, Sep 30, 2008 at 1:22 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>>> The convention for gems is that the top level module shares a name
>>> with the gem, but rspec uses 'spec' instead, resulting in things like
>>> this:
>>>
>>> require 'rubygems'
>>> gem 'rspec'
>>> require 'spec'
>>>
>>> I'd like to propose that we change the 'spec' namespace to 'rspec'.
>>> We'd have to continue to support 'spec' for backwards compatibility
>>> for a long time, but we can do that with a few extra files that just
>>> require other files.
>>>
>>> Thoughts?
>>
>> That recommendation is just to change the require, or the namespace also?
>>
>> Spec::*
>>
>> Becames RSpec::*
>>
>> For the initial require: +1
>> For the namespace change: -1
>
> I didn't really mention that, did I? I think it's the right thing to
> do, but obviously there are other opinions. Can you explain why you'd
> not want them to move together, as long as we also aliased the RSpec
> module with Spec?
>



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

To quote your own words:

"I'd like to propose that we change the 'spec' namespace to 'rspec'."

But the mail started with renaming the top level module to make the
initial require more compliant, so I got mixed feelings.

I any case, I use most of RSpec out of the box. If Spec namespace will
be deprecated, I hope will stay long enough for plugin developers move
to the new convention :-)

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From dchelimsky at gmail.com  Mon Sep 29 23:53:34 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 29 Sep 2008 22:53:34 -0500
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <71166b3b0809292049u21ece5cfpe16cc88355b3afea@mail.gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<71166b3b0809292029p5e771a2dl88b8ee9d00bfee8c@mail.gmail.com>
	<57c63afe0809292042h24fc51d6mdce81cf243817555@mail.gmail.com>
	<71166b3b0809292049u21ece5cfpe16cc88355b3afea@mail.gmail.com>
Message-ID: <57c63afe0809292053p7ec878bfk1399e1654e70d0b@mail.gmail.com>

On Mon, Sep 29, 2008 at 10:49 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Tue, Sep 30, 2008 at 1:42 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On Mon, Sep 29, 2008 at 10:29 PM, Luis Lavena <luislavena at gmail.com> wrote:
>>> On Tue, Sep 30, 2008 at 1:22 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>>>> The convention for gems is that the top level module shares a name
>>>> with the gem, but rspec uses 'spec' instead, resulting in things like
>>>> this:
>>>>
>>>> require 'rubygems'
>>>> gem 'rspec'
>>>> require 'spec'
>>>>
>>>> I'd like to propose that we change the 'spec' namespace to 'rspec'.
>>>> We'd have to continue to support 'spec' for backwards compatibility
>>>> for a long time, but we can do that with a few extra files that just
>>>> require other files.
>>>>
>>>> Thoughts?
>>>
>>> That recommendation is just to change the require, or the namespace also?
>>>
>>> Spec::*
>>>
>>> Becames RSpec::*
>>>
>>> For the initial require: +1
>>> For the namespace change: -1
>>
>> I didn't really mention that, did I? I think it's the right thing to
>> do, but obviously there are other opinions. Can you explain why you'd
>> not want them to move together, as long as we also aliased the RSpec
>> module with Spec?

If we do this, we'd absolutely support the 'spec' directory and Spec
namespace for a good long time.

>>
>
>
>
>>> --
>>> Luis Lavena
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>
> To quote your own words:
>
> "I'd like to propose that we change the 'spec' namespace to 'rspec'."
>
> But the mail started with renaming the top level module to make the
> initial require more compliant, so I got mixed feelings.
>
> I any case, I use most of RSpec out of the box. If Spec namespace will
> be deprecated, I hope will stay long enough for plugin developers move
> to the new convention :-)
>
> --
> Luis Lavena
> AREA 17
> -
> Human beings, who are almost unique in having the ability to learn from
> the experience of others, are also remarkable for their apparent
> disinclination to do so.
> Douglas Adams
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From jim.weirich at gmail.com  Tue Sep 30 00:27:31 2008
From: jim.weirich at gmail.com (Jim Weirich)
Date: Tue, 30 Sep 2008 00:27:31 -0400
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <57c63afe0809292030l41325153p74b053961f3ffc38@mail.gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<9476C1F2-D9DB-4D3F-8BD4-D5D19223BE8E@gmail.com>
	<57c63afe0809292030l41325153p74b053961f3ffc38@mail.gmail.com>
Message-ID: <698F4DA6-B2AA-42A2-A1AD-0C1140478A4E@gmail.com>


On Sep 29, 2008, at 11:30 PM, David Chelimsky wrote:

> Wouldn't the 2nd line have an effect if you wanted to specify a  
> version?

Yes, but then it would be a different 2nd line, wouldn't it?  :)

Rule of thumb: Always supply a version when using the "gem" statement,  
or just omit it.

-- 
-- Jim Weirich
-- jim.weirich at gmail.com


From mailing_lists at railsnewbie.com  Tue Sep 30 00:53:46 2008
From: mailing_lists at railsnewbie.com (Scott Taylor)
Date: Tue, 30 Sep 2008 00:53:46 -0400
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <m2k5cufgqg.fsf@gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<m2k5cufgqg.fsf@gmail.com>
Message-ID: <842CCBD3-E665-4861-8015-20F0E8BADD10@railsnewbie.com>


On Sep 29, 2008, at 11:35 PM, Pat Maddox wrote:

> "David Chelimsky" <dchelimsky at gmail.com> writes:
>
>> The convention for gems is that the top level module shares a name
>> with the gem, but rspec uses 'spec' instead, resulting in things like
>> this:
>>
>> require 'rubygems'
>> gem 'rspec'
>> require 'spec'
>>
>> I'd like to propose that we change the 'spec' namespace to 'rspec'.
>> We'd have to continue to support 'spec' for backwards compatibility
>> for a long time, but we can do that with a few extra files that just
>> require other files.
>>
>> Thoughts?
>
> I nearly always write
> require 'rspec'
>
> when I start a new app, and am confused for a bit before I remember  
> that
> it's just spec.  It was kind of funny when I was pairing one time:
> me: *types require 'rspec'*
> pair: "Isn't it just require 'spec'?"
> me: "oh right"
> pair: "aren't you on the rspec team?"
>
> :)

Haha.

Is the top level constant going to be Rspec, or RSpec?

Scott


From aslak.hellesoy at gmail.com  Tue Sep 30 03:47:19 2008
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 30 Sep 2008 09:47:19 +0200
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <842CCBD3-E665-4861-8015-20F0E8BADD10@railsnewbie.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<m2k5cufgqg.fsf@gmail.com>
	<842CCBD3-E665-4861-8015-20F0E8BADD10@railsnewbie.com>
Message-ID: <8d961d900809300047s325afe07g1f71cc2da5108c60@mail.gmail.com>

On Tue, Sep 30, 2008 at 6:53 AM, Scott Taylor
<mailing_lists at railsnewbie.com> wrote:
>
> On Sep 29, 2008, at 11:35 PM, Pat Maddox wrote:
>
>> "David Chelimsky" <dchelimsky at gmail.com> writes:
>>
>>> The convention for gems is that the top level module shares a name
>>> with the gem, but rspec uses 'spec' instead, resulting in things like
>>> this:
>>>
>>> require 'rubygems'
>>> gem 'rspec'
>>> require 'spec'
>>>
>>> I'd like to propose that we change the 'spec' namespace to 'rspec'.
>>> We'd have to continue to support 'spec' for backwards compatibility
>>> for a long time, but we can do that with a few extra files that just
>>> require other files.
>>>
>>> Thoughts?
>>
>> I nearly always write
>> require 'rspec'
>>
>> when I start a new app, and am confused for a bit before I remember that
>> it's just spec.  It was kind of funny when I was pairing one time:
>> me: *types require 'rspec'*
>> pair: "Isn't it just require 'spec'?"
>> me: "oh right"
>> pair: "aren't you on the rspec team?"
>>
>> :)
>
> Haha.
>
> Is the top level constant going to be Rspec, or RSpec?
>

Like the name of the project - RSpec

Aslak

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

From blake at near-time.com  Tue Sep 30 09:05:57 2008
From: blake at near-time.com (Blake Watters)
Date: Tue, 30 Sep 2008 09:05:57 -0400
Subject: [rspec-devel] [Proposal] change 'spec' to 'rspec'
In-Reply-To: <8d961d900809300047s325afe07g1f71cc2da5108c60@mail.gmail.com>
References: <57c63afe0809292022i5413c2b5v3643db3ff5055dda@mail.gmail.com>
	<m2k5cufgqg.fsf@gmail.com>
	<842CCBD3-E665-4861-8015-20F0E8BADD10@railsnewbie.com>
	<8d961d900809300047s325afe07g1f71cc2da5108c60@mail.gmail.com>
Message-ID: <b90035d60809300605o150cd9edk6bfb8c2cb50cfe0f@mail.gmail.com>

+1. consistency and predictability++

On Tue, Sep 30, 2008 at 3:47 AM, aslak hellesoy <aslak.hellesoy at gmail.com>wrote:

> On Tue, Sep 30, 2008 at 6:53 AM, Scott Taylor
> <mailing_lists at railsnewbie.com> wrote:
> >
> > On Sep 29, 2008, at 11:35 PM, Pat Maddox wrote:
> >
> >> "David Chelimsky" <dchelimsky at gmail.com> writes:
> >>
> >>> The convention for gems is that the top level module shares a name
> >>> with the gem, but rspec uses 'spec' instead, resulting in things like
> >>> this:
> >>>
> >>> require 'rubygems'
> >>> gem 'rspec'
> >>> require 'spec'
> >>>
> >>> I'd like to propose that we change the 'spec' namespace to 'rspec'.
> >>> We'd have to continue to support 'spec' for backwards compatibility
> >>> for a long time, but we can do that with a few extra files that just
> >>> require other files.
> >>>
> >>> Thoughts?
> >>
> >> I nearly always write
> >> require 'rspec'
> >>
> >> when I start a new app, and am confused for a bit before I remember that
> >> it's just spec.  It was kind of funny when I was pairing one time:
> >> me: *types require 'rspec'*
> >> pair: "Isn't it just require 'spec'?"
> >> me: "oh right"
> >> pair: "aren't you on the rspec team?"
> >>
> >> :)
> >
> > Haha.
> >
> > Is the top level constant going to be Rspec, or RSpec?
> >
>
> Like the name of the project - RSpec
>
> Aslak
>
> > Scott
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-devel/attachments/20080930/b82cefa2/attachment-0001.html>

From lianliming at gmail.com  Tue Sep 30 11:45:14 2008
From: lianliming at gmail.com (Lian Liming)
Date: Tue, 30 Sep 2008 23:45:14 +0800
Subject: [rspec-devel] Error when running Spec:Rails
Message-ID: <2ab0f52d0809300845yf1c4635jbf9120d69e2b9478@mail.gmail.com>

Hi all,

I am trying to use Spec:Rails, when running "rake spec", I got following error:

/usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/aliasing.rb:31:in
`alias_method': undefined method `evaluate_value_proc' for class
`Spec::Matchers::Change' (NameError)
	from /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/aliasing.rb:31:in
`alias_method_chain'
	from /home/data/projects/MicroBlogging/linkey/vendor/plugins/rspec-rails/lib/spec/rails/matchers/change.rb:8
.........(omit the rest of error msg)


I am using Rails 2.1.0 and rspec 1.1.5, and following the installation
guide on http://github.com/dchelimsky/rspec-rails/wikis

Any possible wrong? Any help is appreciated and thanks in advance!

Liming

From dchelimsky at gmail.com  Tue Sep 30 11:47:51 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 30 Sep 2008 10:47:51 -0500
Subject: [rspec-devel] Error when running Spec:Rails
In-Reply-To: <2ab0f52d0809300845yf1c4635jbf9120d69e2b9478@mail.gmail.com>
References: <2ab0f52d0809300845yf1c4635jbf9120d69e2b9478@mail.gmail.com>
Message-ID: <57c63afe0809300847u377d1a18vd2c7567546eeb459@mail.gmail.com>

On Tue, Sep 30, 2008 at 10:45 AM, Lian Liming <lianliming at gmail.com> wrote:
> Hi all,
>
> I am trying to use Spec:Rails, when running "rake spec", I got following error:
>
> /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/aliasing.rb:31:in
> `alias_method': undefined method `evaluate_value_proc' for class
> `Spec::Matchers::Change' (NameError)
>        from /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/aliasing.rb:31:in
> `alias_method_chain'
>        from /home/data/projects/MicroBlogging/linkey/vendor/plugins/rspec-rails/lib/spec/rails/matchers/change.rb:8
> .........(omit the rest of error msg)
>
>
> I am using Rails 2.1.0 and rspec 1.1.5, and following the installation
> guide on http://github.com/dchelimsky/rspec-rails/wikis

You don't have compatible versions of rspec and rspec-rails. Make sure
you either get the versions tagged 1.1.5 of both, or that you have the
latest of both.

>
> Any possible wrong? Any help is appreciated and thanks in advance!
>
> Liming
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From lianliming at gmail.com  Tue Sep 30 12:01:55 2008
From: lianliming at gmail.com (Lian Liming)
Date: Wed, 1 Oct 2008 00:01:55 +0800
Subject: [rspec-devel] Error when running Spec:Rails
In-Reply-To: <57c63afe0809300847u377d1a18vd2c7567546eeb459@mail.gmail.com>
References: <2ab0f52d0809300845yf1c4635jbf9120d69e2b9478@mail.gmail.com>
	<57c63afe0809300847u377d1a18vd2c7567546eeb459@mail.gmail.com>
Message-ID: <2ab0f52d0809300901x23b7a9e8j14f76d8a8a7c6560@mail.gmail.com>

Hi Dave,

Thanks for your quick reply!

I am not familiar with GIT, i am guessing that to fix this error, I
should re-install the rspec:rails plugin for my rails project and use
"git checkout 1.1.5" instead of "git checkout 1.1.4" as documented?

Thanks again!

On Tue, Sep 30, 2008 at 11:47 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Tue, Sep 30, 2008 at 10:45 AM, Lian Liming <lianliming at gmail.com> wrote:
>> Hi all,
>>
>> I am trying to use Spec:Rails, when running "rake spec", I got following error:
>>
>> /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/aliasing.rb:31:in
>> `alias_method': undefined method `evaluate_value_proc' for class
>> `Spec::Matchers::Change' (NameError)
>>        from /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/aliasing.rb:31:in
>> `alias_method_chain'
>>        from /home/data/projects/MicroBlogging/linkey/vendor/plugins/rspec-rails/lib/spec/rails/matchers/change.rb:8
>> .........(omit the rest of error msg)
>>
>>
>> I am using Rails 2.1.0 and rspec 1.1.5, and following the installation
>> guide on http://github.com/dchelimsky/rspec-rails/wikis
>
> You don't have compatible versions of rspec and rspec-rails. Make sure
> you either get the versions tagged 1.1.5 of both, or that you have the
> latest of both.
>
>>
>> Any possible wrong? Any help is appreciated and thanks in advance!
>>
>> Liming
>> _______________________________________________
>> 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 Sep 30 12:04:30 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 30 Sep 2008 11:04:30 -0500
Subject: [rspec-devel] Error when running Spec:Rails
In-Reply-To: <2ab0f52d0809300901x23b7a9e8j14f76d8a8a7c6560@mail.gmail.com>
References: <2ab0f52d0809300845yf1c4635jbf9120d69e2b9478@mail.gmail.com>
	<57c63afe0809300847u377d1a18vd2c7567546eeb459@mail.gmail.com>
	<2ab0f52d0809300901x23b7a9e8j14f76d8a8a7c6560@mail.gmail.com>
Message-ID: <57c63afe0809300904w5dd07d90t692fcbbf400ee89a@mail.gmail.com>

On Tue, Sep 30, 2008 at 11:01 AM, Lian Liming <lianliming at gmail.com> wrote:
> Hi Dave,
>
> Thanks for your quick reply!
>
> I am not familiar with GIT, i am guessing that to fix this error, I
> should re-install the rspec:rails plugin for my rails project and use
> "git checkout 1.1.5" instead of "git checkout 1.1.4" as documented?

Or you could uninstall the plugins and just use the gems:

gem install rspec
gem install rspec-rails

As of the 1.1.5 release, that works!

>
> Thanks again!
>
> On Tue, Sep 30, 2008 at 11:47 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On Tue, Sep 30, 2008 at 10:45 AM, Lian Liming <lianliming at gmail.com> wrote:
>>> Hi all,
>>>
>>> I am trying to use Spec:Rails, when running "rake spec", I got following error:
>>>
>>> /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/aliasing.rb:31:in
>>> `alias_method': undefined method `evaluate_value_proc' for class
>>> `Spec::Matchers::Change' (NameError)
>>>        from /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.0/lib/active_support/core_ext/module/aliasing.rb:31:in
>>> `alias_method_chain'
>>>        from /home/data/projects/MicroBlogging/linkey/vendor/plugins/rspec-rails/lib/spec/rails/matchers/change.rb:8
>>> .........(omit the rest of error msg)
>>>
>>>
>>> I am using Rails 2.1.0 and rspec 1.1.5, and following the installation
>>> guide on http://github.com/dchelimsky/rspec-rails/wikis
>>
>> You don't have compatible versions of rspec and rspec-rails. Make sure
>> you either get the versions tagged 1.1.5 of both, or that you have the
>> latest of both.
>>
>>>
>>> Any possible wrong? Any help is appreciated and thanks in advance!
>>>
>>> Liming
>>> _______________________________________________
>>> 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 lianliming at gmail.com  Tue Sep 30 12:15:25 2008
From: lianliming at gmail.com (Lian Liming)
Date: Wed, 1 Oct 2008 00:15:25 +0800
Subject: [rspec-devel] Error when running Spec:Rails
In-Reply-To: <57c63afe0809300904w5dd07d90t692fcbbf400ee89a@mail.gmail.com>
References: <2ab0f52d0809300845yf1c4635jbf9120d69e2b9478@mail.gmail.com>
	<57c63afe0809300847u377d1a18vd2c7567546eeb459@mail.gmail.com>
	<2ab0f52d0809300901x23b7a9e8j14f76d8a8a7c6560@mail.gmail.com>
	<57c63afe0809300904w5dd07d90t692fcbbf400ee89a@mail.gmail.com>
Message-ID: <2ab0f52d0809300915k4d416107ha18309c079204dd9@mail.gmail.com>

Hi Dave,

> Or you could uninstall the plugins and just use the gems:
>
> gem install rspec
> gem install rspec-rails

That works for me, thanks