From lachiec at gmail.com  Thu Jun  1 00:47:40 2006
From: lachiec at gmail.com (Lachie)
Date: Thu, 1 Jun 2006 14:47:40 +1000
Subject: [Rspec-devel] RSpec on Rails
Message-ID: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>

Hi everyone,
I've been working on an RSpec plugin for rails

Its a joy.

http://lachie.info/svn/projects/rails_plugins/rspec_on_rails/README

Features:
* minimal impact on RSpec - overwrites Spec::Runner::Context#run, adds
to Context, Specification and ExecutionContext
* pragmatic - only supports what I (and my contributor :) have needed so far
* mashes in rails' fixture loading - I only use yaml
* mashes in rails' test controller setup
* mashes in much of zenspider's Test::Rails::ControllerTestCase
* can automatically load the Controller for verification.
* many of rails' custom, crufty asserts aren't even needed with the
beauty of "should"
* provides rake tasks for running specs
* uses the plugin install hook to create a spec directory, including
the spec_helper required to use the rails features
* its a plugin, so the barrier of using it in a rails app is very low.

AntiFeatures:
* pragmatic - only supports what I (and my contributor :) have needed so far
* opportunistic - lots of snatch-n-grab code from Rails and Zenspider
source. I blame the tightly coupled design of the original code, of
course.

However, it does bring RSpec to Rails. My recent apps have received a
dose of RSpec goodness, and both I and the apps have benefitted
immensely from the experience.

Is anyone actively pimping RSpec? I've talked to fellow Rails/Ruby
devs who've never heard of it!

Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From aslak.hellesoy at gmail.com  Thu Jun  1 00:57:15 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 31 May 2006 23:57:15 -0500
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
Message-ID: <8d961d900605312157t436f0700h7e0d5294a771bb59@mail.gmail.com>

a quick answer because it's late and i'm a little tipsy...

this sounds great!
i have done some rails work myself on a branch (branches/ar_fixtures_facade)
it sounds like you have done a lot more though!

i'll definitely take a closer look tomorrow and give more detailed feedback

cheers,
aslak

On 5/31/06, Lachie <lachiec at gmail.com> wrote:
> Hi everyone,
> I've been working on an RSpec plugin for rails
>
> Its a joy.
>
> http://lachie.info/svn/projects/rails_plugins/rspec_on_rails/README
>
> Features:
> * minimal impact on RSpec - overwrites Spec::Runner::Context#run, adds
> to Context, Specification and ExecutionContext
> * pragmatic - only supports what I (and my contributor :) have needed so far
> * mashes in rails' fixture loading - I only use yaml
> * mashes in rails' test controller setup
> * mashes in much of zenspider's Test::Rails::ControllerTestCase
> * can automatically load the Controller for verification.
> * many of rails' custom, crufty asserts aren't even needed with the
> beauty of "should"
> * provides rake tasks for running specs
> * uses the plugin install hook to create a spec directory, including
> the spec_helper required to use the rails features
> * its a plugin, so the barrier of using it in a rails app is very low.
>
> AntiFeatures:
> * pragmatic - only supports what I (and my contributor :) have needed so far
> * opportunistic - lots of snatch-n-grab code from Rails and Zenspider
> source. I blame the tightly coupled design of the original code, of
> course.
>
> However, it does bring RSpec to Rails. My recent apps have received a
> dose of RSpec goodness, and both I and the apps have benefitted
> immensely from the experience.
>
> Is anyone actively pimping RSpec? I've talked to fellow Rails/Ruby
> devs who've never heard of it!
>
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dastels at daveastels.com  Thu Jun  1 01:29:28 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 1 Jun 2006 02:29:28 -0300
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
Message-ID: <D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>


On 1-Jun-06, at 1:47 AM, Lachie wrote:

> Hi everyone,
> I've been working on an RSpec plugin for rails

Sweet.  I'll have a closer look in the next day or so as well.

> However, it does bring RSpec to Rails. My recent apps have received a
> dose of RSpec goodness, and both I and the apps have benefitted
> immensely from the experience.

Very cool!

> Is anyone actively pimping RSpec? I've talked to fellow Rails/Ruby
> devs who've never heard of it!

I'm speaking about it at conferences & such.  I have a public rSpec  
workshop coming up in July in Toronto.  It's still pretty new, though.

Dave



From srbaker at pobox.com  Thu Jun  1 13:16:58 2006
From: srbaker at pobox.com (Steven R. Baker)
Date: Thu, 1 Jun 2006 10:16:58 -0700
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
Message-ID: <0BC0BA30-61A5-4077-B3B7-7E85CBD01358@pobox.com>

> Hi everyone,
> I've been working on an RSpec plugin for rails

Great, so have I.  You should look me up on irc (srbaker) so we can  
combine notes.

> Features:
> * minimal impact on RSpec - overwrites Spec::Runner::Context#run, adds
> to Context, Specification and ExecutionContext
> * pragmatic - only supports what I (and my contributor :) have  
> needed so far
> * mashes in rails' fixture loading - I only use yaml
> * mashes in rails' test controller setup
> * mashes in much of zenspider's Test::Rails::ControllerTestCase
> * can automatically load the Controller for verification.
> * many of rails' custom, crufty asserts aren't even needed with the
> beauty of "should"
> * provides rake tasks for running specs
> * uses the plugin install hook to create a spec directory, including
> the spec_helper required to use the rails features
> * its a plugin, so the barrier of using it in a rails app is very low.

I have rake integration, database loading, fixtures, etc.  We should  
discuss the best way to set up the environment for what Rails Tests  
use for controller loading.  Currently, the way functional tests are  
done in rails encourages (requires?) a 1:1 Class:Test, which is bad.

> AntiFeatures:
> * pragmatic - only supports what I (and my contributor :) have  
> needed so far
> * opportunistic - lots of snatch-n-grab code from Rails and Zenspider
> source. I blame the tightly coupled design of the original code, of
> course.

I have been pulling the code that I've been using from rails into a  
module that mixes in at run time.  This will get submitted as a patch  
back to rails, since Rails Testing, RSpec, and the RailsTest stuff  
use a lot of ti.

> However, it does bring RSpec to Rails. My recent apps have received a
> dose of RSpec goodness, and both I and the apps have benefitted
> immensely from the experience.
>
> Is anyone actively pimping RSpec? I've talked to fellow Rails/Ruby
> devs who've never heard of it!

A couple of us have been speaking at conferences and user groups on  
the subject.  The word is getting around well.

-Steven


From lachiec at gmail.com  Thu Jun  1 20:19:00 2006
From: lachiec at gmail.com (Lachie)
Date: Fri, 2 Jun 2006 10:19:00 +1000
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <0BC0BA30-61A5-4077-B3B7-7E85CBD01358@pobox.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<0BC0BA30-61A5-4077-B3B7-7E85CBD01358@pobox.com>
Message-ID: <2c5e719e0606011719n5634ae2di1fef7040d453a0e2@mail.gmail.com>

On 6/2/06, Steven R. Baker <srbaker at pobox.com> wrote:
> > Hi everyone,
> > I've been working on an RSpec plugin for rails
>
> Great, so have I.  You should look me up on irc (srbaker) so we can
> combine notes.

I'll try... I'm in Australia, so timezones will be an issue. Do you
tend to hang out there all day?

>
> > Features:
> > * minimal impact on RSpec - overwrites Spec::Runner::Context#run, adds
> > to Context, Specification and ExecutionContext
> > * pragmatic - only supports what I (and my contributor :) have
> > needed so far
> > * mashes in rails' fixture loading - I only use yaml
> > * mashes in rails' test controller setup
> > * mashes in much of zenspider's Test::Rails::ControllerTestCase
> > * can automatically load the Controller for verification.
> > * many of rails' custom, crufty asserts aren't even needed with the
> > beauty of "should"
> > * provides rake tasks for running specs
> > * uses the plugin install hook to create a spec directory, including
> > the spec_helper required to use the rails features
> > * its a plugin, so the barrier of using it in a rails app is very low.
>
> I have rake integration, database loading, fixtures, etc.  We should
> discuss the best way to set up the environment for what Rails Tests
> use for controller loading.  Currently, the way functional tests are
> done in rails encourages (requires?) a 1:1 Class:Test, which is bad.

Would you mind expanding on this? I'm not exactly sure how this translates to
rSpec.

I usually create contexts so that their meaning in English is heightened.
Generally, that means 1 Controller -> 1 spec file but 1 Controller ->
many contexts.

I dig the rSpec approach's openness.

> > AntiFeatures:
> > * pragmatic - only supports what I (and my contributor :) have
> > needed so far
> > * opportunistic - lots of snatch-n-grab code from Rails and Zenspider
> > source. I blame the tightly coupled design of the original code, of
> > course.
>
> I have been pulling the code that I've been using from rails into a
> module that mixes in at run time.  This will get submitted as a patch
> back to rails, since Rails Testing, RSpec, and the RailsTest stuff
> use a lot of ti.

I thought of doing that too. But Rails-corites have said that the way
to Rails' heart is through its plugins. In other words, its only worth
their while to integrate that kind of patch if the popularity of the
rSpec Way mandates it.

Also, IMO the rails stuff works, but could be better. In particular,
Zenspider's Controller and View TestCase stuff makes much more sense
than Rails' own.

I don't think there's anything super complex or holy about the Rails
internal implementation.

> > However, it does bring RSpec to Rails. My recent apps have received a
> > dose of RSpec goodness, and both I and the apps have benefitted
> > immensely from the experience.
> >
> > Is anyone actively pimping RSpec? I've talked to fellow Rails/Ruby
> > devs who've never heard of it!
>
> A couple of us have been speaking at conferences and user groups on
> the subject.  The word is getting around well.

Unfortunately, most of the world doesn't get the same glut of ruby or
rails conferences which the north america or even europe does.
<sniff,sniff>

Australia, for example, has zero. We are connected via lists like
this, and IRC when the timezones match -- but we have to know about
them first. The blogosphere is really the only way we can learn about
the new coolness.

I think that rSpec needs lots more good blog articles - tips and
tricks, style guides, complex usage. The spec site is very slick and
quite helpful, but you have to want it before you go there. Are there
some out there which I've overlooked?

Fortunately, a rails community is growing in Sydney. There are
probably half a dozen of us, whom I may have the opportunity to
present rSpec and my plugin.


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

-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From deanmao at gmail.com  Fri Jun  2 12:32:21 2006
From: deanmao at gmail.com (Dean Mao)
Date: Fri, 2 Jun 2006 12:32:21 -0400
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
Message-ID: <5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>

Probably the best way to pimp it...  is to get other app devs to use it as
their main testing framework...  so anyone else that wants to read/add to
the tests, will have to figure out how to work rSpec magic.  So far, I'm
pleased with it...  pleased enough that I don't have to write methods like
testThatWithALongAndUglyMethodName.  (or similar ones without camel case)

Dean


On 6/1/06, David Astels <dastels at daveastels.com> wrote:
>
>
> On 1-Jun-06, at 1:47 AM, Lachie wrote:
>
> > Hi everyone,
> > I've been working on an RSpec plugin for rails
>
> Sweet.  I'll have a closer look in the next day or so as well.
>
> > However, it does bring RSpec to Rails. My recent apps have received a
> > dose of RSpec goodness, and both I and the apps have benefitted
> > immensely from the experience.
>
> Very cool!
>
> > Is anyone actively pimping RSpec? I've talked to fellow Rails/Ruby
> > devs who've never heard of it!
>
> I'm speaking about it at conferences & such.  I have a public rSpec
> workshop coming up in July in Toronto.  It's still pretty new, though.
>
> Dave
>
>
> _______________________________________________
> 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/20060602/70c664dc/attachment.htm 

From aslak.hellesoy at gmail.com  Fri Jun  2 13:43:16 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 2 Jun 2006 12:43:16 -0500
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
Message-ID: <8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>

On 6/2/06, Dean Mao <deanmao at gmail.com> wrote:
> Probably the best way to pimp it...  is to get other app devs to use it as
> their main testing framework...  so anyone else that wants to read/add to
> the tests, will have to figure out how to work rSpec magic.

I agree. Except that RSpec is not a testing framework - it's a design
framework whose by-product is executable specifications. :-)

A subtle difference, but nevertheless the raison d'etre for RSpec.

I'm out for the weekend, but I hope to add Lachie's Rails support to a
new branch in RSpec's svn next week.

As for testing (spit) the RSpec Rails plugin - I'm thinking about
checking in a minimal Rails app in svn, check in the plugin under its
vendor/plugins branch and let it live there.

We'll just have a Rakefile inside it that can package it as a gem as
well as publishing the plugin via the rails plugin mechanism.

WDYT?

Aslak

> So far, I'm
> pleased with it...  pleased enough that I don't have to write methods like
> testThatWithALongAndUglyMethodName.  (or similar ones
> without camel case)
>
> Dean
>
>
>
> On 6/1/06, David Astels <dastels at daveastels.com> wrote:
> >
> > On 1-Jun-06, at 1:47 AM, Lachie wrote:
> >
> > > Hi everyone,
> > > I've been working on an RSpec plugin for rails
> >
> > Sweet.  I'll have a closer look in the next day or so as well.
> >
> > > However, it does bring RSpec to Rails. My recent apps have received a
> > > dose of RSpec goodness, and both I and the apps have benefitted
> > > immensely from the experience.
> >
> > Very cool!
> >
> > > Is anyone actively pimping RSpec? I've talked to fellow Rails/Ruby
> > > devs who've never heard of it!
> >
> > I'm speaking about it at conferences & such.  I have a public rSpec
> > workshop coming up in July in Toronto.  It's still pretty new, though.
> >
> > Dave
> >
> >
> > _______________________________________________
> > 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 evgeny.zislis at gmail.com  Fri Jun  2 18:25:04 2006
From: evgeny.zislis at gmail.com (Evgeny)
Date: Sat, 3 Jun 2006 01:25:04 +0300
Subject: [Rspec-devel] Porting rSpec to C++
Message-ID: <b6840c770606021525r4d6dfe13rd726974ebcdf9ef5@mail.gmail.com>

Greetings All,

The projects my team are working on is written in C++ and since I have been
using rSpec with great success on my ruby projects I want to present this
new concept to my team mates in a fashion that can contribute to their
efforts.

But unfortunately I am not much of a c++ programmer, and it is taking me
quite a lot of time to come up with something that resembles rSpec.

So far, after several weeks of learning yacc/lex and bison/flex I understand
that these tools are not the best tools for the job -- because their lack of
c++ support (c works, c++ not). And since I discovered the
Boost.Spiritparser -- I came up with some drafts that looks more or
less like what I see
c++Spec should look like.

Attached to this mail is a sample spec file, and a sample c++ result file
from that spec.

1. I would want to use Boost.Spirit to parse the spec file and create the
c++ result.
2. I would want to compile this result file as a library (static or dynamic)
3. I would want to run a Runner that will use the dynamic library and my own
code and do the spec checks.
4. I would want to link my own code with the static library into a static
runner and run it to see if it passes the checks.

Is there anyone interested in this?

Can someone help out?

I am willing to contribute some resources to this matter, like
space/services(svn) on my dreamhost or something ... if needed.


Regards,

Evgeny


PS: Thanks to Steve and Dave and all the other people who came up with and
created rSpec and are making my programming experience in ruby much more
productive than it used to be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060603/1894a37b/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample_spec.ifi
Type: application/octet-stream
Size: 2528 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060603/1894a37b/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: result.cc
Type: text/x-c++src
Size: 3073 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060603/1894a37b/attachment-0001.bin 

From deanmao at gmail.com  Fri Jun  2 22:50:00 2006
From: deanmao at gmail.com (Dean Mao)
Date: Fri, 2 Jun 2006 22:50:00 -0400
Subject: [Rspec-devel] Porting rSpec to C++
In-Reply-To: <b6840c770606021525r4d6dfe13rd726974ebcdf9ef5@mail.gmail.com>
References: <b6840c770606021525r4d6dfe13rd726974ebcdf9ef5@mail.gmail.com>
Message-ID: <5ad0c3de0606021950r12d28074i922f6466be2ca084@mail.gmail.com>

I think it would be cool to see BDD being applied to other languages.
Personally, I really enjoy rSpec for their great combination of mocks &
clean dsl.

On 6/2/06, Evgeny <evgeny.zislis at gmail.com> wrote:
>
> Greetings All,
>
> The projects my team are working on is written in C++ and since I have
> been using rSpec with great success on my ruby projects I want to present
> this new concept to my team mates in a fashion that can contribute to their
> efforts.
>
> But unfortunately I am not much of a c++ programmer, and it is taking me
> quite a lot of time to come up with something that resembles rSpec.
>
> So far, after several weeks of learning yacc/lex and bison/flex I
> understand that these tools are not the best tools for the job -- because
> their lack of c++ support (c works, c++ not). And since I discovered the
> Boost.Spirit parser -- I came up with some drafts that looks more or less
> like what I see c++Spec should look like.
>
> Attached to this mail is a sample spec file, and a sample c++ result file
> from that spec.
>
> 1. I would want to use Boost.Spirit to parse the spec file and create the
> c++ result.
> 2. I would want to compile this result file as a library (static or
> dynamic)
> 3. I would want to run a Runner that will use the dynamic library and my
> own code and do the spec checks.
> 4. I would want to link my own code with the static library into a static
> runner and run it to see if it passes the checks.
>
> Is there anyone interested in this?
>
> Can someone help out?
>
> I am willing to contribute some resources to this matter, like
> space/services(svn) on my dreamhost or something ... if needed.
>
>
> Regards,
>
> Evgeny
>
>
> PS: Thanks to Steve and Dave and all the other people who came up with and
> created rSpec and are making my programming experience in ruby much more
> productive than it used to be.
>
> _______________________________________________
> 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/20060602/82ff6e3e/attachment.htm 

From dchelimsky at gmail.com  Sat Jun  3 07:44:07 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 3 Jun 2006 06:44:07 -0500
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
Message-ID: <57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>

On 6/2/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> As for testing (spit) the RSpec Rails plugin - I'm thinking about
> checking in a minimal Rails app in svn, check in the plugin under its
> vendor/plugins branch and let it live there.
>
> We'll just have a Rakefile inside it that can package it as a gem as
> well as publishing the plugin via the rails plugin mechanism.
>
> WDYT?

Works for me.

From dastels at daveastels.com  Sat Jun  3 11:38:54 2006
From: dastels at daveastels.com (David Astels)
Date: Sat, 3 Jun 2006 12:38:54 -0300
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
Message-ID: <234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>


On 3-Jun-06, at 8:44 AM, David Chelimsky wrote:

> On 6/2/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>> As for testing (spit) the RSpec Rails plugin - I'm thinking about
>> checking in a minimal Rails app in svn, check in the plugin under its
>> vendor/plugins branch and let it live there.
>>
>> We'll just have a Rakefile inside it that can package it as a gem as
>> well as publishing the plugin via the rails plugin mechanism.
>>
>> WDYT?
>
> Works for me.

+1


From lachiec at gmail.com  Sat Jun  3 20:00:57 2006
From: lachiec at gmail.com (Lachie)
Date: Sun, 4 Jun 2006 10:00:57 +1000
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
	<234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
Message-ID: <2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>

me too! (said with all the weight of being on the list for 2 whole days :)

Though, obviously there's a lot of scope for refactoring, and a few
things to add, such as spec generators.

How does the refinement process work after it goes into your tree?

Lachie

On 6/4/06, David Astels <dastels at daveastels.com> wrote:
>
> On 3-Jun-06, at 8:44 AM, David Chelimsky wrote:
>
> > On 6/2/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> >> As for testing (spit) the RSpec Rails plugin - I'm thinking about
> >> checking in a minimal Rails app in svn, check in the plugin under its
> >> vendor/plugins branch and let it live there.
> >>
> >> We'll just have a Rakefile inside it that can package it as a gem as
> >> well as publishing the plugin via the rails plugin mechanism.
> >>
> >> WDYT?
> >
> > Works for me.
>
> +1
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From chad at clearwaterassociates.ca  Sat Jun  3 20:35:48 2006
From: chad at clearwaterassociates.ca (Chad Nantais)
Date: Sat, 3 Jun 2006 20:35:48 -0400
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
	<234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
	<2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
Message-ID: <3de931600606031735w5d08f33blf1f4e054109ac223@mail.gmail.com>

Chalk up one more from me.

I am about to take a client into a new Rails project and we'll be
using the RSpec on Rails plugin for specs.  Having the plugin get the
TLC of the RSpec community will only make it more stable and
comprehensive.

Cheers,

Chad

On 6/3/06, Lachie <lachiec at gmail.com> wrote:
> me too! (said with all the weight of being on the list for 2 whole days :)
>
> Though, obviously there's a lot of scope for refactoring, and a few
> things to add, such as spec generators.
>
> How does the refinement process work after it goes into your tree?
>
> Lachie
>
> On 6/4/06, David Astels <dastels at daveastels.com> wrote:
> >
> > On 3-Jun-06, at 8:44 AM, David Chelimsky wrote:
> >
> > > On 6/2/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > >> As for testing (spit) the RSpec Rails plugin - I'm thinking about
> > >> checking in a minimal Rails app in svn, check in the plugin under its
> > >> vendor/plugins branch and let it live there.
> > >>
> > >> We'll just have a Rakefile inside it that can package it as a gem as
> > >> well as publishing the plugin via the rails plugin mechanism.
> > >>
> > >> WDYT?
> > >
> > > Works for me.
> >
> > +1
> >
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
> --
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Mon Jun  5 13:21:51 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 5 Jun 2006 12:21:51 -0500
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
	<234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
	<2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
Message-ID: <8d961d900606051021h59e693dfk756d0fa29ddcceb6@mail.gmail.com>

On 6/3/06, Lachie <lachiec at gmail.com> wrote:
> me too! (said with all the weight of being on the list for 2 whole days :)
>

OK, it's checked into trunk/vendor/rspec_on_rails.
The plugin lives under trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails

As far as testing goes, I think it's sufficient to follow the route of
'acceptance testing', i.e. write more exhaustive specs for the demo
app, and fix the plugin accordingly if it breaks.

I have written up some docs under trunk/src/documentation/rails.page
It's currently lying, since the plugin isn't yet published.

What is the best way to publish it? As a separate gem? Just 'pure' svn? Both?

> Though, obviously there's a lot of scope for refactoring, and a few
> things to add, such as spec generators.
>

That would be great!
It would also be great to override the behaviour of the general
generators, so that tests are not created, but specs instead (when the
user does script/generate model).

The fixtures should also go under spec/fixtures, and not test/fixtures.

> How does the refinement process work after it goes into your tree?
>

For starters, send patches, preferrably to the tracker at Rubyforge.
If you continue sending quality code, we'll consider your rights as a committer.

Cheers,
Aslak

> Lachie
>
> On 6/4/06, David Astels <dastels at daveastels.com> wrote:
> >
> > On 3-Jun-06, at 8:44 AM, David Chelimsky wrote:
> >
> > > On 6/2/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > >> As for testing (spit) the RSpec Rails plugin - I'm thinking about
> > >> checking in a minimal Rails app in svn, check in the plugin under its
> > >> vendor/plugins branch and let it live there.
> > >>
> > >> We'll just have a Rakefile inside it that can package it as a gem as
> > >> well as publishing the plugin via the rails plugin mechanism.
> > >>
> > >> WDYT?
> > >
> > > Works for me.
> >
> > +1
> >
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
> --
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dastels at daveastels.com  Mon Jun  5 13:31:23 2006
From: dastels at daveastels.com (David Astels)
Date: Mon, 5 Jun 2006 14:31:23 -0300
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <8d961d900606051021h59e693dfk756d0fa29ddcceb6@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
	<234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
	<2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
	<8d961d900606051021h59e693dfk756d0fa29ddcceb6@mail.gmail.com>
Message-ID: <30D51DF3-81F8-475F-99B9-786FC99DA1A5@daveastels.com>


On 5-Jun-06, at 2:21 PM, aslak hellesoy wrote:

>
>
> What is the best way to publish it? As a separate gem? Just 'pure'  
> svn? Both?

I vote or a separate gem

Dave


From lachiec at gmail.com  Mon Jun  5 19:32:48 2006
From: lachiec at gmail.com (Lachie)
Date: Tue, 6 Jun 2006 09:32:48 +1000
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <8d961d900606051021h59e693dfk756d0fa29ddcceb6@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
	<234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
	<2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
	<8d961d900606051021h59e693dfk756d0fa29ddcceb6@mail.gmail.com>
Message-ID: <2c5e719e0606051632t4bd015f2hcb5e27591a0c4496@mail.gmail.com>

On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/3/06, Lachie <lachiec at gmail.com> wrote:
> > me too! (said with all the weight of being on the list for 2 whole days :)
> >
>
> OK, it's checked into trunk/vendor/rspec_on_rails.
> The plugin lives under trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
>
> As far as testing goes, I think it's sufficient to follow the route of
> 'acceptance testing', i.e. write more exhaustive specs for the demo
> app, and fix the plugin accordingly if it breaks.

Sounds like the best way to me. A nice feature might be to set it up
to use a sqlite3 file or memory database, to alleviate the dependency
on an external database. Though, that wouldn't really allow for
testing transactions or the like.

> I have written up some docs under trunk/src/documentation/rails.page
> It's currently lying, since the plugin isn't yet published.
>
> What is the best way to publish it? As a separate gem? Just 'pure' svn? Both?

Well, the rails plugin system works in a fairly specific way -- an
installed gem wouldn't be automatically hooked by the system.

A crash course in rails plugins (apologies to those who already know it):
I would install my plugin using the following command:
script/plugin install
http://lachie.info/svn/projects/rails_plugins/rspec_on_rails/

This:
* downloads it using http, svn externals, svn export or svn checkout
  it goes into PLUGIN_ROOT=RAILS_ROOT/vendor/plugin/rspec_on_rails
* runs PLUGIN_ROOT/install.rb

The default way for it to download is via http... it can use svn
directly, but the user must have svn on their machine. Can rubyforge
provide a plain http listing of the files under svn?

When the rails app loads, it runs PLUGIN_ROOT/init.rb which pulls in
the rspec_on_rails libraries.
The generate script looks for generators here.
Rake pulls in any tasks defined in PLUGIN_ROOT/tasks

I think that an installed gem would just sit inert on the disc, unless
the user did a symlink to PLUGIN_ROOT

The "official" place to publish it is in the rails wiki... please feel
free to change my rpsec on rails entry in the testing section to point
at the http/svn path you've set up.

http://wiki.rubyonrails.com/rails/pages/Plugins

(The plugin script's discover command actually scrapes this page for
plugin sources)

You'd need to publish the path right down to the plugin:
/trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails

> > Though, obviously there's a lot of scope for refactoring, and a few
> > things to add, such as spec generators.
> >
>
> That would be great!
> It would also be great to override the behaviour of the general
> generators, so that tests are not created, but specs instead (when the
> user does script/generate model).

I was thinking the same thing... I'm sure its possible, but it might
start out being quite hacky.

> The fixtures should also go under spec/fixtures, and not test/fixtures.

oops...

-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From aslak.hellesoy at gmail.com  Mon Jun  5 20:01:28 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 5 Jun 2006 19:01:28 -0500
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <2c5e719e0606051632t4bd015f2hcb5e27591a0c4496@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
	<234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
	<2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
	<8d961d900606051021h59e693dfk756d0fa29ddcceb6@mail.gmail.com>
	<2c5e719e0606051632t4bd015f2hcb5e27591a0c4496@mail.gmail.com>
Message-ID: <8d961d900606051701j75f578cfh62c60a8235f0d7fd@mail.gmail.com>

On 6/5/06, Lachie <lachiec at gmail.com> wrote:
> On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 6/3/06, Lachie <lachiec at gmail.com> wrote:
> > > me too! (said with all the weight of being on the list for 2 whole days :)
> > >
> >
> > OK, it's checked into trunk/vendor/rspec_on_rails.
> > The plugin lives under trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
> >
> > As far as testing goes, I think it's sufficient to follow the route of
> > 'acceptance testing', i.e. write more exhaustive specs for the demo
> > app, and fix the plugin accordingly if it breaks.
>
> Sounds like the best way to me. A nice feature might be to set it up
> to use a sqlite3 file or memory database, to alleviate the dependency
> on an external database. Though, that wouldn't really allow for
> testing transactions or the like.
>

Right now it's using sqlite3 on file - not memory. Not sure what's
needed for in-memory. Patches welcome.

> > I have written up some docs under trunk/src/documentation/rails.page
> > It's currently lying, since the plugin isn't yet published.
> >
> > What is the best way to publish it? As a separate gem? Just 'pure' svn? Both?
>
> Well, the rails plugin system works in a fairly specific way -- an
> installed gem wouldn't be automatically hooked by the system.
>
> A crash course in rails plugins (apologies to those who already know it):
> I would install my plugin using the following command:
> script/plugin install
> http://lachie.info/svn/projects/rails_plugins/rspec_on_rails/
>

I'd rather not use the default plugin mechanism, as it's not
particularly well suited for moving target code such as rspec. The
user will always get head (unless we start tagging) - and
incompatibilities between various versions of the plugin, rspec and
rails itself is a potential can of worms.

So I think we should go for a gem/generator approach. Any gem ending
with _generator is automatically picked up by rails. If we package
this as a gem called rspec_generator, users would be able to do:

gem install rspec_generator
script/generate rspec # => puts the spec_helper.rb in place and
creates empty directories.

We should provide generators that will replace all the test stuff. For
example for models:

script/generate rspec model customer
or
script/generate rspec_model customer
or simply
script/generate model customer (as before - if we can hijack the
builtin generators)

(See more on this below)

> This:
> * downloads it using http, svn externals, svn export or svn checkout
>   it goes into PLUGIN_ROOT=RAILS_ROOT/vendor/plugin/rspec_on_rails
> * runs PLUGIN_ROOT/install.rb
>

I know, but I'd rather not because of potential versioning problems.

> The default way for it to download is via http... it can use svn
> directly, but the user must have svn on their machine. Can rubyforge
> provide a plain http listing of the files under svn?
>

Only the svn:// protocol is supported afaik

> When the rails app loads, it runs PLUGIN_ROOT/init.rb which pulls in
> the rspec_on_rails libraries.
> The generate script looks for generators here.
> Rake pulls in any tasks defined in PLUGIN_ROOT/tasks
>
> I think that an installed gem would just sit inert on the disc, unless
> the user did a symlink to PLUGIN_ROOT
>
> The "official" place to publish it is in the rails wiki... please feel
> free to change my rpsec on rails entry in the testing section to point
> at the http/svn path you've set up.
>
> http://wiki.rubyonrails.com/rails/pages/Plugins
>
> (The plugin script's discover command actually scrapes this page for
> plugin sources)
>
> You'd need to publish the path right down to the plugin:
> /trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
>
> > > Though, obviously there's a lot of scope for refactoring, and a few
> > > things to add, such as spec generators.
> > >
> >
> > That would be great!
> > It would also be great to override the behaviour of the general
> > generators, so that tests are not created, but specs instead (when the
> > user does script/generate model).
>
> I was thinking the same thing... I'm sure its possible, but it might
> start out being quite hacky.
>

See the various alternatives above. We should pick whatever makes most
sense from a user's perspective, provided it's not too hacky. I'd
prefer to let everything remain the same for the user, i.e.

script/generate model customer

will create:

spec/fixtures/customer.yml instead of test/fixtures/customer.yml
and
spec/models/customer_spec.rb instead of test/unit/customer_test.rb

-provided the user has previously configured his rails project to be
rspec-based (using simply script/generate rspec).

Let me know what you think of the generator-as-gem approach instead of
http/svn based plugins.

Aslak

> > The fixtures should also go under spec/fixtures, and not test/fixtures.
>
> oops...
>
> --
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From lachiec at gmail.com  Mon Jun  5 21:51:43 2006
From: lachiec at gmail.com (Lachie)
Date: Tue, 6 Jun 2006 11:51:43 +1000
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <8d961d900606051701j75f578cfh62c60a8235f0d7fd@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<D672399B-6443-4430-8B27-68705F950F7E@daveastels.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
	<234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
	<2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
	<8d961d900606051021h59e693dfk756d0fa29ddcceb6@mail.gmail.com>
	<2c5e719e0606051632t4bd015f2hcb5e27591a0c4496@mail.gmail.com>
	<8d961d900606051701j75f578cfh62c60a8235f0d7fd@mail.gmail.com>
Message-ID: <2c5e719e0606051851y65f35db1s8634b448a40e032a@mail.gmail.com>

just a quickie, i've implemented the generators to override model and
controller generators

i'll give em a burl and submit a patch later

more on this later, but i think that if we go the rspec generator
route, how would the overridden generators work?

On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/5/06, Lachie <lachiec at gmail.com> wrote:
> > On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 6/3/06, Lachie <lachiec at gmail.com> wrote:
> > > > me too! (said with all the weight of being on the list for 2 whole days :)
> > > >
> > >
> > > OK, it's checked into trunk/vendor/rspec_on_rails.
> > > The plugin lives under trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
> > >
> > > As far as testing goes, I think it's sufficient to follow the route of
> > > 'acceptance testing', i.e. write more exhaustive specs for the demo
> > > app, and fix the plugin accordingly if it breaks.
> >
> > Sounds like the best way to me. A nice feature might be to set it up
> > to use a sqlite3 file or memory database, to alleviate the dependency
> > on an external database. Though, that wouldn't really allow for
> > testing transactions or the like.
> >
>
> Right now it's using sqlite3 on file - not memory. Not sure what's
> needed for in-memory. Patches welcome.
>
> > > I have written up some docs under trunk/src/documentation/rails.page
> > > It's currently lying, since the plugin isn't yet published.
> > >
> > > What is the best way to publish it? As a separate gem? Just 'pure' svn? Both?
> >
> > Well, the rails plugin system works in a fairly specific way -- an
> > installed gem wouldn't be automatically hooked by the system.
> >
> > A crash course in rails plugins (apologies to those who already know it):
> > I would install my plugin using the following command:
> > script/plugin install
> > http://lachie.info/svn/projects/rails_plugins/rspec_on_rails/
> >
>
> I'd rather not use the default plugin mechanism, as it's not
> particularly well suited for moving target code such as rspec. The
> user will always get head (unless we start tagging) - and
> incompatibilities between various versions of the plugin, rspec and
> rails itself is a potential can of worms.
>
> So I think we should go for a gem/generator approach. Any gem ending
> with _generator is automatically picked up by rails. If we package
> this as a gem called rspec_generator, users would be able to do:
>
> gem install rspec_generator
> script/generate rspec # => puts the spec_helper.rb in place and
> creates empty directories.
>
> We should provide generators that will replace all the test stuff. For
> example for models:
>
> script/generate rspec model customer
> or
> script/generate rspec_model customer
> or simply
> script/generate model customer (as before - if we can hijack the
> builtin generators)
>
> (See more on this below)
>
> > This:
> > * downloads it using http, svn externals, svn export or svn checkout
> >   it goes into PLUGIN_ROOT=RAILS_ROOT/vendor/plugin/rspec_on_rails
> > * runs PLUGIN_ROOT/install.rb
> >
>
> I know, but I'd rather not because of potential versioning problems.
>
> > The default way for it to download is via http... it can use svn
> > directly, but the user must have svn on their machine. Can rubyforge
> > provide a plain http listing of the files under svn?
> >
>
> Only the svn:// protocol is supported afaik
>
> > When the rails app loads, it runs PLUGIN_ROOT/init.rb which pulls in
> > the rspec_on_rails libraries.
> > The generate script looks for generators here.
> > Rake pulls in any tasks defined in PLUGIN_ROOT/tasks
> >
> > I think that an installed gem would just sit inert on the disc, unless
> > the user did a symlink to PLUGIN_ROOT
> >
> > The "official" place to publish it is in the rails wiki... please feel
> > free to change my rpsec on rails entry in the testing section to point
> > at the http/svn path you've set up.
> >
> > http://wiki.rubyonrails.com/rails/pages/Plugins
> >
> > (The plugin script's discover command actually scrapes this page for
> > plugin sources)
> >
> > You'd need to publish the path right down to the plugin:
> > /trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
> >
> > > > Though, obviously there's a lot of scope for refactoring, and a few
> > > > things to add, such as spec generators.
> > > >
> > >
> > > That would be great!
> > > It would also be great to override the behaviour of the general
> > > generators, so that tests are not created, but specs instead (when the
> > > user does script/generate model).
> >
> > I was thinking the same thing... I'm sure its possible, but it might
> > start out being quite hacky.
> >
>
> See the various alternatives above. We should pick whatever makes most
> sense from a user's perspective, provided it's not too hacky. I'd
> prefer to let everything remain the same for the user, i.e.
>
> script/generate model customer
>
> will create:
>
> spec/fixtures/customer.yml instead of test/fixtures/customer.yml
> and
> spec/models/customer_spec.rb instead of test/unit/customer_test.rb
>
> -provided the user has previously configured his rails project to be
> rspec-based (using simply script/generate rspec).
>
> Let me know what you think of the generator-as-gem approach instead of
> http/svn based plugins.
>
> Aslak
>
> > > The fixtures should also go under spec/fixtures, and not test/fixtures.
> >
> > oops...
> >
> > --
> > Lachie
> > http://lachie.info/
> > http://www.flickr.com/photos/lachie/
> > _______________________________________________
> > 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
>


-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From aslak.hellesoy at gmail.com  Mon Jun  5 23:21:55 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 5 Jun 2006 22:21:55 -0500
Subject: [Rspec-devel] RSpec on Rails
In-Reply-To: <2c5e719e0606051851y65f35db1s8634b448a40e032a@mail.gmail.com>
References: <2c5e719e0605312147x1bfed659sae30abed57ba84dd@mail.gmail.com>
	<5ad0c3de0606020932l5c9e6971j4dac10b979d75621@mail.gmail.com>
	<8d961d900606021043k71a08ca2h8257b8abae3395c0@mail.gmail.com>
	<57c63afe0606030444o4f6cd74dr69a2ee96d987afe0@mail.gmail.com>
	<234D75FF-E919-476F-83A3-C6399FE2D2DB@daveastels.com>
	<2c5e719e0606031700u33f06c0ev9172ab6448210a6d@mail.gmail.com>
	<8d961d900606051021h59e693dfk756d0fa29ddcceb6@mail.gmail.com>
	<2c5e719e0606051632t4bd015f2hcb5e27591a0c4496@mail.gmail.com>
	<8d961d900606051701j75f578cfh62c60a8235f0d7fd@mail.gmail.com>
	<2c5e719e0606051851y65f35db1s8634b448a40e032a@mail.gmail.com>
Message-ID: <8d961d900606052021r7531eebftf91bd60b9bd41bba@mail.gmail.com>

On 6/5/06, Lachie <lachiec at gmail.com> wrote:
> just a quickie, i've implemented the generators to override model and
> controller generators
>

great. i'm reorganising the source code a bit towards a gem/generator
structure - i'll commit something in a couple of hours.

> i'll give em a burl and submit a patch later
>
> more on this later, but i think that if we go the rspec generator
> route, how would the overridden generators work?
>

i don't know yet - i'm writing my first generator now, and don't know
enough about the internals yet.

but it's ruby so there must be an easy way ;-)

aslak

> On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 6/5/06, Lachie <lachiec at gmail.com> wrote:
> > > On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > On 6/3/06, Lachie <lachiec at gmail.com> wrote:
> > > > > me too! (said with all the weight of being on the list for 2 whole days :)
> > > > >
> > > >
> > > > OK, it's checked into trunk/vendor/rspec_on_rails.
> > > > The plugin lives under trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
> > > >
> > > > As far as testing goes, I think it's sufficient to follow the route of
> > > > 'acceptance testing', i.e. write more exhaustive specs for the demo
> > > > app, and fix the plugin accordingly if it breaks.
> > >
> > > Sounds like the best way to me. A nice feature might be to set it up
> > > to use a sqlite3 file or memory database, to alleviate the dependency
> > > on an external database. Though, that wouldn't really allow for
> > > testing transactions or the like.
> > >
> >
> > Right now it's using sqlite3 on file - not memory. Not sure what's
> > needed for in-memory. Patches welcome.
> >
> > > > I have written up some docs under trunk/src/documentation/rails.page
> > > > It's currently lying, since the plugin isn't yet published.
> > > >
> > > > What is the best way to publish it? As a separate gem? Just 'pure' svn? Both?
> > >
> > > Well, the rails plugin system works in a fairly specific way -- an
> > > installed gem wouldn't be automatically hooked by the system.
> > >
> > > A crash course in rails plugins (apologies to those who already know it):
> > > I would install my plugin using the following command:
> > > script/plugin install
> > > http://lachie.info/svn/projects/rails_plugins/rspec_on_rails/
> > >
> >
> > I'd rather not use the default plugin mechanism, as it's not
> > particularly well suited for moving target code such as rspec. The
> > user will always get head (unless we start tagging) - and
> > incompatibilities between various versions of the plugin, rspec and
> > rails itself is a potential can of worms.
> >
> > So I think we should go for a gem/generator approach. Any gem ending
> > with _generator is automatically picked up by rails. If we package
> > this as a gem called rspec_generator, users would be able to do:
> >
> > gem install rspec_generator
> > script/generate rspec # => puts the spec_helper.rb in place and
> > creates empty directories.
> >
> > We should provide generators that will replace all the test stuff. For
> > example for models:
> >
> > script/generate rspec model customer
> > or
> > script/generate rspec_model customer
> > or simply
> > script/generate model customer (as before - if we can hijack the
> > builtin generators)
> >
> > (See more on this below)
> >
> > > This:
> > > * downloads it using http, svn externals, svn export or svn checkout
> > >   it goes into PLUGIN_ROOT=RAILS_ROOT/vendor/plugin/rspec_on_rails
> > > * runs PLUGIN_ROOT/install.rb
> > >
> >
> > I know, but I'd rather not because of potential versioning problems.
> >
> > > The default way for it to download is via http... it can use svn
> > > directly, but the user must have svn on their machine. Can rubyforge
> > > provide a plain http listing of the files under svn?
> > >
> >
> > Only the svn:// protocol is supported afaik
> >
> > > When the rails app loads, it runs PLUGIN_ROOT/init.rb which pulls in
> > > the rspec_on_rails libraries.
> > > The generate script looks for generators here.
> > > Rake pulls in any tasks defined in PLUGIN_ROOT/tasks
> > >
> > > I think that an installed gem would just sit inert on the disc, unless
> > > the user did a symlink to PLUGIN_ROOT
> > >
> > > The "official" place to publish it is in the rails wiki... please feel
> > > free to change my rpsec on rails entry in the testing section to point
> > > at the http/svn path you've set up.
> > >
> > > http://wiki.rubyonrails.com/rails/pages/Plugins
> > >
> > > (The plugin script's discover command actually scrapes this page for
> > > plugin sources)
> > >
> > > You'd need to publish the path right down to the plugin:
> > > /trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
> > >
> > > > > Though, obviously there's a lot of scope for refactoring, and a few
> > > > > things to add, such as spec generators.
> > > > >
> > > >
> > > > That would be great!
> > > > It would also be great to override the behaviour of the general
> > > > generators, so that tests are not created, but specs instead (when the
> > > > user does script/generate model).
> > >
> > > I was thinking the same thing... I'm sure its possible, but it might
> > > start out being quite hacky.
> > >
> >
> > See the various alternatives above. We should pick whatever makes most
> > sense from a user's perspective, provided it's not too hacky. I'd
> > prefer to let everything remain the same for the user, i.e.
> >
> > script/generate model customer
> >
> > will create:
> >
> > spec/fixtures/customer.yml instead of test/fixtures/customer.yml
> > and
> > spec/models/customer_spec.rb instead of test/unit/customer_test.rb
> >
> > -provided the user has previously configured his rails project to be
> > rspec-based (using simply script/generate rspec).
> >
> > Let me know what you think of the generator-as-gem approach instead of
> > http/svn based plugins.
> >
> > Aslak
> >
> > > > The fixtures should also go under spec/fixtures, and not test/fixtures.
> > >
> > > oops...
> > >
> > > --
> > > Lachie
> > > http://lachie.info/
> > > http://www.flickr.com/photos/lachie/
> > > _______________________________________________
> > > 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
> >
>
>
> --
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Tue Jun  6 15:26:35 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 6 Jun 2006 14:26:35 -0500
Subject: [Rspec-devel] [ANN] RSpec 0.5.5 on Rails
Message-ID: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>

Hi there!

I just released RSpec 0.5.5. There are only very minor changes to the
RSpec core, but the big news is Rails support!

The Rails support is based on Lachie Cox' contribution from last week
- it was a Rails plugin. I have now restructured it and packaged it as
a Rubygem instead (separate from the core Rspec gem).

Assuming you already have a Rails app with a properly configured
database, here is how to get started.

gem install rspec_generator
cd my/rails/app
script/generate rspec
script/generate rspec_model account
script/generate rspec_controller account index create
rake migrate
rake spec

The generators will leave some specs failing in order to suck you
right in and make you fix it.

We're having some problems with the website now, so the online docs
are not uptodate. (Nut they should be in Subversion).

Big thanks to Lachie for the code!

Feedback, questions, bugs and fixes(in the Rubyforge tracker please)
is very welcome.

Aslak

From aslak.hellesoy at gmail.com  Tue Jun  6 17:28:55 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 6 Jun 2006 16:28:55 -0500
Subject: [Rspec-devel] should_be_nil or should.be.nil
Message-ID: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>

RSpec supports both dotted and underscored syntax.

While users can choose whichever they like, I think the documentation
and examples we provide for RSpec should consistently use one style.
Right now it's rather confusing.

To avoid confusing the users.

Shall ve vote? Please reply to the latest reply - that makes counting easier.


[Dots]

[Underscores]
+1 (Aslak)

[Mixed is ok]

From srbaker at pobox.com  Tue Jun  6 17:30:57 2006
From: srbaker at pobox.com (Steven R. Baker)
Date: Tue, 6 Jun 2006 14:30:57 -0700
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
Message-ID: <DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>

Underscores.  Without question.

-Steven

On 6-Jun-06, at 2:28 PM, aslak hellesoy wrote:

> RSpec supports both dotted and underscored syntax.
>
> While users can choose whichever they like, I think the documentation
> and examples we provide for RSpec should consistently use one style.
> Right now it's rather confusing.
>
> To avoid confusing the users.
>
> Shall ve vote? Please reply to the latest reply - that makes  
> counting easier.
>
>
> [Dots]
>
> [Underscores]
> +1 (Aslak)
>
> [Mixed is ok]
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dastels at daveastels.com  Tue Jun  6 17:37:48 2006
From: dastels at daveastels.com (David Astels)
Date: Tue, 6 Jun 2006 18:37:48 -0300
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
Message-ID: <7B783C73-5118-4C4C-9144-2C5F8EE7DD25@daveastels.com>

>
>> RSpec supports both dotted and underscored syntax.
>>
>> While users can choose whichever they like, I think the documentation
>> and examples we provide for RSpec should consistently use one style.
>> Right now it's rather confusing.
>>
>> To avoid confusing the users.
>>
>> Shall ve vote? Please reply to the latest reply - that makes
>> counting easier.
>>
>>
>> [Dots]
+1 (Dave A)
>>
>> [Underscores]
>> +1 (Aslak)
+1 (Steve B)
>>
>> [Mixed is ok]

Everyone on the list, please feel free to vote!!

Dave


From chad at clearwaterassociates.ca  Tue Jun  6 17:39:03 2006
From: chad at clearwaterassociates.ca (Chad Nantais)
Date: Tue, 6 Jun 2006 17:39:03 -0400
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
Message-ID: <3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>

Underscores.



On 6/6/06, Steven R. Baker <srbaker at pobox.com> wrote:
> Underscores.  Without question.
>
> -Steven
>
> On 6-Jun-06, at 2:28 PM, aslak hellesoy wrote:
>
> > RSpec supports both dotted and underscored syntax.
> >
> > While users can choose whichever they like, I think the documentation
> > and examples we provide for RSpec should consistently use one style.
> > Right now it's rather confusing.
> >
> > To avoid confusing the users.
> >
> > Shall ve vote? Please reply to the latest reply - that makes
> > counting easier.
> >
> >
> > [Dots]
> >
> > [Underscores]
> > +1 (Aslak)
> >
> > [Mixed is ok]
> > _______________________________________________
> > 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 ged at FaerieMUD.org  Tue Jun  6 18:08:57 2006
From: ged at FaerieMUD.org (Michael Granger)
Date: Tue, 6 Jun 2006 15:08:57 -0700
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
Message-ID: <1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>

On 6-Jun-06, at 2:28 PM, aslak hellesoy wrote:

> RSpec supports both dotted and underscored syntax.
>
> While users can choose whichever they like, I think the documentation
> and examples we provide for RSpec should consistently use one style.
> Right now it's rather confusing.
>
> To avoid confusing the users.
>
> Shall ve vote? Please reply to the latest reply - that makes
> counting easier.

Underscores.

--
Michael Granger <ged at FaerieMUD.org>
Rubymage, Architect, Believer
The FaerieMUD Consortium <http://www.faeriemud.org/>





From evgeny.zislis at gmail.com  Tue Jun  6 19:05:30 2006
From: evgeny.zislis at gmail.com (Evgeny)
Date: Wed, 7 Jun 2006 02:05:30 +0300
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
Message-ID: <b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>

Dots! :)

well, dots are more consistent anyways,
since x.y.z.q.w.e.r.t.y is better than x.y.z_q_w_e_r_t.y

On 6/7/06, Michael Granger <ged at faeriemud.org> wrote:
> On 6-Jun-06, at 2:28 PM, aslak hellesoy wrote:
>
> > RSpec supports both dotted and underscored syntax.
> >
> > While users can choose whichever they like, I think the documentation
> > and examples we provide for RSpec should consistently use one style.
> > Right now it's rather confusing.
> >
> > To avoid confusing the users.
> >
> > Shall ve vote? Please reply to the latest reply - that makes
> > counting easier.
>
> Underscores.
>
> --
> Michael Granger <ged at FaerieMUD.org>
> Rubymage, Architect, Believer
> The FaerieMUD Consortium <http://www.faeriemud.org/>
>
>
>
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Tue Jun  6 19:25:24 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 6 Jun 2006 18:25:24 -0500
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
Message-ID: <8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>

On 6/6/06, Evgeny <evgeny.zislis at gmail.com> wrote:
> Dots! :)
>
> well, dots are more consistent anyways,
> since x.y.z.q.w.e.r.t.y is better than x.y.z_q_w_e_r_t.y
>

Can you elaborate on why you think dots are better?

And since I didn't elaborate on my own opinion when I voted, so here I go:

Underscores mask the fact that we're dealing with several chained method calls.
This is - IMO - A Good Thing, since it allows the reader/writer of the spec code
to focus more on readability than implementation. Underscored methods is a
well-established convention in the Ruby community. Many dots is not - and it
reminds me of a kind of code I have a strong disliking for - code that
violates the
tell/don't ask principle. Also known as the Law of Demeter, or "more
periods than a girl's locker room". I'm concerned that if RSpec
advocates long dotted calls, people might
be less inclined to avoid it in their own code. By using dots we're on
a slippery slope - advocating a bad practice.

Aslak

> On 6/7/06, Michael Granger <ged at faeriemud.org> wrote:
> > On 6-Jun-06, at 2:28 PM, aslak hellesoy wrote:
> >
> > > RSpec supports both dotted and underscored syntax.
> > >
> > > While users can choose whichever they like, I think the documentation
> > > and examples we provide for RSpec should consistently use one style.
> > > Right now it's rather confusing.
> > >
> > > To avoid confusing the users.
> > >
> > > Shall ve vote? Please reply to the latest reply - that makes
> > > counting easier.
> >
> > Underscores.
> >
> > --
> > Michael Granger <ged at FaerieMUD.org>
> > Rubymage, Architect, Believer
> > The FaerieMUD Consortium <http://www.faeriemud.org/>
> >
> >
> >
> >
> > _______________________________________________
> > 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 evgeny.zislis at gmail.com  Tue Jun  6 19:38:02 2006
From: evgeny.zislis at gmail.com (Evgeny)
Date: Wed, 7 Jun 2006 02:38:02 +0300
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
Message-ID: <b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>

When I consider the dots-vs-underscore-vs-spaces question, I dont
think in ruby. I think usability and catch-easy.
Dots are easy, they are more intuitive, since I someone who is not
well informed will be less inclined to make typos and mistakes and
code that wont-work-the-first-time-its-run.
Dots are continuation of whatever it is you are writing in that
"should" sentance.

For example.

myfoo.bar is a method on an instance of a class.

The two spec phrases would be thus :
(1) myfoo.bar.should.not.be 10
(2) myfoo.bar.should_not_be 10

Since the second phrase is somewhat of a mixed-dot-underline (like in
mixed-case), it will be much more prone to typos and mistakes - and
thus less likely to be more intuitive. There is no such problem with
the first example, this is why I fell in love with rSpec in the first
place... it extends the sentance without bringing in its own rules
that need to be followed (ie. counted intuitive)

Actually, the best solution IMHO would be spaces, as in :
(3) myfoo.bar should not be 10

Number (3) is th best in intuitive/english-closeness that you can get
-- and thus makes it the best of kind in this specification writing.
[To prove my point, notice how many spaces you are using in your
letter and weight that against
whats-more-intuitive-spaces-or-dots-or-underscores]

And underscores REQUIRE you to press two keys on your keyboard, both
shift and the - key, while dots dont. [on english keyboards anyways]

Choose DOTS! They are best! :)

Regards all,

Evgeny.

On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/6/06, Evgeny <evgeny.zislis at gmail.com> wrote:
> > Dots! :)
> >
> > well, dots are more consistent anyways,
> > since x.y.z.q.w.e.r.t.y is better than x.y.z_q_w_e_r_t.y
> >
>
> Can you elaborate on why you think dots are better?
>
> And since I didn't elaborate on my own opinion when I voted, so here I go:
>
> Underscores mask the fact that we're dealing with several chained method calls.
> This is - IMO - A Good Thing, since it allows the reader/writer of the spec code
> to focus more on readability than implementation. Underscored methods is a
> well-established convention in the Ruby community. Many dots is not - and it
> reminds me of a kind of code I have a strong disliking for - code that
> violates the
> tell/don't ask principle. Also known as the Law of Demeter, or "more
> periods than a girl's locker room". I'm concerned that if RSpec
> advocates long dotted calls, people might
> be less inclined to avoid it in their own code. By using dots we're on
> a slippery slope - advocating a bad practice.
>
> Aslak
>
> > On 6/7/06, Michael Granger <ged at faeriemud.org> wrote:
> > > On 6-Jun-06, at 2:28 PM, aslak hellesoy wrote:
> > >
> > > > RSpec supports both dotted and underscored syntax.
> > > >
> > > > While users can choose whichever they like, I think the documentation
> > > > and examples we provide for RSpec should consistently use one style.
> > > > Right now it's rather confusing.
> > > >
> > > > To avoid confusing the users.
> > > >
> > > > Shall ve vote? Please reply to the latest reply - that makes
> > > > counting easier.
> > >
> > > Underscores.
> > >
> > > --
> > > Michael Granger <ged at FaerieMUD.org>
> > > Rubymage, Architect, Believer
> > > The FaerieMUD Consortium <http://www.faeriemud.org/>
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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 evgeny.zislis at gmail.com  Tue Jun  6 19:39:55 2006
From: evgeny.zislis at gmail.com (Evgeny)
Date: Wed, 7 Jun 2006 02:39:55 +0300
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
Message-ID: <b6840c770606061639y252e7b8dv4175882c72169fd2@mail.gmail.com>

Oh, sorry for the typos.... drank a bit too much guinness i'm afraid.

On 6/7/06, Evgeny <evgeny.zislis at gmail.com> wrote:
> When I consider the dots-vs-underscore-vs-spaces question, I dont
> think in ruby. I think usability and catch-easy.
> Dots are easy, they are more intuitive, since I someone who is not
> well informed will be less inclined to make typos and mistakes and
> code that wont-work-the-first-time-its-run.
> Dots are continuation of whatever it is you are writing in that
> "should" sentance.
>
> For example.
>
> myfoo.bar is a method on an instance of a class.
>
> The two spec phrases would be thus :
> (1) myfoo.bar.should.not.be 10
> (2) myfoo.bar.should_not_be 10
>
> Since the second phrase is somewhat of a mixed-dot-underline (like in
> mixed-case), it will be much more prone to typos and mistakes - and
> thus less likely to be more intuitive. There is no such problem with
> the first example, this is why I fell in love with rSpec in the first
> place... it extends the sentance without bringing in its own rules
> that need to be followed (ie. counted intuitive)
>
> Actually, the best solution IMHO would be spaces, as in :
> (3) myfoo.bar should not be 10
>
> Number (3) is th best in intuitive/english-closeness that you can get
> -- and thus makes it the best of kind in this specification writing.
> [To prove my point, notice how many spaces you are using in your
> letter and weight that against
> whats-more-intuitive-spaces-or-dots-or-underscores]
>
> And underscores REQUIRE you to press two keys on your keyboard, both
> shift and the - key, while dots dont. [on english keyboards anyways]
>
> Choose DOTS! They are best! :)
>
> Regards all,
>
> Evgeny.
>
> On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 6/6/06, Evgeny <evgeny.zislis at gmail.com> wrote:
> > > Dots! :)
> > >
> > > well, dots are more consistent anyways,
> > > since x.y.z.q.w.e.r.t.y is better than x.y.z_q_w_e_r_t.y
> > >
> >
> > Can you elaborate on why you think dots are better?
> >
> > And since I didn't elaborate on my own opinion when I voted, so here I go:
> >
> > Underscores mask the fact that we're dealing with several chained method calls.
> > This is - IMO - A Good Thing, since it allows the reader/writer of the spec code
> > to focus more on readability than implementation. Underscored methods is a
> > well-established convention in the Ruby community. Many dots is not - and it
> > reminds me of a kind of code I have a strong disliking for - code that
> > violates the
> > tell/don't ask principle. Also known as the Law of Demeter, or "more
> > periods than a girl's locker room". I'm concerned that if RSpec
> > advocates long dotted calls, people might
> > be less inclined to avoid it in their own code. By using dots we're on
> > a slippery slope - advocating a bad practice.
> >
> > Aslak
> >
> > > On 6/7/06, Michael Granger <ged at faeriemud.org> wrote:
> > > > On 6-Jun-06, at 2:28 PM, aslak hellesoy wrote:
> > > >
> > > > > RSpec supports both dotted and underscored syntax.
> > > > >
> > > > > While users can choose whichever they like, I think the documentation
> > > > > and examples we provide for RSpec should consistently use one style.
> > > > > Right now it's rather confusing.
> > > > >
> > > > > To avoid confusing the users.
> > > > >
> > > > > Shall ve vote? Please reply to the latest reply - that makes
> > > > > counting easier.
> > > >
> > > > Underscores.
> > > >
> > > > --
> > > > Michael Granger <ged at FaerieMUD.org>
> > > > Rubymage, Architect, Believer
> > > > The FaerieMUD Consortium <http://www.faeriemud.org/>
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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 dastels at daveastels.com  Tue Jun  6 19:49:02 2006
From: dastels at daveastels.com (David Astels)
Date: Tue, 6 Jun 2006 20:49:02 -0300
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
Message-ID: <3DAC1871-8678-4B8B-AEB6-6C6A0947D475@daveastels.com>


On 6-Jun-06, at 8:38 PM, Evgeny wrote:

> When I consider the dots-vs-underscore-vs-spaces question

Nicely said, imho.

> Actually, the best solution IMHO would be spaces, as in :
> myfoo.bar should not be 10

You'll probably like sSpec then!  The above would be

      myfoo bar should not be: 10

Dave


From lachiec at gmail.com  Tue Jun  6 19:54:57 2006
From: lachiec at gmail.com (Lachie)
Date: Wed, 7 Jun 2006 09:54:57 +1000
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
Message-ID: <2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>

I'm torn now...

underscores makes me think of:

class FooTestCase < Test::Unit::TestCase
    def test_should_really_be_rspeccing_because_writing_all_this_in_a_method_name_is_naff
    end
end

and in use, underscores would break most editors' code completion approaches.

The dots made me look twice at rSpec in the first place, but it was
more because it was such a novel approach.

in the end
+1 Underscore


On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/6/06, Evgeny <evgeny.zislis at gmail.com> wrote:
> > Dots! :)
> >
> > well, dots are more consistent anyways,
> > since x.y.z.q.w.e.r.t.y is better than x.y.z_q_w_e_r_t.y
> >
>
> Can you elaborate on why you think dots are better?
>
> And since I didn't elaborate on my own opinion when I voted, so here I go:
>
> Underscores mask the fact that we're dealing with several chained method calls.
> This is - IMO - A Good Thing, since it allows the reader/writer of the spec code
> to focus more on readability than implementation. Underscored methods is a
> well-established convention in the Ruby community. Many dots is not - and it
> reminds me of a kind of code I have a strong disliking for - code that
> violates the
> tell/don't ask principle. Also known as the Law of Demeter, or "more
> periods than a girl's locker room". I'm concerned that if RSpec
> advocates long dotted calls, people might
> be less inclined to avoid it in their own code. By using dots we're on
> a slippery slope - advocating a bad practice.
>
> Aslak
>
> > On 6/7/06, Michael Granger <ged at faeriemud.org> wrote:
> > > On 6-Jun-06, at 2:28 PM, aslak hellesoy wrote:
> > >
> > > > RSpec supports both dotted and underscored syntax.
> > > >
> > > > While users can choose whichever they like, I think the documentation
> > > > and examples we provide for RSpec should consistently use one style.
> > > > Right now it's rather confusing.
> > > >
> > > > To avoid confusing the users.
> > > >
> > > > Shall ve vote? Please reply to the latest reply - that makes
> > > > counting easier.
> > >
> > > Underscores.
> > >
> > > --
> > > Michael Granger <ged at FaerieMUD.org>
> > > Rubymage, Architect, Believer
> > > The FaerieMUD Consortium <http://www.faeriemud.org/>
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>


-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From dchelimsky at gmail.com  Tue Jun  6 20:05:07 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 6 Jun 2006 20:05:07 -0400
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>
Message-ID: <57c63afe0606061705x12ac70a0o289f988744f7c49e@mail.gmail.com>

On 6/6/06, Lachie <lachiec at gmail.com> wrote:
> The dots made me look twice at rSpec in the first place, but it was
> more because it was such a novel approach.
>
> in the end
> +1 Underscore
>

Bear in mind that the initial syntax was underscores. The dots were
introduced later in order to make the implementation simpler and more
robust. So from an implementation standpoint, I'd prefer to only
support dots. From a usability standpoint, I'd like to use
underscores. So, since I live on both sides of that divide:

+. 5 Dots
+ .5 Underscores

From cuong.tran at gmail.com  Tue Jun  6 21:04:29 2006
From: cuong.tran at gmail.com (Cuong Tran)
Date: Tue, 6 Jun 2006 20:04:29 -0500
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <57c63afe0606061705x12ac70a0o289f988744f7c49e@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>
	<57c63afe0606061705x12ac70a0o289f988744f7c49e@mail.gmail.com>
Message-ID: <8a73c7940606061804r5bcb4842w46d6e212ca50900b@mail.gmail.com>

I'm just a rspec beginner but I would vote for DOT since it's a bit easier
on my finger :-)
My little finger is overwork already.

On 6/6/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 6/6/06, Lachie <lachiec at gmail.com> wrote:
> > The dots made me look twice at rSpec in the first place, but it was
> > more because it was such a novel approach.
> >
> > in the end
> > +1 Underscore
> >
>
> Bear in mind that the initial syntax was underscores. The dots were
> introduced later in order to make the implementation simpler and more
> robust. So from an implementation standpoint, I'd prefer to only
> support dots. From a usability standpoint, I'd like to use
> underscores. So, since I live on both sides of that divide:
>
> +. 5 Dots
> + .5 Underscores
> _______________________________________________
> 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/20060606/7f45a8ca/attachment.htm 

From lists-rspec at shopwatch.org  Tue Jun  6 21:07:15 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 06 Jun 2006 21:07:15 -0400
Subject: [Rspec-devel] [ANN] RSpec 0.5.5 on Rails
In-Reply-To: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>
References: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>
Message-ID: <448626C3.6010301@rubyforge.org>

aslak hellesoy wrote:
> Hi there!
> 
> I just released RSpec 0.5.5. There are only very minor changes to the
> RSpec core, but the big news is Rails support!
[...]

> rake spec

How do I get "rake spec" to show me format=specdoc?

Jay Levitt


From aslak.hellesoy at gmail.com  Tue Jun  6 21:53:42 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 6 Jun 2006 20:53:42 -0500
Subject: [Rspec-devel] [ANN] RSpec 0.5.5 on Rails
In-Reply-To: <448626C3.6010301@rubyforge.org>
References: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>
	<448626C3.6010301@rubyforge.org>
Message-ID: <8d961d900606061853s79c719c1h6e3e00ba0f3fa1b8@mail.gmail.com>

On 6/6/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> aslak hellesoy wrote:
> > Hi there!
> >
> > I just released RSpec 0.5.5. There are only very minor changes to the
> > RSpec core, but the big news is Rails support!
> [...]
>
> > rake spec
>
> How do I get "rake spec" to show me format=specdoc?
>

You'll have to tweak lib/tasks/rspec.rake

Add more tasks or tweak the existing ones.
Example:
http://rspec.rubyforge.org/tools/rake.html
(use t.spec_opts = ["--format", "specdoc"])

I'll add more stock tasks to rspec.rake in the next release.

Aslak

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

From aslak.hellesoy at gmail.com  Tue Jun  6 21:55:37 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 6 Jun 2006 20:55:37 -0500
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <8a73c7940606061804r5bcb4842w46d6e212ca50900b@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>
	<57c63afe0606061705x12ac70a0o289f988744f7c49e@mail.gmail.com>
	<8a73c7940606061804r5bcb4842w46d6e212ca50900b@mail.gmail.com>
Message-ID: <8d961d900606061855y6acc7be0md67f015118530638@mail.gmail.com>

On 6/6/06, Cuong Tran <cuong.tran at gmail.com> wrote:
>
> I'm just a rspec beginner but I would vote for DOT since it's a bit easier
> on my finger :-)
> My little finger is overwork already.
>

Vote noted, but I think it's more important to please eyes than
fingers. Readability has high importance in RSpec land.

What reads best to you? dots or underscores? Indifferent?

Aslak

>
> On 6/6/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 6/6/06, Lachie < lachiec at gmail.com> wrote:
> > > The dots made me look twice at rSpec in the first place, but it was
> > > more because it was such a novel approach.
> > >
> > > in the end
> > > +1 Underscore
> > >
> >
> > Bear in mind that the initial syntax was underscores. The dots were
> > introduced later in order to make the implementation simpler and more
> > robust. So from an implementation standpoint, I'd prefer to only
> > support dots. From a usability standpoint, I'd like to use
> > underscores. So, since I live on both sides of that divide:
> >
> > +. 5 Dots
> > + .5 Underscores
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From lists-rspec at shopwatch.org  Tue Jun  6 22:28:23 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 06 Jun 2006 22:28:23 -0400
Subject: [Rspec-devel] Rake, recursive directories
In-Reply-To: <8d961d900606061853s79c719c1h6e3e00ba0f3fa1b8@mail.gmail.com>
References: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>	<448626C3.6010301@rubyforge.org>
	<8d961d900606061853s79c719c1h6e3e00ba0f3fa1b8@mail.gmail.com>
Message-ID: <448639C7.40206@rubyforge.org>

>> How do I get "rake spec" to show me format=specdoc?
>>
> 
> You'll have to tweak lib/tasks/rspec.rake

Ah, thanks.. looks like simply running "spec spec/* -f s" is much, much 
faster than launching rake to relaunch ruby.

So I set about trying to add recursive directory support, so that I 
could just type "spec spec -f s", but I can't follow where the file is 
opened.  It looks like it's in tool/command_line.rb, but that's talking 
about source and destination files and dirs, which is confusing in this 
context.  Is translator just an overly-generic pattern being called into 
play, or something else I'm missing?

What I wouldn't give for a proper step-through debugger for Ruby!

Jay


From lists-rspec at shopwatch.org  Tue Jun  6 22:32:21 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 06 Jun 2006 22:32:21 -0400
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <8d961d900606061855y6acc7be0md67f015118530638@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>	<2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>	<57c63afe0606061705x12ac70a0o289f988744f7c49e@mail.gmail.com>	<8a73c7940606061804r5bcb4842w46d6e212ca50900b@mail.gmail.com>
	<8d961d900606061855y6acc7be0md67f015118530638@mail.gmail.com>
Message-ID: <44863AB5.9050708@rubyforge.org>

aslak hellesoy wrote:
> On 6/6/06, Cuong Tran <cuong.tran at gmail.com> wrote:
>> I'm just a rspec beginner but I would vote for DOT since it's a bit easier
>> on my finger :-)
>> My little finger is overwork already.
>>
> 
> Vote noted, but I think it's more important to please eyes than
> fingers. Readability has high importance in RSpec land.
> 
> What reads best to you? dots or underscores? Indifferent?
> 
What exactly are we voting on when we say "underscores"?  Are we saying 
"my_obj.reader.should_be true", or "my_reader_should_be_true"?  I think 
the former actually conveys intent best - take an existing method like 
my_obj.reader, and call the "should_be" test on it.  Neither 
"my.obj.reader.should.be true" nor "my_obj_reader_should_be_true" convey 
that.  So is that a vote for mixed, or is this actually what you mean by 
underscores?

Jay

> Aslak
> 
>> On 6/6/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>>> On 6/6/06, Lachie < lachiec at gmail.com> wrote:
>>>> The dots made me look twice at rSpec in the first place, but it was
>>>> more because it was such a novel approach.
>>>>
>>>> in the end
>>>> +1 Underscore
>>>>
>>> Bear in mind that the initial syntax was underscores. The dots were
>>> introduced later in order to make the implementation simpler and more
>>> robust. So from an implementation standpoint, I'd prefer to only
>>> support dots. From a usability standpoint, I'd like to use
>>> underscores. So, since I live on both sides of that divide:
>>>
>>> +. 5 Dots
>>> + .5 Underscores
>>> _______________________________________________
>>> 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 Keith.Hodges at warwick.ac.uk  Tue Jun  6 22:57:36 2006
From: Keith.Hodges at warwick.ac.uk (Keith Hodges)
Date: Wed, 07 Jun 2006 03:57:36 +0100
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <3DAC1871-8678-4B8B-AEB6-6C6A0947D475@daveastels.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>	<b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
	<3DAC1871-8678-4B8B-AEB6-6C6A0947D475@daveastels.com>
Message-ID: <448640A0.3090900@warwick.ac.uk>

Definitely spaces for me,

Dave,

I am looking forward to the squeak version of sspec

Keith
> //rubyforge.org/mailman/listinfo/rspec-devel
>   


	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html

From aslak.hellesoy at gmail.com  Wed Jun  7 00:04:14 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 6 Jun 2006 23:04:14 -0500
Subject: [Rspec-devel] Rake, recursive directories
In-Reply-To: <448639C7.40206@rubyforge.org>
References: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>
	<448626C3.6010301@rubyforge.org>
	<8d961d900606061853s79c719c1h6e3e00ba0f3fa1b8@mail.gmail.com>
	<448639C7.40206@rubyforge.org>
Message-ID: <8d961d900606062104n3957412ree38b13568311511@mail.gmail.com>

On 6/6/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> >> How do I get "rake spec" to show me format=specdoc?
> >>
> >
> > You'll have to tweak lib/tasks/rspec.rake
>
> Ah, thanks.. looks like simply running "spec spec/* -f s" is much, much
> faster than launching rake to relaunch ruby.
>

rspec already has recursive support

spec spec -f s

> So I set about trying to add recursive directory support, so that I
> could just type "spec spec -f s", but I can't follow where the file is
> opened.  It looks like it's in tool/command_line.rb, but that's talking
> about source and destination files and dirs, which is confusing in this
> context.  Is translator just an overly-generic pattern being called into
> play, or something else I'm missing?
>

the tool_command_line.rb code is only for the test2rspec translator -
a red herring!

aslak

> What I wouldn't give for a proper step-through debugger for Ruby!
>
> Jay
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From cuong.tran at gmail.com  Wed Jun  7 00:24:17 2006
From: cuong.tran at gmail.com (Cuong Tran)
Date: Tue, 6 Jun 2006 23:24:17 -0500
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <8d961d900606061855y6acc7be0md67f015118530638@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>
	<57c63afe0606061705x12ac70a0o289f988744f7c49e@mail.gmail.com>
	<8a73c7940606061804r5bcb4842w46d6e212ca50900b@mail.gmail.com>
	<8d961d900606061855y6acc7be0md67f015118530638@mail.gmail.com>
Message-ID: <8a73c7940606062124u2e65f9d1ib0a3f5822fd9bec2@mail.gmail.com>

Both read the same to me.  That's why I went with ease of typing :-)

On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
> On 6/6/06, Cuong Tran <cuong.tran at gmail.com> wrote:
> >
> > I'm just a rspec beginner but I would vote for DOT since it's a bit
> easier
> > on my finger :-)
> > My little finger is overwork already.
> >
>
> Vote noted, but I think it's more important to please eyes than
> fingers. Readability has high importance in RSpec land.
>
> What reads best to you? dots or underscores? Indifferent?
>
> Aslak
>
> >
> > On 6/6/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 6/6/06, Lachie < lachiec at gmail.com> wrote:
> > > > The dots made me look twice at rSpec in the first place, but it was
> > > > more because it was such a novel approach.
> > > >
> > > > in the end
> > > > +1 Underscore
> > > >
> > >
> > > Bear in mind that the initial syntax was underscores. The dots were
> > > introduced later in order to make the implementation simpler and more
> > > robust. So from an implementation standpoint, I'd prefer to only
> > > support dots. From a usability standpoint, I'd like to use
> > > underscores. So, since I live on both sides of that divide:
> > >
> > > +. 5 Dots
> > > + .5 Underscores
> > > _______________________________________________
> > > Rspec-devel mailing list
> > > Rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> >
> >
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060606/f2fcd62b/attachment-0001.htm 

From aslak.hellesoy at gmail.com  Wed Jun  7 01:32:20 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 7 Jun 2006 00:32:20 -0500
Subject: [Rspec-devel] experimental output tweak
Message-ID: <8d961d900606062232t7a829511ma9337bb41c4ad932@mail.gmail.com>

On Rspec trunk the default output will now look like:

--------------------------
..........................

The dashes are printed before the specs are run, and it represents the
total number of specs. It can be useful if there are many (slow) specs
to see how much is left

I'm not sure I like it though - it's noisy, and specs should be fast,
in which case it's not really needed. But in Rails things tend to be
slow.

Anyhow - the underlying change opens up for better progress reporting
for other reporters, such as Dave's cocoa runner/reporter. I will also
need it in my upcoming port of TDDMate (BDDMate).

If people don't like this for the textual output we can easily remove it.

wdyt?

Aslak

From lists-rspec at shopwatch.org  Wed Jun  7 07:12:52 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Wed, 07 Jun 2006 07:12:52 -0400
Subject: [Rspec-devel] Rake, recursive directories
In-Reply-To: <8d961d900606062104n3957412ree38b13568311511@mail.gmail.com>
References: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>	<448626C3.6010301@rubyforge.org>	<8d961d900606061853s79c719c1h6e3e00ba0f3fa1b8@mail.gmail.com>	<448639C7.40206@rubyforge.org>
	<8d961d900606062104n3957412ree38b13568311511@mail.gmail.com>
Message-ID: <4486B4B4.905@rubyforge.org>

aslak hellesoy wrote:

> rspec already has recursive support
> 
> spec spec -f s

Hmm, not with 5.6, on either Cygwin or Mandrake Linux...

$ spec spec


Finished in 0.0 seconds

0 contexts, 0 specifications, 0 failures

$ spec spec/*

.F.

1)
ExpectationNotMetError in 'The MainController should have more 
specifications'
not enough specs
./spec/controllers/main_controller_spec.rb:13:in `should have more 
specifications'
/usr/lib/ruby/gems/1.8/gems/rspec_generator-0.5.6/lib/rspec_on_rails.rb:33:in 
`run'
/usr/lib/ruby/gems/1.8/gems/rspec_generator-0.5.6/lib/rspec_on_rails.rb:31:in 
`run'

Finished in 0.349 seconds

2 contexts, 3 specifications, 1 failure


I'll file a bug report.

Jay


From dchelimsky at gmail.com  Wed Jun  7 07:15:57 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Jun 2006 07:15:57 -0400
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <44863AB5.9050708@rubyforge.org>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>
	<57c63afe0606061705x12ac70a0o289f988744f7c49e@mail.gmail.com>
	<8a73c7940606061804r5bcb4842w46d6e212ca50900b@mail.gmail.com>
	<8d961d900606061855y6acc7be0md67f015118530638@mail.gmail.com>
	<44863AB5.9050708@rubyforge.org>
Message-ID: <57c63afe0606070415r3c6681e8y5169720dd3727677@mail.gmail.com>

On 6/6/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> What exactly are we voting on when we say "underscores"?  Are we saying
> "my_obj.reader.should_be true", or "my_reader_should_be_true"?  I think
> the former actually conveys intent best - take an existing method like
> my_obj.reader, and call the "should_be" test on it.  Neither
> "my.obj.reader.should.be true" nor "my_obj_reader_should_be_true" convey
> that.  So is that a vote for mixed, or is this actually what you mean by
> underscores?

Jay, it just has to do with the messages you send directly to rspec.
So it's a choice between this:

the_team.should_have_at_least(11).active_players

and this:

the_team.should.have.at.least(11).active_players

where "the_team" is the subject you are specifying, "active_players"
is a collection that it owns and "should_have_at_least" or
"should.have.at.least" is what gets fielded by rspec directly.

RSpec supports both, so the question is not one of functionality -
it's one of documentation. Do we want the docs to sometimes use
"should.equal" and sometimes "should_equal", always "should_equal", or
always "should.equal".

I think it's clear that we don't want mixed. That's just confusing.

From dchelimsky at gmail.com  Wed Jun  7 07:23:44 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Jun 2006 07:23:44 -0400
Subject: [Rspec-devel] experimental output tweak
In-Reply-To: <8d961d900606062232t7a829511ma9337bb41c4ad932@mail.gmail.com>
References: <8d961d900606062232t7a829511ma9337bb41c4ad932@mail.gmail.com>
Message-ID: <57c63afe0606070423ie272e9ep1d975d0f1bf9c60b@mail.gmail.com>

On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On Rspec trunk the default output will now look like:
>
> --------------------------
> ..........................

-1
The underscores are pure noise IMO.

From luke at agileevolved.com  Wed Jun  7 07:45:20 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Wed, 7 Jun 2006 12:45:20 +0100
Subject: [Rspec-devel] experimental output tweak
In-Reply-To: <8d961d900606062232t7a829511ma9337bb41c4ad932@mail.gmail.com>
References: <8d961d900606062232t7a829511ma9337bb41c4ad932@mail.gmail.com>
Message-ID: <19E0C400-DFB6-49C3-B977-A8CBC5AACD78@agileevolved.com>

-1 for me, at least as a default - perhaps better as an option using  
a switch?

Cheers
Luke

On 7 Jun 2006, at 06:32, aslak hellesoy wrote:

> On Rspec trunk the default output will now look like:
>
> --------------------------
> ..........................
>
> The dashes are printed before the specs are run, and it represents the
> total number of specs. It can be useful if there are many (slow) specs
> to see how much is left
>
> I'm not sure I like it though - it's noisy, and specs should be fast,
> in which case it's not really needed. But in Rails things tend to be
> slow.
>
> Anyhow - the underlying change opens up for better progress reporting
> for other reporters, such as Dave's cocoa runner/reporter. I will also
> need it in my upcoming port of TDDMate (BDDMate).
>
> If people don't like this for the textual output we can easily  
> remove it.
>
> wdyt?
>
> Aslak
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dastels at daveastels.com  Wed Jun  7 08:06:35 2006
From: dastels at daveastels.com (David Astels)
Date: Wed, 7 Jun 2006 09:06:35 -0300
Subject: [Rspec-devel] experimental output tweak
In-Reply-To: <8d961d900606062232t7a829511ma9337bb41c4ad932@mail.gmail.com>
References: <8d961d900606062232t7a829511ma9337bb41c4ad932@mail.gmail.com>
Message-ID: <8AC0AF13-6D8F-41C7-9C1F-29FC4DD3954E@daveastels.com>


On 7-Jun-06, at 2:32 AM, aslak hellesoy wrote:

> On Rspec trunk the default output will now look like:
>
> --------------------------
> ..........................
>
> The dashes are printed before the specs are run, and it represents the
> total number of specs. It can be useful if there are many (slow) specs
> to see how much is left
>
> I'm not sure I like it though - it's noisy, and specs should be fast,
> in which case it's not really needed. But in Rails things tend to be
> slow.
>
> Anyhow - the underlying change opens up for better progress reporting
> for other reporters, such as Dave's cocoa runner/reporter. I will also
> need it in my upcoming port of TDDMate (BDDMate).
>
> If people don't like this for the textual output we can easily  
> remove it.

-1

It adds noise without useful information

dave


From lists-rspec at shopwatch.org  Wed Jun  7 08:08:09 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Wed, 07 Jun 2006 08:08:09 -0400
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <57c63afe0606070415r3c6681e8y5169720dd3727677@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>	<2c5e719e0606061654g129e95a7m30eec1ae72596aba@mail.gmail.com>	<57c63afe0606061705x12ac70a0o289f988744f7c49e@mail.gmail.com>	<8a73c7940606061804r5bcb4842w46d6e212ca50900b@mail.gmail.com>	<8d961d900606061855y6acc7be0md67f015118530638@mail.gmail.com>	<44863AB5.9050708@rubyforge.org>
	<57c63afe0606070415r3c6681e8y5169720dd3727677@mail.gmail.com>
Message-ID: <4486C1A9.2050402@rubyforge.org>

David Chelimsky wrote:

> Jay, it just has to do with the messages you send directly to rspec.
> So it's a choice between this:
> 
> the_team.should_have_at_least(11).active_players
> 
> and this:
> 
> the_team.should.have.at.least(11).active_players
> 
> where "the_team" is the subject you are specifying, "active_players"
> is a collection that it owns and "should_have_at_least" or
> "should.have.at.least" is what gets fielded by rspec directly.

Ah, ok.  I wasn't sure if the rspec dot-magic extended to object names, 
method access, etc. as well, so that we might be talking about

the.team.should.have.at.least(11).active.players

or, vice versa (if there were a method "teams.winner")

teams_winner_should_have_at_least(11)_active_players

both of which would be horrible.

I'm +1 on underscores.

Jay

> 
> RSpec supports both, so the question is not one of functionality -
> it's one of documentation. Do we want the docs to sometimes use
> "should.equal" and sometimes "should_equal", always "should_equal", or
> always "should.equal".
> 
> I think it's clear that we don't want mixed. That's just confusing.
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Wed Jun  7 09:24:16 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 7 Jun 2006 08:24:16 -0500
Subject: [Rspec-devel] experimental output tweak
In-Reply-To: <8AC0AF13-6D8F-41C7-9C1F-29FC4DD3954E@daveastels.com>
References: <8d961d900606062232t7a829511ma9337bb41c4ad932@mail.gmail.com>
	<8AC0AF13-6D8F-41C7-9C1F-29FC4DD3954E@daveastels.com>
Message-ID: <8d961d900606070624m68fda512q32dfb2c7f425efee@mail.gmail.com>

On 6/7/06, David Astels <dastels at daveastels.com> wrote:
>
> On 7-Jun-06, at 2:32 AM, aslak hellesoy wrote:
>
> > On Rspec trunk the default output will now look like:
> >
> > --------------------------
> > ..........................
> >

it's gone

> > The dashes are printed before the specs are run, and it represents the
> > total number of specs. It can be useful if there are many (slow) specs
> > to see how much is left
> >
> > I'm not sure I like it though - it's noisy, and specs should be fast,
> > in which case it's not really needed. But in Rails things tend to be
> > slow.
> >
> > Anyhow - the underlying change opens up for better progress reporting
> > for other reporters, such as Dave's cocoa runner/reporter. I will also
> > need it in my upcoming port of TDDMate (BDDMate).
> >
> > If people don't like this for the textual output we can easily
> > remove it.
>
> -1
>
> It adds noise without useful information
>
> dave
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From chad at clearwaterassociates.ca  Wed Jun  7 09:28:47 2006
From: chad at clearwaterassociates.ca (Chad Nantais)
Date: Wed, 7 Jun 2006 09:28:47 -0400
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <448640A0.3090900@warwick.ac.uk>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
	<3DAC1871-8678-4B8B-AEB6-6C6A0947D475@daveastels.com>
	<448640A0.3090900@warwick.ac.uk>
Message-ID: <3de931600606070628u164b7337pd9619b552fee68be@mail.gmail.com>

I would have voted for spaces rather than underscores, had I known it
was an option.

Dave,

I too await the squeak version of sSpec.

Chad

On 6/6/06, Keith Hodges <Keith.Hodges at warwick.ac.uk> wrote:
> Definitely spaces for me,
>
> Dave,
>
> I am looking forward to the squeak version of sspec
>
> Keith
> > //rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
>
>
>
> ___________________________________________________________
> All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
> http://uk.docs.yahoo.com/nowyoucan.html
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Wed Jun  7 10:48:57 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 7 Jun 2006 09:48:57 -0500
Subject: [Rspec-devel] dots vs underscores tally
Message-ID: <8d961d900606070748g5e8df548uf3a94aae69657de6@mail.gmail.com>

So we had a quick vote on whether the RSpec *documentation* should use
dots or underscores. Here are the results so far:

Dots: 3 (Dave, Evgeny, Cuong)
Underscores: 6 (Aslak, Steve, Chad, Michael, Lachie, Jay)
Indifferent: 1 (David)

so_it_looks_like_underscores_are_most_popular

I will:

* Update documentation and examples to use _
* Keep internal Test::Unit tests the way they are (mostly dots)

I just want to stress that this doesn't remove your option to use dots
in *your* specs -
it's just that you won't see it in the documentation (except on one
page where we'll describe that both are possible).

Aslak

From hughes.james at gmail.com  Wed Jun  7 12:30:41 2006
From: hughes.james at gmail.com (James Hughes)
Date: Wed, 7 Jun 2006 09:30:41 -0700
Subject: [Rspec-devel] [ANN] RSpec 0.5.5 on Rails
In-Reply-To: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>
References: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>
Message-ID: <765a2c230606070930h4086e946se4264413a1e75f3f@mail.gmail.com>

On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> I just released RSpec 0.5.5. There are only very minor changes to the
> RSpec core, but the big news is Rails support!

> The Rails support is based on Lachie Cox' contribution from last week
> - it was a Rails plugin. I have now restructured it and packaged it as
> a Rubygem instead (separate from the core Rspec gem).

I thought I'd take this opportunity to introduce myself to the list by
noting that I just created my first project with the gem, and it
worked flawlessly. I've been using Lachie's plugin for the last few
weeks (at work even!) and it's good to have the last few pieces of
infrastucture that the gem provides.

A question, does anyone have a notion of what it would take to get
this working with Zentest (specifically the piece of Zentest that I
use most, autotest)?

jh

-- 
James Hughes
Web application developer
Vancouver, BC

"Developing a coherent political analysis is in many respects
contingent upon an ability to connect one context to another, a
process not dissimilar to playing the kid's game of dot-to-dot."
 - Ward Churchill, from '"A Government of Laws"?'

From dastels at daveastels.com  Wed Jun  7 12:52:30 2006
From: dastels at daveastels.com (David Astels)
Date: Wed, 7 Jun 2006 13:52:30 -0300
Subject: [Rspec-devel] [ANN] RSpec 0.5.5 on Rails
In-Reply-To: <765a2c230606070930h4086e946se4264413a1e75f3f@mail.gmail.com>
References: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>
	<765a2c230606070930h4086e946se4264413a1e75f3f@mail.gmail.com>
Message-ID: <7D54F8D7-A627-440E-B0EE-C0366EFE122C@daveastels.com>


On 7-Jun-06, at 1:30 PM, James Hughes wrote:

> A question, does anyone have a notion of what it would take to get
> this working with Zentest (specifically the piece of Zentest that I
> use most, autotest)?

Not really.. but I talked to Ryan Davis about just that... so people  
are thinking about it.

Dave


From aslak.hellesoy at gmail.com  Wed Jun  7 12:59:26 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 7 Jun 2006 11:59:26 -0500
Subject: [Rspec-devel] [ANN] RSpec 0.5.5 on Rails
In-Reply-To: <765a2c230606070930h4086e946se4264413a1e75f3f@mail.gmail.com>
References: <8d961d900606061226v5a730d4dte5e3ccaf619006d4@mail.gmail.com>
	<765a2c230606070930h4086e946se4264413a1e75f3f@mail.gmail.com>
Message-ID: <8d961d900606070959r12da3f07t641c4a4f79b05cb1@mail.gmail.com>

On 6/7/06, James Hughes <hughes.james at gmail.com> wrote:
> On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > I just released RSpec 0.5.5. There are only very minor changes to the
> > RSpec core, but the big news is Rails support!
>
> > The Rails support is based on Lachie Cox' contribution from last week
> > - it was a Rails plugin. I have now restructured it and packaged it as
> > a Rubygem instead (separate from the core Rspec gem).
>
> I thought I'd take this opportunity to introduce myself to the list by
> noting that I just created my first project with the gem, and it
> worked flawlessly.

I suppose you mean the rspec_generator gem.
I'm glad it's working for you!

> I've been using Lachie's plugin for the last few
> weeks (at work even!) and it's good to have the last few pieces of
> infrastucture that the gem provides.
>
> A question, does anyone have a notion of what it would take to get
> this working with Zentest (specifically the piece of Zentest that I
> use most, autotest)?
>

Looking at ZenTest's Autotest - it looks like the Autotest class and
RailsAutotest classes can be extended/modified so that it looks for
(and executes) RSpec specs rather than Test::Unit tests.

If we (RSpec team) do it, it will probably be a lot of duplication - I
think it would be better if support for RSpec was implemented in
ZenTest itself. -Or at least that ZenTest was refactored to support
commandline-specified plugins (and we could write the RSpec plugin for
it)

I have CC'ed Ryan Davis - Eric Hodel is already on this list (the ZenTest guys)

Aslak

> jh
>
> --
> James Hughes
> Web application developer
> Vancouver, BC
>
> "Developing a coherent political analysis is in many respects
> contingent upon an ability to connect one context to another, a
> process not dissimilar to playing the kid's game of dot-to-dot."
>  - Ward Churchill, from '"A Government of Laws"?'
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Wed Jun  7 17:54:14 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Jun 2006 17:54:14 -0400
Subject: [Rspec-devel] dots vs underscores tally
In-Reply-To: <8d961d900606070748g5e8df548uf3a94aae69657de6@mail.gmail.com>
References: <8d961d900606070748g5e8df548uf3a94aae69657de6@mail.gmail.com>
Message-ID: <57c63afe0606071454p229c5b95x713af2e36dddf45c@mail.gmail.com>

On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> I will:
> * Keep internal Test::Unit tests the way they are (mostly dots)

My thinking is that if we're committed to underscores, then that's
what we should support. The tests should change to use underscores.
I'll be glad to change them myself.

Doing this will give us more freedom in implementation. For example,
right now the HaveHelper has methods "at" and "least" and "most". If
we abandon official dot-support, there's no reason we can't change
that to "at_least" and "at_most", at which point the code speaks a bit
better IMO.

Thoughts?

David

From aslak.hellesoy at gmail.com  Wed Jun  7 18:08:26 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 7 Jun 2006 17:08:26 -0500
Subject: [Rspec-devel] dots vs underscores tally
In-Reply-To: <57c63afe0606071454p229c5b95x713af2e36dddf45c@mail.gmail.com>
References: <8d961d900606070748g5e8df548uf3a94aae69657de6@mail.gmail.com>
	<57c63afe0606071454p229c5b95x713af2e36dddf45c@mail.gmail.com>
Message-ID: <8d961d900606071508p6ee243e0r521270d25e27ffa7@mail.gmail.com>

On 6/7/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > I will:
> > * Keep internal Test::Unit tests the way they are (mostly dots)
>
> My thinking is that if we're committed to underscores, then that's
> what we should support. The tests should change to use underscores.
> I'll be glad to change them myself.
>

I have already changed all the docs and the tests, except the ones
that test the chaining of helpers. They still use dots.

> Doing this will give us more freedom in implementation. For example,
> right now the HaveHelper has methods "at" and "least" and "most". If
> we abandon official dot-support, there's no reason we can't change
> that to "at_least" and "at_most", at which point the code speaks a bit
> better IMO.
>
> Thoughts?
>

I think the internal implementation with chained helper is great, so I
hope you don't
want to change that.

I suppose we could implement at_least and at_most and tweak sugar.rb
to account for those special cases.

Aslak

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

From dchelimsky at gmail.com  Wed Jun  7 18:14:01 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Jun 2006 18:14:01 -0400
Subject: [Rspec-devel] dots vs underscores tally
In-Reply-To: <8d961d900606071508p6ee243e0r521270d25e27ffa7@mail.gmail.com>
References: <8d961d900606070748g5e8df548uf3a94aae69657de6@mail.gmail.com>
	<57c63afe0606071454p229c5b95x713af2e36dddf45c@mail.gmail.com>
	<8d961d900606071508p6ee243e0r521270d25e27ffa7@mail.gmail.com>
Message-ID: <57c63afe0606071514x400289ffl363f9a78d991e951@mail.gmail.com>

On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/7/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > My thinking is that if we're committed to underscores, then that's
> > what we should support. The tests should change to use underscores.
> > I'll be glad to change them myself.
>
> > Doing this will give us more freedom in implementation. For example,
> > right now the HaveHelper has methods "at" and "least" and "most". If
> > we abandon official dot-support, there's no reason we can't change
> > that to "at_least" and "at_most", at which point the code speaks a bit
> > better IMO.
> >
> > Thoughts?
> >
>
> I think the internal implementation with chained helper is great, so I
> hope you don't
> want to change that.

Not entirely. The chained helper is what gives us arbitrary
predicates, reduces the changes to Object, etc. I'm just saying that
for specific cases it might simplify the code to use "_".

>
> I suppose we could implement at_least and at_most and tweak sugar.rb
> to account for those special cases.

If sugar needs tweaking to handle these, then I withdraw my suggestion
(vis a vis changing implementation).

However, that's based on rspec as it is today. I still think that with
a long rspec life in mind, that we're shooting ourselves in our future
feet by supporting both "_" and "."

>
> Aslak

From aslak.hellesoy at gmail.com  Wed Jun  7 18:29:00 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 7 Jun 2006 17:29:00 -0500
Subject: [Rspec-devel] test2rspec based on RubyToRuby/ParseTree/RubyInline
Message-ID: <8d961d900606071529mc7784a8t5c4d9e1076288eec@mail.gmail.com>

Hi there,

The current test2rspec is based on pattern matching and it's very flaky.

I have experimented with a new translator based on RubyToRuby:

RubyToRuby (http://blog.zenspider.com/archives/2005/02/rubytoruby.html
and a successor - http://dark.fhtr.org/ruby2ruby.rb)
ParseTree - used by RubyToRuby (http://rubyforge.org/projects/parsetree/)
RubyInline - used by ParseTree (http://rubyforge.org/projects/rubyinline/)

All of this is MIT licenced (except RubyToRuby which doesn't appear to
have a licence - I suppose it's in the public domain)

I'm not 100% done yet, but it's looking promising.

RubyInline won't work on windows (afaik), so that's a drawback, but on
the flip side I think
that basing the translator on this stuff will result in much better
translations.
And they only have to be done once anyway.

Any objections if I check that in tomorrow and replace the old translator?

Aslak

From aslak.hellesoy at gmail.com  Wed Jun  7 18:30:18 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 7 Jun 2006 17:30:18 -0500
Subject: [Rspec-devel] dots vs underscores tally
In-Reply-To: <57c63afe0606071514x400289ffl363f9a78d991e951@mail.gmail.com>
References: <8d961d900606070748g5e8df548uf3a94aae69657de6@mail.gmail.com>
	<57c63afe0606071454p229c5b95x713af2e36dddf45c@mail.gmail.com>
	<8d961d900606071508p6ee243e0r521270d25e27ffa7@mail.gmail.com>
	<57c63afe0606071514x400289ffl363f9a78d991e951@mail.gmail.com>
Message-ID: <8d961d900606071530x67c39368y19e7dd2ddd05aa7f@mail.gmail.com>

On 6/7/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 6/7/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > My thinking is that if we're committed to underscores, then that's
> > > what we should support. The tests should change to use underscores.
> > > I'll be glad to change them myself.
> >
> > > Doing this will give us more freedom in implementation. For example,
> > > right now the HaveHelper has methods "at" and "least" and "most". If
> > > we abandon official dot-support, there's no reason we can't change
> > > that to "at_least" and "at_most", at which point the code speaks a bit
> > > better IMO.
> > >
> > > Thoughts?
> > >
> >
> > I think the internal implementation with chained helper is great, so I
> > hope you don't
> > want to change that.
>
> Not entirely. The chained helper is what gives us arbitrary
> predicates, reduces the changes to Object, etc. I'm just saying that
> for specific cases it might simplify the code to use "_".
>
> >
> > I suppose we could implement at_least and at_most and tweak sugar.rb
> > to account for those special cases.
>
> If sugar needs tweaking to handle these, then I withdraw my suggestion
> (vis a vis changing implementation).
>

I'm not sure it will need tweaking. And so what if it does?

> However, that's based on rspec as it is today. I still think that with
> a long rspec life in mind, that we're shooting ourselves in our future
> feet by supporting both "_" and "."
>

Agree

Aslak

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

From dchelimsky at gmail.com  Wed Jun  7 18:30:43 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Jun 2006 18:30:43 -0400
Subject: [Rspec-devel] test2rspec based on
	RubyToRuby/ParseTree/RubyInline
In-Reply-To: <8d961d900606071529mc7784a8t5c4d9e1076288eec@mail.gmail.com>
References: <8d961d900606071529mc7784a8t5c4d9e1076288eec@mail.gmail.com>
Message-ID: <57c63afe0606071530o4539b5c8yb376af24ea6c67a1@mail.gmail.com>

On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> Hi there,
>
> The current test2rspec is based on pattern matching and it's very flaky.
>
> I have experimented with a new translator based on RubyToRuby:
>
> RubyToRuby (http://blog.zenspider.com/archives/2005/02/rubytoruby.html
> and a successor - http://dark.fhtr.org/ruby2ruby.rb)
> ParseTree - used by RubyToRuby (http://rubyforge.org/projects/parsetree/)
> RubyInline - used by ParseTree (http://rubyforge.org/projects/rubyinline/)
>
> All of this is MIT licenced (except RubyToRuby which doesn't appear to
> have a licence - I suppose it's in the public domain)
>
> I'm not 100% done yet, but it's looking promising.
>
> RubyInline won't work on windows (afaik), so that's a drawback, but on
> the flip side I think
> that basing the translator on this stuff will result in much better
> translations.
> And they only have to be done once anyway.
>
> Any objections if I check that in tomorrow and replace the old translator?

No problem as long as you buy me a mac laptop first ;)

From dchelimsky at gmail.com  Wed Jun  7 18:36:01 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Jun 2006 18:36:01 -0400
Subject: [Rspec-devel] dots vs underscores tally
In-Reply-To: <8d961d900606071530x67c39368y19e7dd2ddd05aa7f@mail.gmail.com>
References: <8d961d900606070748g5e8df548uf3a94aae69657de6@mail.gmail.com>
	<57c63afe0606071454p229c5b95x713af2e36dddf45c@mail.gmail.com>
	<8d961d900606071508p6ee243e0r521270d25e27ffa7@mail.gmail.com>
	<57c63afe0606071514x400289ffl363f9a78d991e951@mail.gmail.com>
	<8d961d900606071530x67c39368y19e7dd2ddd05aa7f@mail.gmail.com>
Message-ID: <57c63afe0606071536l40c7d6f4ue50b2b70cf44f45b@mail.gmail.com>

On 6/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > If sugar needs tweaking to handle these, then I withdraw my suggestion
> > (vis a vis changing implementation).
> >
>
> I'm not sure it will need tweaking. And so what if it does?

Why gum up Sugar to clean up HaveHelper?

From evgeny.zislis at gmail.com  Thu Jun  8 09:36:39 2006
From: evgeny.zislis at gmail.com (Evgeny)
Date: Thu, 8 Jun 2006 16:36:39 +0300
Subject: [Rspec-devel] Runners and compatibility
Message-ID: <b6840c770606080636y7d1975c3hc9a4d44ab88b9fb6@mail.gmail.com>

Greetings All,



Is there some way to use the Test::Unit runner that exists for eclipse
(or for any other platform for that matter, like Gtk/Qt/etc..) and
magick rspec to run with that?

and if not - is there a plan to do an eclipse runner, any is there
someone working on it somewhere?



Regards,

Evgeny.

From dastels at daveastels.com  Thu Jun  8 09:49:37 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 8 Jun 2006 10:49:37 -0300
Subject: [Rspec-devel] Runners and compatibility
In-Reply-To: <b6840c770606080636y7d1975c3hc9a4d44ab88b9fb6@mail.gmail.com>
References: <b6840c770606080636y7d1975c3hc9a4d44ab88b9fb6@mail.gmail.com>
Message-ID: <E001BBFF-8059-4755-9131-137583DC0202@daveastels.com>


On 8-Jun-06, at 10:36 AM, Evgeny wrote:

> and if not - is there a plan to do an eclipse runner, any is there
> someone working on it somewhere?

Kyle and I had talked briefly about RadRails support for rSpec.

That was in April, I haven't heard anything more.

Dave


From aslak.hellesoy at gmail.com  Thu Jun  8 10:14:04 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 8 Jun 2006 09:14:04 -0500
Subject: [Rspec-devel] Runners and compatibility
In-Reply-To: <b6840c770606080636y7d1975c3hc9a4d44ab88b9fb6@mail.gmail.com>
References: <b6840c770606080636y7d1975c3hc9a4d44ab88b9fb6@mail.gmail.com>
Message-ID: <8d961d900606080714x4d2f2829mbb6ad790ffc8a7da@mail.gmail.com>

On 6/8/06, Evgeny <evgeny.zislis at gmail.com> wrote:
> Greetings All,
>
>
>
> Is there some way to use the Test::Unit runner that exists for eclipse
> (or for any other platform for that matter, like Gtk/Qt/etc..) and
> magick rspec to run with that?
>

Unfortunately not at the moment.

RSpec's spec commandline interface is different from Test::Unit's, and
so is the output format. (RSpec tweaks backtraces to make them more
human-readable, and this might confuse a program parsing it - such as
the eclipse runner). I'm not familiar with the eclipse runner's
internals though.

If someone wants to develop a Test::Unit wrapper it would be great.
This would consist of:
1) A secondary commandline with an interface similar to Test::Unit's
2) Any tweaks necessary to provide output similar to Test::Unit's

Point 2 *might* require us to develop a plugin interface similar to
Test::Unit's plugin interface. Something that allows RSpec to use
drop-in implementations of Test::Unit::UI::Console::TestRunner =>
http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/classes/Test/Unit/UI/Console/TestRunner.html

Aslak

> and if not - is there a plan to do an eclipse runner, any is there
> someone working on it somewhere?
>

We don't really make a lot of plans - we develop new features as we
need them (we meaning the RSpec team). We'd be happy to accept patches
though.

Aslak

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

From lachiec at gmail.com  Thu Jun  8 22:16:39 2006
From: lachiec at gmail.com (Lachie)
Date: Fri, 9 Jun 2006 12:16:39 +1000
Subject: [Rspec-devel] Trouble with the latest gems under windows
Message-ID: <2c5e719e0606081916n54f6502fo3785f73aa8de82a7@mail.gmail.com>

I'm having trouble with the latest gems

It works fine on linux:
$ rspec --remote -v '0.5.7'

But under windows:
( >ruby -v
ruby 1.8.2 (2004-12-25) [i386-mswin32]
okay, so i should upgrade that, but still...)

>gem install rspec --remote -v '0.5.7'
>"c:\ruby\bin\ruby.exe" "c:\ruby\bin\gem" install rspec -v '
0.5.7'
Attempting local installation of 'rspec'
Local gem file not found: rspec*.gem
Attempting remote installation of 'rspec'
ERROR:  While executing gem ... (Zlib::BufError)
    buffer error

# to prove 0.5.6 still installs ok:
>gem install rspec --remote -v '0.5.6'
>"c:\ruby\bin\ruby.exe" "c:\ruby\bin\gem" install rspec -v '
0.5.6'
Attempting local installation of 'rspec'
Local gem file not found: rspec*.gem
Attempting remote installation of 'rspec'
Successfully installed rspec-0.5.6
Installing RDoc documentation for rspec-0.5.6...

any ideas?
thanks,
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From chad at clearwaterassociates.ca  Thu Jun  8 22:26:18 2006
From: chad at clearwaterassociates.ca (Chad Nantais)
Date: Thu, 8 Jun 2006 22:26:18 -0400
Subject: [Rspec-devel] Trouble with the latest gems under windows
In-Reply-To: <2c5e719e0606081916n54f6502fo3785f73aa8de82a7@mail.gmail.com>
References: <2c5e719e0606081916n54f6502fo3785f73aa8de82a7@mail.gmail.com>
Message-ID: <3de931600606081926i172aedffvddfad96228be99f1@mail.gmail.com>

I also got that error on Windows while trying to update my rspec gem
from 0.5.5 to 0.5.7.  I found no solution yet.

I am running the same version of Ruby as Lachie.

Chad

On 6/8/06, Lachie <lachiec at gmail.com> wrote:
> I'm having trouble with the latest gems
>
> It works fine on linux:
> $ rspec --remote -v '0.5.7'
>
> But under windows:
> ( >ruby -v
> ruby 1.8.2 (2004-12-25) [i386-mswin32]
> okay, so i should upgrade that, but still...)
>
> >gem install rspec --remote -v '0.5.7'
> >"c:\ruby\bin\ruby.exe" "c:\ruby\bin\gem" install rspec -v '
> 0.5.7'
> Attempting local installation of 'rspec'
> Local gem file not found: rspec*.gem
> Attempting remote installation of 'rspec'
> ERROR:  While executing gem ... (Zlib::BufError)
>     buffer error
>
> # to prove 0.5.6 still installs ok:
> >gem install rspec --remote -v '0.5.6'
> >"c:\ruby\bin\ruby.exe" "c:\ruby\bin\gem" install rspec -v '
> 0.5.6'
> Attempting local installation of 'rspec'
> Local gem file not found: rspec*.gem
> Attempting remote installation of 'rspec'
> Successfully installed rspec-0.5.6
> Installing RDoc documentation for rspec-0.5.6...
>
> any ideas?
> thanks,
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Fri Jun  9 00:28:01 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 8 Jun 2006 23:28:01 -0500
Subject: [Rspec-devel] Trouble with the latest gems under windows
In-Reply-To: <3de931600606081926i172aedffvddfad96228be99f1@mail.gmail.com>
References: <2c5e719e0606081916n54f6502fo3785f73aa8de82a7@mail.gmail.com>
	<3de931600606081926i172aedffvddfad96228be99f1@mail.gmail.com>
Message-ID: <8d961d900606082128v56b810c9s44bd78d58de99c5d@mail.gmail.com>

On 6/8/06, Chad Nantais <chad at clearwaterassociates.ca> wrote:
> I also got that error on Windows while trying to update my rspec gem
> from 0.5.5 to 0.5.7.  I found no solution yet.
>
> I am running the same version of Ruby as Lachie.
>

Looks like it's corrupt.
I'll upload a new one tomorrow.
0.5.6 should be ok

Sorry for the inconvenience,

Aslak

> Chad
>
> On 6/8/06, Lachie <lachiec at gmail.com> wrote:
> > I'm having trouble with the latest gems
> >
> > It works fine on linux:
> > $ rspec --remote -v '0.5.7'
> >
> > But under windows:
> > ( >ruby -v
> > ruby 1.8.2 (2004-12-25) [i386-mswin32]
> > okay, so i should upgrade that, but still...)
> >
> > >gem install rspec --remote -v '0.5.7'
> > >"c:\ruby\bin\ruby.exe" "c:\ruby\bin\gem" install rspec -v '
> > 0.5.7'
> > Attempting local installation of 'rspec'
> > Local gem file not found: rspec*.gem
> > Attempting remote installation of 'rspec'
> > ERROR:  While executing gem ... (Zlib::BufError)
> >     buffer error
> >
> > # to prove 0.5.6 still installs ok:
> > >gem install rspec --remote -v '0.5.6'
> > >"c:\ruby\bin\ruby.exe" "c:\ruby\bin\gem" install rspec -v '
> > 0.5.6'
> > Attempting local installation of 'rspec'
> > Local gem file not found: rspec*.gem
> > Attempting remote installation of 'rspec'
> > Successfully installed rspec-0.5.6
> > Installing RDoc documentation for rspec-0.5.6...
> >
> > any ideas?
> > thanks,
> > Lachie
> > http://lachie.info/
> > http://www.flickr.com/photos/lachie/
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Fri Jun  9 15:17:02 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 9 Jun 2006 14:17:02 -0500
Subject: [Rspec-devel] [ANN] RSpec 0.5.8 released - new test2spec tool
Message-ID: <8d961d900606091217y25972413ka868c8aa51157ddf@mail.gmail.com>

I've just released 0.5.8. Release notes:

This release features a new Test::Unit to RSpec translation tool.
Also note that the RubyGem of the previous release (0.5.7) was corrupt.
We're close to being able to translate all of RSpec's own Test::Unit
tests and have them run successfully!

Please play with test2spec - it should be much better than the previous one!
More info here: http://rspec.rubyforge.org/tools/test2spec.html (I
know, it needs some CSS love)

On note about the gem - It seems like it takes a while for the gem to
rsync to the various RubyForge mirrors. If the gem command can't find
0.5.8, download the gem manually from the website and install it with
gem install path/to/rspec-0.5.8.gem. Hopefully this won't last long.

Cheers,
Aslak

From deanmao at gmail.com  Fri Jun  9 16:24:30 2006
From: deanmao at gmail.com (Dean Mao)
Date: Fri, 9 Jun 2006 16:24:30 -0400
Subject: [Rspec-devel] [ANN] RSpec 0.5.8 released - new test2spec tool
In-Reply-To: <8d961d900606091217y25972413ka868c8aa51157ddf@mail.gmail.com>
References: <8d961d900606091217y25972413ka868c8aa51157ddf@mail.gmail.com>
Message-ID: <5ad0c3de0606091324nad5117ax7149573900615659@mail.gmail.com>

great stuff!

On 6/9/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> I've just released 0.5.8. Release notes:
>
> This release features a new Test::Unit to RSpec translation tool.
> Also note that the RubyGem of the previous release (0.5.7) was corrupt.
> We're close to being able to translate all of RSpec's own Test::Unit
> tests and have them run successfully!
>
> Please play with test2spec - it should be much better than the previous one!
> More info here: http://rspec.rubyforge.org/tools/test2spec.html (I
> know, it needs some CSS love)
>
> On note about the gem - It seems like it takes a while for the gem to
> rsync to the various RubyForge mirrors. If the gem command can't find
> 0.5.8, download the gem manually from the website and install it with
> gem install path/to/rspec-0.5.8.gem. Hopefully this won't last long.
>
> Cheers,
> Aslak
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Fri Jun  9 18:08:26 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 9 Jun 2006 17:08:26 -0500
Subject: [Rspec-devel] contexts in reporting
Message-ID: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>

We're thinking of changing the last line of command line output from this:

38 contexts, 228 specifications, 1 failure

to this:

228 specifications, 1 failure

The thinking is that the number of contexts is not very useful
information, so really it's just noise. Anyone think differently?

From itsme213 at hotmail.com  Fri Jun  9 18:17:21 2006
From: itsme213 at hotmail.com (itsme213)
Date: Fri, 9 Jun 2006 17:17:21 -0500
Subject: [Rspec-devel] use case for:  setup_once, teardown_once
Message-ID: <BAY108-DAV69C3BE3A3A35FD5DF53FA99880@phx.gbl>

Bump.

> In this case I was actually using spec to specify some explicit 
> requirements about the (remote) results of a (remote) deployment, to say 
> things like:
>
> - the remote directory structure should satisfy ...
> - remote file time stamps should be ...
> - remote access controls should be ...
>
> How would mocks help with this? Or is this not an appropriate thing to 
> specify?

A bit more generally, if my tests are closer to integration or acceptance 
tests than unit tests (where my guess is one should test the actual 
assemblage without mocking of in-scope parts):

 - would it be appropriate to be testing expensive/slow things?
 - would it be reasonable to want to not repeat setup costs for each test?

Thanks.

From itsme213 at hotmail.com  Fri Jun  9 18:27:33 2006
From: itsme213 at hotmail.com (itsme213)
Date: Fri, 9 Jun 2006 17:27:33 -0500
Subject: [Rspec-devel] contexts in reporting
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>
Message-ID: <BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl>

> 38 contexts, 228 specifications, 1 failure
>
> to this:
>
> 228 specifications, 1 failure

+1

But ... it would also be nice to have a 'verbose' mode in which the "..." 
are interleaved with the corresponding context + spec text, with an 
indicator of each "should_...". Output might look like:

context 1
  spec 1 .....
  spec 2 ..
  spec 3 .....
  spec 4
context 2
  spec 5 .

I am showing a "." for each "should", as I think in verbose mode this would 
be better than just a "." for each spec including assertion-less specs e.g. 
it would shows specs (spec 4) that pass simply because they have no 
assertions (e.g. if not in strictly test-first mode).


From aslak.hellesoy at gmail.com  Fri Jun  9 19:12:39 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 9 Jun 2006 18:12:39 -0500
Subject: [Rspec-devel] contexts in reporting
In-Reply-To: <BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl>
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>
	<BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl>
Message-ID: <8d961d900606091612r2253d125r9e18dbeff05023ae@mail.gmail.com>

On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> > 38 contexts, 228 specifications, 1 failure
> >
> > to this:
> >
> > 228 specifications, 1 failure
>
> +1
>
> But ... it would also be nice to have a 'verbose' mode in which the "..."
> are interleaved with the corresponding context + spec text, with an
> indicator of each "should_...". Output might look like:
>
> context 1
>   spec 1 .....
>   spec 2 ..
>   spec 3 .....
>   spec 4
> context 2
>   spec 5 .
>
> I am showing a "." for each "should", as I think in verbose mode this would
> be better than just a "." for each spec including assertion-less specs e.g.
> it would shows specs (spec 4) that pass simply because they have no
> assertions (e.g. if not in strictly test-first mode).
>

I don't see the usefulness in outputting a dot for each should_*
What's the value of that feature?

Aslak

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

From aslak.hellesoy at gmail.com  Fri Jun  9 19:18:34 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 9 Jun 2006 18:18:34 -0500
Subject: [Rspec-devel] use case for: setup_once, teardown_once
In-Reply-To: <BAY108-DAV69C3BE3A3A35FD5DF53FA99880@phx.gbl>
References: <BAY108-DAV69C3BE3A3A35FD5DF53FA99880@phx.gbl>
Message-ID: <8d961d900606091618v6f9fc10dl95501379e78db8bd@mail.gmail.com>

On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> Bump.
>
> > In this case I was actually using spec to specify some explicit
> > requirements about the (remote) results of a (remote) deployment, to say
> > things like:
> >
> > - the remote directory structure should satisfy ...
> > - remote file time stamps should be ...
> > - remote access controls should be ...
> >
> > How would mocks help with this? Or is this not an appropriate thing to
> > specify?
>
> A bit more generally, if my tests are closer to integration or acceptance
> tests than unit tests (where my guess is one should test the actual
> assemblage without mocking of in-scope parts):
>
>  - would it be appropriate to be testing expensive/slow things?

Yes, but you should isolate slow code in separate classes and have a
separate set of specs for those classes only.

You should be able to run (superfast) specs for 90% of your code.
You'll run the fast suite often and the slow suite less often.

This means that 90% of your code shouldn't depend directly on the remaining 10%
of your code that _is_ slow (i.e. the code that does I/O and Thread stuff).

This is where you should be able to use mocks for the expensive stuff,
when running specs for the remaining 10%.

>  - would it be reasonable to want to not repeat setup costs for each test?
>

If you isolate the expensive stuff, it won't slow down the rest - so
it's less important.

Aslak

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

From dchelimsky at gmail.com  Fri Jun  9 19:33:49 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 9 Jun 2006 18:33:49 -0500
Subject: [Rspec-devel] assert_template
Message-ID: <57c63afe0606091633n3c86a904i62b24e26a8096f01@mail.gmail.com>

Lachie,

How do you handle the following w/ the rails plugin?

assert_redirected_to
assert_template
assert_tag

From evgeny.zislis at gmail.com  Fri Jun  9 21:28:54 2006
From: evgeny.zislis at gmail.com (Evgeny)
Date: Sat, 10 Jun 2006 04:28:54 +0300
Subject: [Rspec-devel] Nested contexts
Message-ID: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>

Actually the subject sais it all, but i'll repeat "Nested contexts".
AFAIK it does not exist in the current version, and in the democratic
spirit of this list I would like to ask for a poll.

All in favor : +1
All against : -1


Regards,

Evgeny


PS: Okay okay, for those who dont understand what I'm talking about
I'll give a short example.

context "This is the first context"
   setup
     # some things to do for the first context
   end

   context "this is actually a subcontext for the first one"
      setup
         # things that will only be setup in this subcontext
      end
   end
   context "this is the second subcontext"
      setup
         # this has a different setup, but its also empty....
      end
   end
end

From dastels at daveastels.com  Fri Jun  9 21:56:25 2006
From: dastels at daveastels.com (David Astels)
Date: Fri, 9 Jun 2006 22:56:25 -0300
Subject: [Rspec-devel] contexts in reporting
In-Reply-To: <8d961d900606091612r2253d125r9e18dbeff05023ae@mail.gmail.com>
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>
	<BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl>
	<8d961d900606091612r2253d125r9e18dbeff05023ae@mail.gmail.com>
Message-ID: <CF68E270-BECC-4985-980E-6CF9AFCD8A43@daveastels.com>


On 9-Jun-06, at 8:12 PM, aslak hellesoy wrote:

> I don't see the usefulness in outputting a dot for each should_*

I concur.

Dave


From dastels at daveastels.com  Fri Jun  9 21:59:08 2006
From: dastels at daveastels.com (David Astels)
Date: Fri, 9 Jun 2006 22:59:08 -0300
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
Message-ID: <87047946-19B0-4DAA-87B2-17B6011E5656@daveastels.com>


On 9-Jun-06, at 10:28 PM, Evgeny wrote:

> Actually the subject sais it all, but i'll repeat "Nested contexts".
> AFAIK it does not exist in the current version, and in the democratic
> spirit of this list I would like to ask for a poll.
>
> All in favor : +1
> All against : -1

-1
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060609/e6eb4936/attachment.htm 

From dchelimsky at gmail.com  Fri Jun  9 22:01:01 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 9 Jun 2006 21:01:01 -0500
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
Message-ID: <57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>

On 6/9/06, Evgeny <evgeny.zislis at gmail.com> wrote:
> Actually the subject sais it all, but i'll repeat "Nested contexts".
> AFAIK it does not exist in the current version, and in the democratic
> spirit of this list I would like to ask for a poll.
>
> All in favor : +1
> All against : -1
>
>
> Regards,
>
> Evgeny
>
>
> PS: Okay okay, for those who dont understand what I'm talking about
> I'll give a short example.
>
> context "This is the first context"
>    setup
>      # some things to do for the first context
>    end
>
>    context "this is actually a subcontext for the first one"
>       setup
>          # things that will only be setup in this subcontext
>       end
>    end
>    context "this is the second subcontext"
>       setup
>          # this has a different setup, but its also empty....
>       end
>    end
> end

-1 for the time being

One of the reasons BDD exists is because people doing TDD have been
writing test structures that are very difficult to understand and
therefore less valuable. Structures like nested contexts are going to
lead to degredation in clarity, and we have to weigh the costs of some
duplication against the costs of unclear specs.

I do think that we'll have to address the duplication issue at one
point, but I also think we need more time to evaluate the REAL effects
of different types of duplication in specs, in the context of BDD,
before we introduce new constructs into rspec.

That's my 2 cents.

But, admittedly, just one vote :)

From dchelimsky at gmail.com  Fri Jun  9 22:13:26 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 9 Jun 2006 21:13:26 -0500
Subject: [Rspec-devel] contexts in reporting
In-Reply-To: <CF68E270-BECC-4985-980E-6CF9AFCD8A43@daveastels.com>
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>
	<BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl>
	<8d961d900606091612r2253d125r9e18dbeff05023ae@mail.gmail.com>
	<CF68E270-BECC-4985-980E-6CF9AFCD8A43@daveastels.com>
Message-ID: <57c63afe0606091913k5de4715cg804d5b5319b76ee2@mail.gmail.com>

On 6/9/06, David Astels <dastels at daveastels.com> wrote:
>
> On 9-Jun-06, at 8:12 PM, aslak hellesoy wrote:
>
> > I don't see the usefulness in outputting a dot for each should_*
>
> I concur.

I concur as well, though I do see value in reporting specs with zero
shoulds to expose holes in coverage. The question is how much value?
Right now, specs and shoulds don't know each other, and I suspect
introducing them would be costly.

From lachiec at gmail.com  Fri Jun  9 23:01:21 2006
From: lachiec at gmail.com (Lachie)
Date: Sat, 10 Jun 2006 13:01:21 +1000
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
Message-ID: <2c5e719e0606092001w3bc1e7aey6bc7a8ccae16f6e@mail.gmail.com>

-1

but I'd like to hear about what problem they'd be solving...

On 6/10/06, Evgeny <evgeny.zislis at gmail.com> wrote:
> Actually the subject sais it all, but i'll repeat "Nested contexts".
> AFAIK it does not exist in the current version, and in the democratic
> spirit of this list I would like to ask for a poll.
>
> All in favor : +1
> All against : -1
>
>
> Regards,
>
> Evgeny
>
>
> PS: Okay okay, for those who dont understand what I'm talking about
> I'll give a short example.
>
> context "This is the first context"
>    setup
>      # some things to do for the first context
>    end
>
>    context "this is actually a subcontext for the first one"
>       setup
>          # things that will only be setup in this subcontext
>       end
>    end
>    context "this is the second subcontext"
>       setup
>          # this has a different setup, but its also empty....
>       end
>    end
> end
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From lachiec at gmail.com  Fri Jun  9 23:10:41 2006
From: lachiec at gmail.com (Lachie)
Date: Sat, 10 Jun 2006 13:10:41 +1000
Subject: [Rspec-devel] contexts in reporting
In-Reply-To: <57c63afe0606091913k5de4715cg804d5b5319b76ee2@mail.gmail.com>
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>
	<BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl>
	<8d961d900606091612r2253d125r9e18dbeff05023ae@mail.gmail.com>
	<CF68E270-BECC-4985-980E-6CF9AFCD8A43@daveastels.com>
	<57c63afe0606091913k5de4715cg804d5b5319b76ee2@mail.gmail.com>
Message-ID: <2c5e719e0606092010r1843f44l5c864d197a52125e@mail.gmail.com>

On 6/10/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 6/9/06, David Astels <dastels at daveastels.com> wrote:
> >
> > On 9-Jun-06, at 8:12 PM, aslak hellesoy wrote:
> >
> > > I don't see the usefulness in outputting a dot for each should_*
> >
> > I concur.
>
> I concur as well, though I do see value in reporting specs with zero
> shoulds to expose holes in coverage. The question is how much value?
> Right now, specs and shoulds don't know each other, and I suspect
> introducing them would be costly.

When I first started with rSpec, I expected that a spec with zero
shoulds would be an automatic violatation.

Though I do see how counting shoulds could be a pain to implement.

-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From itsme213 at hotmail.com  Fri Jun  9 23:42:02 2006
From: itsme213 at hotmail.com (itsme213)
Date: Fri, 9 Jun 2006 22:42:02 -0500
Subject: [Rspec-devel] contexts in reporting
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com><BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl><8d961d900606091612r2253d125r9e18dbeff05023ae@mail.gmail.com><CF68E270-BECC-4985-980E-6CF9AFCD8A43@daveastels.com>
	<57c63afe0606091913k5de4715cg804d5b5319b76ee2@mail.gmail.com>
Message-ID: <BAY108-DAV31FBDAE4100B9453FBEA599890@phx.gbl>

>> > I don't see the usefulness in outputting a dot for each should_*

Maybe I am doing something wrong with my shoulds. Is it a best practice to 
have a single should per spec? Smallest number possible?

If not, what is the fundamental difference between seeking feedback on
  - the number of should's vs.
  - the number of specs?

Thanks for any light shed.


From dastels at daveastels.com  Fri Jun  9 23:49:01 2006
From: dastels at daveastels.com (David Astels)
Date: Sat, 10 Jun 2006 00:49:01 -0300
Subject: [Rspec-devel] contexts in reporting
In-Reply-To: <BAY108-DAV31FBDAE4100B9453FBEA599890@phx.gbl>
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com><BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl><8d961d900606091612r2253d125r9e18dbeff05023ae@mail.gmail.com><CF68E270-BECC-4985-980E-6CF9AFCD8A43@daveastels.com>
	<57c63afe0606091913k5de4715cg804d5b5319b76ee2@mail.gmail.com>
	<BAY108-DAV31FBDAE4100B9453FBEA599890@phx.gbl>
Message-ID: <4335719B-85B1-4ECD-B1B8-575EE57ED80E@daveastels.com>


On 10-Jun-06, at 12:42 AM, itsme213 wrote:

>>>> I don't see the usefulness in outputting a dot for each should_*
>
> Maybe I am doing something wrong with my shoulds. Is it a best  
> practice to
> have a single should per spec? Smallest number possible?

I say yes & yes
>
> If not, what is the fundamental difference between seeking feedback on
>   - the number of should's vs.
>   - the number of specs?

specs are more conceptual.. what is the desired behaviour...  
expectations (what you are calling 'shoulds') are technical details.   
Maybe one expectation is enough, maybe not.

Dave


From dchelimsky at gmail.com  Fri Jun  9 23:52:23 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 9 Jun 2006 22:52:23 -0500
Subject: [Rspec-devel] contexts in reporting
In-Reply-To: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>
Message-ID: <57c63afe0606092052g59123cf9r2534f3598b3e5744@mail.gmail.com>

Well, we only had a few votes, but since it is thus far unanimous,
I've removed "contexts" and checked the change in to the trunk.

On 6/9/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> We're thinking of changing the last line of command line output from this:
>
> 38 contexts, 228 specifications, 1 failure
>
> to this:
>
> 228 specifications, 1 failure
>
> The thinking is that the number of contexts is not very useful
> information, so really it's just noise. Anyone think differently?
>

From itsme213 at hotmail.com  Sat Jun 10 00:09:55 2006
From: itsme213 at hotmail.com (itsme213)
Date: Fri, 9 Jun 2006 23:09:55 -0500
Subject: [Rspec-devel] Nested contexts
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
Message-ID: <BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>

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

> Structures like nested contexts are going to
> lead to degredation in clarity

I am curious what this is based on.

If it is based on the experience with the x-Unit family then is that really 
the right comparison? The best written and most readable specs I have seen 
(not in the context of TDD) have very clear nested tables of contents. Not 
everything fits this structure, but it helps more than enough that I would 
hate to read or maintain those specs as a 2-level flat list.

Some uses of that nesting are for things that may not correspond to (say) 
chains of initializers (r-spec setups). I think that is a separate matter. 
If the structure is useful enough, why rule it out? Why not figure out the 
variations in its use?

> I do think that we'll have to address the duplication issue at one
> point,

What kind of ratio do you expect (in the very near term) for:
    Lines-of-Spec / Lines-of-Code

Isn't there evidence that the ratio is close to 1, or even > 1? 

From itsme213 at hotmail.com  Sat Jun 10 00:20:44 2006
From: itsme213 at hotmail.com (itsme213)
Date: Fri, 9 Jun 2006 23:20:44 -0500
Subject: [Rspec-devel] use case for: setup_once, teardown_once
References: <BAY108-DAV69C3BE3A3A35FD5DF53FA99880@phx.gbl>
	<8d961d900606091618v6f9fc10dl95501379e78db8bd@mail.gmail.com>
Message-ID: <BAY108-DAV146443EE7A7EE3B1EA52BD99890@phx.gbl>

From: "aslak hellesoy" <aslak.hellesoy at gmail.com>

>>  - would it be appropriate to be testing expensive/slow things?
>
> Yes, but you should isolate slow code in separate classes and have a
> separate set of specs for those classes only.

If I have 5 components, and the communication channels between them are 
slow, and my acceptance test is about a round trip from outside, through all 
5, and back (possibly including things like response time): what should I 
isolate?

> This is where you should be able to use mocks for the expensive stuff,
> when running specs for the remaining 10%.

I do understand (and agree with) this advice in the context of unit testing. 
I don't see how I could apply it to an integration or acceptance test.

Thanks!

From aslak.hellesoy at gmail.com  Sat Jun 10 01:56:33 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 10 Jun 2006 00:56:33 -0500
Subject: [Rspec-devel] contexts in reporting
In-Reply-To: <4335719B-85B1-4ECD-B1B8-575EE57ED80E@daveastels.com>
References: <57c63afe0606091508l580d46fy4a465e08e9e881e1@mail.gmail.com>
	<BAY108-DAV36155B67D5DB5D5FEAD8A99880@phx.gbl>
	<8d961d900606091612r2253d125r9e18dbeff05023ae@mail.gmail.com>
	<CF68E270-BECC-4985-980E-6CF9AFCD8A43@daveastels.com>
	<57c63afe0606091913k5de4715cg804d5b5319b76ee2@mail.gmail.com>
	<BAY108-DAV31FBDAE4100B9453FBEA599890@phx.gbl>
	<4335719B-85B1-4ECD-B1B8-575EE57ED80E@daveastels.com>
Message-ID: <8d961d900606092256w7089d885rc39ac0b69d2510fe@mail.gmail.com>

On 6/9/06, David Astels <dastels at daveastels.com> wrote:
>
> On 10-Jun-06, at 12:42 AM, itsme213 wrote:
>
> >>>> I don't see the usefulness in outputting a dot for each should_*
> >
> > Maybe I am doing something wrong with my shoulds. Is it a best
> > practice to
> > have a single should per spec? Smallest number possible?
>
> I say yes & yes

Dave wrote about this a while ago:

http://www.artima.com/weblogs/viewpost.jsp?thread=35578

Aslak

> >
> > If not, what is the fundamental difference between seeking feedback on
> >   - the number of should's vs.
> >   - the number of specs?
>
> specs are more conceptual.. what is the desired behaviour...
> expectations (what you are calling 'shoulds') are technical details.
> Maybe one expectation is enough, maybe not.
>
> Dave
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Sat Jun 10 02:09:45 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 10 Jun 2006 01:09:45 -0500
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
	<BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
Message-ID: <8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>

On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> From: "David Chelimsky" <dchelimsky at gmail.com>
>
> > Structures like nested contexts are going to
> > lead to degredation in clarity
>
> I am curious what this is based on.
>
> If it is based on the experience with the x-Unit family then is that really
> the right comparison? The best written and most readable specs I have seen
> (not in the context of TDD) have very clear nested tables of contents. Not
> everything fits this structure, but it helps more than enough that I would
> hate to read or maintain those specs as a 2-level flat list.
>
> Some uses of that nesting are for things that may not correspond to (say)
> chains of initializers (r-spec setups). I think that is a separate matter.
> If the structure is useful enough, why rule it out? Why not figure out the
> variations in its use?
>
> > I do think that we'll have to address the duplication issue at one
> > point,
>
> What kind of ratio do you expect (in the very near term) for:
>     Lines-of-Spec / Lines-of-Code
>

I'd recommend using a tool like RCov (which RSpec's Rake task supports
out of the box).

While usage of a coverage tool cannot prove that you have covered
everything there is to cover, it can identify when you haven't.

As a rule of thumb I'd recommend at least 2 specs per method in the
'outer' parts of an API. At least one for the happy path and at least
one for the unhappy one.

Example: If you're developing an RDBMS, your 'outer' part would be the
code that is 'close' to the client interface - i.e. the code parsing
the SQL. You should have specs that cover the cases when the SQL is
valid, and when it's not. If you get this right, you can be more
relaxed about specs for the 'inner parts' - the code that gets
executed once the SQL's correctness is verified by the outer part. You
don't have to specify unhappy paths as much when you get to the
innards of your code - because you can assume that it won't receive
'bad' method calls and data.

BDD and RSpec are design tools, not testing tools. You write specs to
figure out what code you need to write. You start with specs because
they are designed to be closer to how humans think. They help you
write better code.

> Isn't there evidence that the ratio is close to 1, or even > 1?

I don't think that is possible to prove. AFAIK we still don't have any
axioms to base a proof on.

Aslak

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

From aslak.hellesoy at gmail.com  Sat Jun 10 02:15:46 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 10 Jun 2006 01:15:46 -0500
Subject: [Rspec-devel] use case for: setup_once, teardown_once
In-Reply-To: <BAY108-DAV146443EE7A7EE3B1EA52BD99890@phx.gbl>
References: <BAY108-DAV69C3BE3A3A35FD5DF53FA99880@phx.gbl>
	<8d961d900606091618v6f9fc10dl95501379e78db8bd@mail.gmail.com>
	<BAY108-DAV146443EE7A7EE3B1EA52BD99890@phx.gbl>
Message-ID: <8d961d900606092315q3363adfftf29b46c6f6606215@mail.gmail.com>

On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> From: "aslak hellesoy" <aslak.hellesoy at gmail.com>
>
> >>  - would it be appropriate to be testing expensive/slow things?
> >
> > Yes, but you should isolate slow code in separate classes and have a
> > separate set of specs for those classes only.
>
> If I have 5 components, and the communication channels between them are
> slow, and my acceptance test is about a round trip from outside, through all
> 5, and back (possibly including things like response time): what should I
> isolate?
>
> > This is where you should be able to use mocks for the expensive stuff,
> > when running specs for the remaining 10%.
>
> I do understand (and agree with) this advice in the context of unit testing.
> I don't see how I could apply it to an integration or acceptance test.
>

Integration/Acceptance/EndToEnd tests where all code is playing in
concert - usually using heavy resources like I/O, Threads, Graphic
environments etc...

They're usually slow.

I'm not sure RSpec is the right tool for that kind of things.

RSpec's focus is on a smaller level - designing (and verifying)
individual classes' behaviour and their communication with immediate
neighbours (using mocks).

While you can certainly use RSpec to poke a fully wired set of many
objects and see if it chokes, I'ts certainly not what RSpec is
designed for. -Because when you're doing this kind of activity, you're
no longer designing, but testing.

I'm a huge fan of this kind of tests though - don't get me wrong.
Maybe RSpec is good for this stuff too - I just haven't tried it yet.

Aslak

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

From evgeny.zislis at gmail.com  Sat Jun 10 05:25:22 2006
From: evgeny.zislis at gmail.com (Evgeny)
Date: Sat, 10 Jun 2006 12:25:22 +0300
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
	<BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
	<8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
Message-ID: <b6840c770606100225l775c8ec7t222a062e1afb074c@mail.gmail.com>

The reason I suggested this in the first place was that nested setups
is something that is really missing. If I have 3 lines of code that I
just use in each and every setup of each and every context -- then
that is something I would have wanted to have in a separate location.

Ohh well . . . doesn't look like this idea is going to pass anyway :)

On 6/10/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> > From: "David Chelimsky" <dchelimsky at gmail.com>
> >
> > > Structures like nested contexts are going to
> > > lead to degredation in clarity
> >
> > I am curious what this is based on.
> >
> > If it is based on the experience with the x-Unit family then is that really
> > the right comparison? The best written and most readable specs I have seen
> > (not in the context of TDD) have very clear nested tables of contents. Not
> > everything fits this structure, but it helps more than enough that I would
> > hate to read or maintain those specs as a 2-level flat list.
> >
> > Some uses of that nesting are for things that may not correspond to (say)
> > chains of initializers (r-spec setups). I think that is a separate matter.
> > If the structure is useful enough, why rule it out? Why not figure out the
> > variations in its use?
> >
> > > I do think that we'll have to address the duplication issue at one
> > > point,
> >
> > What kind of ratio do you expect (in the very near term) for:
> >     Lines-of-Spec / Lines-of-Code
> >
>
> I'd recommend using a tool like RCov (which RSpec's Rake task supports
> out of the box).
>
> While usage of a coverage tool cannot prove that you have covered
> everything there is to cover, it can identify when you haven't.
>
> As a rule of thumb I'd recommend at least 2 specs per method in the
> 'outer' parts of an API. At least one for the happy path and at least
> one for the unhappy one.
>
> Example: If you're developing an RDBMS, your 'outer' part would be the
> code that is 'close' to the client interface - i.e. the code parsing
> the SQL. You should have specs that cover the cases when the SQL is
> valid, and when it's not. If you get this right, you can be more
> relaxed about specs for the 'inner parts' - the code that gets
> executed once the SQL's correctness is verified by the outer part. You
> don't have to specify unhappy paths as much when you get to the
> innards of your code - because you can assume that it won't receive
> 'bad' method calls and data.
>
> BDD and RSpec are design tools, not testing tools. You write specs to
> figure out what code you need to write. You start with specs because
> they are designed to be closer to how humans think. They help you
> write better code.
>
> > Isn't there evidence that the ratio is close to 1, or even > 1?
>
> I don't think that is possible to prove. AFAIK we still don't have any
> axioms to base a proof on.
>
> Aslak
>
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sat Jun 10 09:07:27 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 10 Jun 2006 08:07:27 -0500
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
	<BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
Message-ID: <57c63afe0606100607w1e0626fl872d0e8339ae14d9@mail.gmail.com>

On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
> From: "David Chelimsky" <dchelimsky at gmail.com>
>
> > Structures like nested contexts are going to
> > lead to degredation in clarity
>
> I am curious what this is based on.
>
> If it is based on the experience with the x-Unit family then is that really
> the right comparison?

Yes it does come from experience w/ xUnit tools. That's an interesting
question (right comparison?). We are, after all, trying to get away
from them. I will definitely give that some more thought.

In the mean time, however, let me give you concrete example of why we
believe this would be a disaster:

Example with nested contexts:

context "A person" do
  setup do
    @person = Person.new
  end
  context "who is an American citizen" do
    setup do
      @person.citizen = true
    end
    context "and is 17 years old" do
      setup do
        @person.birthdate = 17.years_ago
      end
      specify "can not vote in an election" do
        @person.can_vote?.should_be false
      end
      specify "can not serve in the military" do
        @person.can_serve?.should_be false
      end
    end
    context "and is 18 years old" do
      setup do
        @person.birthdate = 18.years_ago
      end
      specify "can vote in an election" do
        @person.can_vote?.should_be true
      end
      specify "can serve in the military" do
        @person.can_serve?.should_be true
      end
    end
  end
  context "who is not an American citizen" do
    setup do
      @person.citizen = false
    end
    context "and is not a registered alien" do
      setup do
        @person.registered_alien = false
      end
      context "and is 17 years old" do
        setup do
          @person.birthdate = 17.years_ago
        end
        specify "can not vote in an election" do
          @person.can_vote?.should_be false
        end
        specify "can not serve in the military" do
          @person.can_serve?.should_be false
        end
      end
      context "and is 18 years old" do
        setup do
          @person.birthdate = 18.years_ago
        end
        specify "can not vote in an election" do
          @person.can_vote?.should_be false
        end
        specify "can not serve in the military" do
          @person.can_serve?.should_be false
        end
      end
    end
    context "and is a registered alien" do
      setup do
        @person.registered_alien = true
      end
      context "and is 17 years old" do
        setup do
          @person.birthdate = 17.years_ago
        end
        specify "can not vote in an election" do
          @person.can_vote?.should_be false
        end
        specify "can not serve in the military" do
          @person.can_serve?.should_be false
        end
      end
      context "and is 18 years old" do
        setup do
          @person.birthdate = 18.years_ago
        end
        specify "can not vote in an election" do
          @person.can_vote?.should_be false
        end
        specify "can serve in the military" do
          @person.can_serve?.should_be true
        end
      end
    end
  end
end

Same example without nested contexts:

context "A 17 year old American citizen" do
  setup do
    @person = Person.new(birthdate => 17.years_ago, citizen => true)
  end
  specify "can not vote in an election" do
    @person.can_vote?.should_be false
  end
  specify "can not serve in the military" do
    @person.can_serve?.should_be false
  end
end

context "An 18 year old American citizen" do
  setup do
    @person = Person.new(birthdate => 18.years_ago, citizen => true)
  end
  specify "can vote in an election" do
    @person.can_vote?.should_be true
  end
  specify "can serve in the military" do
    @person.can_serve?.should_be true
  end
end

context "A 17 year old non-registered alien" do
  setup do
    @person = Person.new(birthdate => 17.years_ago, citizen => false)
  end
  specify "can not vote in an election" do
    @person.can_vote?.should_be false
  end
  specify "can not serve in the military" do
    @person.can_serve?.should_be false
  end
end

context "An 18 year old non-registered alien" do
  setup do
    @person = Person.new(birthdate => 18.years_ago, citizen => false)
  end
  specify "can not vote in an election" do
    @person.can_vote?.should_be false
  end
  specify "can not serve in the military" do
    @person.can_serve?.should_be false
  end
end

context "A 17 year old registered alien" do
  setup do
    @person = Person.new(
      birthdate => 17.years_ago,
      citizen => false,
      registered_alien => true)
  end
  specify "can not vote in an election" do
    @person.can_vote?.should_be false
  end
  specify "can not serve in the military" do
    @person.can_serve?.should_be false
  end
end

context "An 18 year old registered alien" do
  setup do
    @person = Person.new(
      birthdate => 18.years_ago,
      citizen => false,
      registered_alien => true)
  end
  specify "can not vote in an election" do
    @person.can_vote?.should_be false
  end
  specify "can serve in the military" do
    @person.can_serve?.should_be true
  end
end

Which do you find easier to read? Which would be easier to maintain?
What would the output look like?

Nested:

A person
- who is an American citizen
  - and is 17 years old
    - can not vote in an election
    - can not serve in the military
  - and is 18 years old
    - can vote in an election
    - can serve in the military
- who is not an American citizen
  - and is not a registered alien
    - and is 17 years old
      - can not vote in an election
      - can not serve in the military
    - and is 18 years old
      - can not vote in an election
      - can not serve in the military
  - and is a registered alien
    - and is 17 years old
      - can not vote in an election
      - can not serve in the military
    - and is 18 years old
      - can not vote in an election
      - can serve in the military

OR

A person
- who is an American citizen
- and is 17 years old
  - can not vote in an election
  - can not serve in the military
- who is an American citizen
- and is 18 years old
  - can vote in an election
  - can serve in the military
- who is not an American citizen
- and is not a registered alien
- and is 17 years old
  - can not vote in an election
  - can not serve in the military
- who is not an American citizen
- and is not a registered alien
- and is 18 years old
  - can not vote in an election
  - can not serve in the military
- who is not an American citizen
- and is a registered alien
- and is 17 years old
  - can not vote in an election
  - can not serve in the military
- who is not an American citizen
- and is a registered alien
- and is 18 years old
  - can not vote in an election
  - can serve in the military

OR

A person
- who is an American citizen and is 17 years old
  - can not vote in an election
  - can not serve in the military
- who is an American citizen and is 18 years old
  - can vote in an election
  - can serve in the military
- who is not an American citizen and is not a registered alien and is
17 years old
  - can not vote in an election
  - can not serve in the military
- who is not an American citizen and is not a registered alien and is
18 years old
  - can not vote in an election
  - can not serve in the military
- who is not an American citizen and is a registered alien and is 17 years old
  - can not vote in an election
  - can not serve in the military
- who is not an American citizen and is a registered alien and is 18 years old
  - can not vote in an election
  - can serve in the military

In my view, these all just suck. Better ideas are welcome, however
look at the non-nested context output:

A 17 year old American citizen
- can not vote in an election
- can not serve in the military

An 18 year old American citizen
- can vote in an election
- can serve in the military

A 17 year old non-registered alien
- can not vote in an election
- can not serve in the military

An 18 year old non-registered alien
- can not vote in an election
- can not serve in the military

A 17 year old registered alien
- can not vote in an election
- can not serve in the military

An 18 year old registered alien
- can not vote in an election
- can serve in the military

Not to mention the fact that the nested context forces us to have
setters on the Person class for birthdate and aspects of citizenship.
Whether or not you believe that makes sense in THIS example, there are
certainly examples of objects with data values that should simply not
be mutable. Nested contexts would encourage making them mutable "in
the name of *spec*ability".

All of that said, that was one example. Perhaps there is an example
where nested contexts would actually read better, be more maintainable
and produce better output. I would be more than happy to consider such
an example.

David

From antti.tarvainen at iki.fi  Sat Jun 10 11:16:30 2006
From: antti.tarvainen at iki.fi (Antti Tarvainen)
Date: Sat, 10 Jun 2006 18:16:30 +0300
Subject: [Rspec-devel] Abstract contexts
Message-ID: <5b89e3bd0606100816r5be2bcffua18896e615726c0a@mail.gmail.com>

(I already wrote about this on the feature-requests list, but since
almost no one seems to be reading it, I bring it up here too.)

Here's a variation of the nested contexts approach, but with different
goals. The proposition is to have abstract contexts that can introduce
specifications but no setups. Abstract contexts can be included in
concrete contexts with "is" method.

Example:

abstract_context "underaged" do
  specify "can not vote in an election" do
    @person.can_vote?.should_be false
  end
  specify "can not serve in the military" do
    @person.can_serve?.should_be false
  end
end

context "A 17 year old American citizen" do
  is "underaged"
  setup do
    @person = Person.new(birthdate => 17.years_ago, citizen => true)
  end
end

would output

A 17 year old American citizen
- can not vote in an election
- can not serve in the military

or possibly

A 17 year old American citizen
- can not vote in an election (is underaged)
- can not serve in the military (is underaged)


The idea is to highlight why certain specifications are the way they
are. In this example, instead of just telling that 17-year-olds cannot
vote, we can tell that they cannot vote _because they are underaged_.

I think this is a common pattern: a logical (=abstract) specification
("underaged people cannot vote") manifests itself in a concrete
specification ("17-year-olds cannot vote"). In my opinion, these
connections should be visible in the specification, and this is what
abstract_contexts try to solve.

Naturally abstract_contexts could also reduce the number of lines in
some cases. This is just a happy side effect.



A longer example (compare with http://rspec.rubyforge.org/examples.html):

abstract_context "a stack that's not empty" do
  specify "should return top when sent top" do
    @stack.top.should.be 10
  end

  specify "should not remove top when sent top" do
    @stack.top.should.be 10
    @stack.top.should.be 10
  end

  specify "should return top when sent pop" do
    @stack.pop.should.be 10
  end

  specify "should remove top when sent pop" do
    @stack.pop.should.be 10
    @stack.pop.should.be 9
  end
end


abstract_context "a stack that's not full" do
  specify "should accept an item when sent push" do
    lambda { @stack.push Object.new }.should.not.raise
  end
end


abstract_context "an empty stack" do
  specify "should complain when sent top" do
    lambda { @stack.top }.should.raise StackUnderflowError
  end

  specify "should complain when sent pop" do
    lambda { @stack.pop }.should.raise StackUnderflowError
  end
end

abstract_context "a full stack" do
  specify "should complain on push" do
    lambda { @stack.push Object.new }.should.raise StackOverflowError
  end
end


context "A stack with zero items" do
  is "an empty stack", "a stack that's not full"

  setup do
    @stack = Stack.new
  end
end


context "A stack with one item" do
  is "a stack that's not empty", "a stack that's not full"

  setup do
    @stack = Stack.new
    @stack.push 10
  end

  specify "should remove top when sent pop" do
    @stack.pop.should.be 10
    lambda { @stack.pop }.should.raise StackUnderflowError
  end
end


context "A stack with nine items"
  is "a stack that's not empty", "a stack that's not full"

  setup do
    (2..10).each { |i| @stack.push i }
  end
end


context "A stack with ten items"
  is "a stack that's not empty", "a full stack"

  setup do
    @stack = Stack.new
    (1..10).each { |i| @stack.push i }
  end
end



What do you think?


Antti T.

From itsme213 at hotmail.com  Sat Jun 10 12:48:08 2006
From: itsme213 at hotmail.com (itsme213)
Date: Sat, 10 Jun 2006 11:48:08 -0500
Subject: [Rspec-devel] Abstract contexts
References: <5b89e3bd0606100816r5be2bcffua18896e615726c0a@mail.gmail.com>
Message-ID: <BAY108-DAV11ED70DCBBC71DC9F2D9B599890@phx.gbl>

From: "Antti Tarvainen" <antti.tarvainen at iki.fi>
> Here's a variation of the nested contexts approach, but with different
> goals.

This looks encouraging ... it is roughly what I meant by:

> Some uses of that nesting are for things that may NOT correspond to (say)
> chains of initializers (r-spec setups). I think that is a separate matter.
> If the structure is useful enough, why rule it out? Why not figure out the
> variations in its use?

Relations between contexts are useful for more than just sharing of parts of 
initialization chains. One chooses contexts and their structure to improve 
the structure and readability of your specs (and, of course, one can misuse 
any construct as well).


From dastels at daveastels.com  Sat Jun 10 14:45:07 2006
From: dastels at daveastels.com (David Astels)
Date: Sat, 10 Jun 2006 15:45:07 -0300
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
	<BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
	<8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
Message-ID: <83724609-9EC4-4A61-B735-3FE1D89326EB@daveastels.com>


On 10-Jun-06, at 3:09 AM, aslak hellesoy wrote:

> On 6/9/06, itsme213 <itsme213 at hotmail.com> wrote:
>
>> Isn't there evidence that the ratio is close to 1, or even > 1?
>
> I don't think that is possible to prove. AFAIK we still don't have any
> axioms to base a proof on.

In my experience, I've found that 1.5-2:1 is typical and desirable.   
That's half again, to twice, as much test/spec code as production code.

Dave


From dchelimsky at gmail.com  Sat Jun 10 14:45:16 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 10 Jun 2006 13:45:16 -0500
Subject: [Rspec-devel] Abstract contexts
In-Reply-To: <5b89e3bd0606100816r5be2bcffua18896e615726c0a@mail.gmail.com>
References: <5b89e3bd0606100816r5be2bcffua18896e615726c0a@mail.gmail.com>
Message-ID: <57c63afe0606101145r65200536ya2c4bb4f1d860369@mail.gmail.com>

On 6/10/06, Antti Tarvainen <antti.tarvainen at iki.fi> wrote:
> Here's a variation of the nested contexts approach, but with different
> goals. The proposition is to have abstract contexts that can introduce
> specifications but no setups. Abstract contexts can be included in
> concrete contexts with "is" method.
>
> abstract_context "a stack that's not empty" do
>   specify "should return top when sent top" do
>     @stack.top.should.be 10
>   end
>
>   specify "should not remove top when sent top" do
>     @stack.top.should.be 10
>     @stack.top.should.be 10
>   end
>
>   specify "should return top when sent pop" do
>     @stack.pop.should.be 10
>   end
>
>   specify "should remove top when sent pop" do
>     @stack.pop.should.be 10
>     @stack.pop.should.be 9
>   end
> end
>
> abstract_context "a stack that's not full" do
>   specify "should accept an item when sent push" do
>     lambda { @stack.push Object.new }.should.not.raise
>   end
> end
>
> abstract_context "an empty stack" do
>   specify "should complain when sent top" do
>     lambda { @stack.top }.should.raise StackUnderflowError
>   end
>
>   specify "should complain when sent pop" do
>     lambda { @stack.pop }.should.raise StackUnderflowError
>   end
> end
>
> abstract_context "a full stack" do
>   specify "should complain on push" do
>     lambda { @stack.push Object.new }.should.raise StackOverflowError
>   end
> end
>
> context "A stack with zero items" do
>   is "an empty stack", "a stack that's not full"
>
>   setup do
>     @stack = Stack.new
>   end
> end
>
> context "A stack with one item" do
>   is "a stack that's not empty", "a stack that's not full"
>
>   setup do
>     @stack = Stack.new
>     @stack.push 10
>   end
>
>   specify "should remove top when sent pop" do
>     @stack.pop.should.be 10
>     lambda { @stack.pop }.should.raise StackUnderflowError
>   end
> end
>
> context "A stack with nine items"
>   is "a stack that's not empty", "a stack that's not full"
>
>   setup do
>     (2..10).each { |i| @stack.push i }
>   end
> end
>
> context "A stack with ten items"
>   is "a stack that's not empty", "a full stack"
>
>   setup do
>     @stack = Stack.new
>     (1..10).each { |i| @stack.push i }
>   end
> end
>
>
>
> What do you think?

This is similar to an idea that Dave Astels and I were batting around
just yesterday. We were discussing how to address common behaviour
expressed in a base class. In general, I prefer this to nesting
contexts. What we're reusing here are specs across contexts as opposed
to contexts across contexts.

I still have a couple of reservations though.

In this example, "should remove top when sent pop" in "A stack with
one item" is essentially overriding "should remove top when sent pop"
in "a stack that's not empty". In this framework that seems a likely
source of confusion to me. What if we didn't allow this overriding? If
there is truly common behaviour, it could be expressed in the
abstract_context, but if it differs across concrete contexts, then it
has to appear in each one?

The other thing that concerns me is that the setup in "A stack with
nine items" must use (2..10) because the specs in the abstract
contexts have hard coded values. So we've got these bindings between
the concrete and abstract contexts that could make it difficult to
understand why something is failing.

Thoughts?

From dastels at daveastels.com  Sat Jun 10 14:46:34 2006
From: dastels at daveastels.com (David Astels)
Date: Sat, 10 Jun 2006 15:46:34 -0300
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <b6840c770606100225l775c8ec7t222a062e1afb074c@mail.gmail.com>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
	<BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
	<8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
	<b6840c770606100225l775c8ec7t222a062e1afb074c@mail.gmail.com>
Message-ID: <C124C0B2-9307-4ABC-AD69-1A97286F0D92@daveastels.com>


On 10-Jun-06, at 6:25 AM, Evgeny wrote:

> The reason I suggested this in the first place was that nested setups
> is something that is really missing. If I have 3 lines of code that I
> just use in each and every setup of each and every context -- then
> that is something I would have wanted to have in a separate location.

Can't you just 'include' it?

Dave


From dchelimsky at gmail.com  Sat Jun 10 14:59:27 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 10 Jun 2006 13:59:27 -0500
Subject: [Rspec-devel] Abstract contexts
In-Reply-To: <BAY108-DAV11ED70DCBBC71DC9F2D9B599890@phx.gbl>
References: <5b89e3bd0606100816r5be2bcffua18896e615726c0a@mail.gmail.com>
	<BAY108-DAV11ED70DCBBC71DC9F2D9B599890@phx.gbl>
Message-ID: <57c63afe0606101159q306fa21agc71b55212c61ebe8@mail.gmail.com>

On 6/10/06, itsme213 <itsme213 at hotmail.com> wrote:
> Relations between contexts are useful for more than just sharing of parts of
> initialization chains. One chooses contexts and their structure to improve
> the structure and readability of your specs (and, of course, one can misuse
> any construct as well).

I agree that there are many uses for this. The trick is to figure out
what we really need in this framework, and weigh the costs of that
against our primary goals.

<soap box speech>
BDD is, in part, a reaction to shitty TDD. A primary reason people to
TDD badly is because the tools not only allow it, they actually
encourage it in many cases. Case in point - our good friend Eclipse.
Eclipse, for the most part, rocks. But there is this one tool it
provides that makes me want to scream every time I see it. It will
allow you to select a production class and generate a test case for
it. The test case has one test method per public method on the
production class:

public class A
{
  public void doB() {...}
  public void getC() {...}
}

public class ATest extends TestCase
{
  public void testDoB() {...}
  public void testGetC() {...}
}

The result of this is that testing newbies use these stubs exactly as
they are provided, with all the different contexts expressed in one
method, state changes, dozens of assertions, etc, etc, etc. They are
encouraged to do this by the tool, and believe that this is the
correct way to test. This is a fucking disaster in my view.

So, seeing that we're trying to improve the "developing world" with
the introduction of BDD, I (for one) am extremely cautious when it
comes to providing too many features in the tools, lest they should
send the wrong message.
</soap box speech>

That said, we will address this at one point or another, and these
conversations are very beneficial to move us in the direction. Again,
the key is to figure out the right approach. One that makes it easy to
write good specs and hard to write bad ones.

From antti.tarvainen at iki.fi  Sat Jun 10 17:23:06 2006
From: antti.tarvainen at iki.fi (Antti Tarvainen)
Date: Sun, 11 Jun 2006 00:23:06 +0300
Subject: [Rspec-devel] Abstract contexts
In-Reply-To: <57c63afe0606101145r65200536ya2c4bb4f1d860369@mail.gmail.com>
References: <5b89e3bd0606100816r5be2bcffua18896e615726c0a@mail.gmail.com>
	<57c63afe0606101145r65200536ya2c4bb4f1d860369@mail.gmail.com>
Message-ID: <5b89e3bd0606101423r4d41dc15ia06e83d74ad8232d@mail.gmail.com>

> In this example, "should remove top when sent pop" in "A stack with
> one item" is essentially overriding "should remove top when sent pop"
> in "a stack that's not empty". In this framework that seems a likely
> source of confusion to me. What if we didn't allow this overriding? If
> there is truly common behaviour, it could be expressed in the
> abstract_context, but if it differs across concrete contexts, then it
> has to appear in each one?

Yes, I agree that this can be confusing. One possible solution is to
have a separate method to override specifications, such as

override_specification "should remove top when sent pop" do
  @stack.pop.should.be 10
  lambda { @stack.pop }.should.raise StackUnderflowError
end

> The other thing that concerns me is that the setup in "A stack with
> nine items" must use (2..10) because the specs in the abstract
> contexts have hard coded values. So we've got these bindings between
> the concrete and abstract contexts that could make it difficult to
> understand why something is failing.

This is also true. How about this:


def initial_stack_values(how_many=10)
  (11-how_many..10).to_a
end

abstract_context "A stack that's not empty" do
  specify "should return top when sent top" do
    @stack.top.should.be initial_stack_values.last
  end
# ...
end

context "A stack with nine items"
  is "a stack that's not empty", "a stack that's not full"

  setup do
    @stack = Stack.new
    initial_stack_values(9).each { |i| @stack.push i }
  end
end


Antti T.

From itsme213 at hotmail.com  Sat Jun 10 18:47:03 2006
From: itsme213 at hotmail.com (itsme213)
Date: Sat, 10 Jun 2006 17:47:03 -0500
Subject: [Rspec-devel] Nested contexts
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com><57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com><BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl><8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
	<83724609-9EC4-4A61-B735-3FE1D89326EB@daveastels.com>
Message-ID: <BAY108-DAV6A2A31E288D186905B5FC99890@phx.gbl>

From: "David Astels" <dastels at daveastels.com>

> In my experience, I've found that 1.5-2:1 is typical and desirable.
> That's half again, to twice, as much test/spec code as production code.

Doesn't that mean that good structure of spec/test code is at in the same 
general ballpark of importance as good structure of the code?

From itsme213 at hotmail.com  Sat Jun 10 18:52:48 2006
From: itsme213 at hotmail.com (itsme213)
Date: Sat, 10 Jun 2006 17:52:48 -0500
Subject: [Rspec-devel] Abstract contexts
References: <5b89e3bd0606100816r5be2bcffua18896e615726c0a@mail.gmail.com><BAY108-DAV11ED70DCBBC71DC9F2D9B599890@phx.gbl>
	<57c63afe0606101159q306fa21agc71b55212c61ebe8@mail.gmail.com>
Message-ID: <BAY108-DAV11DDD3F84B590BF4D901B599890@phx.gbl>

From: "David Chelimsky" <dchelimsky at gmail.com>
> <soap box speech>
..

I was missing some of that background, so that was helpful.

> That said, we will address this at one point or another, and these
> conversations are very beneficial to move us in the direction.

I was starting to wonder if I had totally missed something about the 
philosophy of rspec.

Thanks!

From dchelimsky at gmail.com  Sat Jun 10 19:36:24 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 10 Jun 2006 18:36:24 -0500
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <BAY108-DAV6A2A31E288D186905B5FC99890@phx.gbl>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
	<BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
	<8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
	<83724609-9EC4-4A61-B735-3FE1D89326EB@daveastels.com>
	<BAY108-DAV6A2A31E288D186905B5FC99890@phx.gbl>
Message-ID: <57c63afe0606101636o51b03901x4942584a5ff5f2e7@mail.gmail.com>

On 6/10/06, itsme213 <itsme213 at hotmail.com> wrote:
> From: "David Astels" <dastels at daveastels.com>
>
> > In my experience, I've found that 1.5-2:1 is typical and desirable.
> > That's half again, to twice, as much test/spec code as production code.
>
> Doesn't that mean that good structure of spec/test code is at in the same
> general ballpark of importance as good structure of the code?

YES. ABSOLUTELY we want good structure in the specs. But that does not
mean the same thing as good structure in the code being specified.

The reasons for duplication being problematic in code are primarily
maintenance and SRP violations:

Maintenance - if you have to change something that is duplicated, then
you have to change it more than once.

SRP - if two places are doing the same thing, then each only has 1/2
of a responsibility. Each responsibility should be expressed once and
only once.

OK, so how does that work out in specs?

Maintenance - you should only be changing specs if requirements are
changing. Adding new requirements should mean adding new specs (just
like the Open/Closed Principle). If this is true, then you should only
be revisiting spec code in order to understand how production code is
supposed to work, or to try to find the cause of a bug. In both of
these cases, complete contextual clarity is of the utmost importance.
This is different than the production code, because in production code
you don't need the entire external context to understand the code
you're looking at (and if you do, there is probably a design problem).

SRP - the responsibility of spec code is to define the use of
production code. Period. Anything else takes second place.

So I'd argue that all of this conversation about duplication is based
on the belief that all duplication is evil. But you have to examine
where that came from. In my view it just doesn't have the same
implications in spec code that it does in production code.

Cheers,
David

From evgeny.zislis at gmail.com  Sun Jun 11 03:54:42 2006
From: evgeny.zislis at gmail.com (Evgeny)
Date: Sun, 11 Jun 2006 10:54:42 +0300
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <C124C0B2-9307-4ABC-AD69-1A97286F0D92@daveastels.com>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
	<BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
	<8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
	<b6840c770606100225l775c8ec7t222a062e1afb074c@mail.gmail.com>
	<C124C0B2-9307-4ABC-AD69-1A97286F0D92@daveastels.com>
Message-ID: <b6840c770606110054u34c28ce8rbac2491be590c3b8@mail.gmail.com>

I could include it, but then for those 3 lines of code i'd have to
have an extra include line in each separate setup in each context that
is using these 3 lines.

For some reason the suggestion of abstract_contexts exclude setups...
which is something that could solve this "including".

On 6/10/06, David Astels <dastels at daveastels.com> wrote:
>
> On 10-Jun-06, at 6:25 AM, Evgeny wrote:
>
> > The reason I suggested this in the first place was that nested setups
> > is something that is really missing. If I have 3 lines of code that I
> > just use in each and every setup of each and every context -- then
> > that is something I would have wanted to have in a separate location.
>
> Can't you just 'include' it?
>
> Dave
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dastels at daveastels.com  Sun Jun 11 10:34:12 2006
From: dastels at daveastels.com (David Astels)
Date: Sun, 11 Jun 2006 11:34:12 -0300
Subject: [Rspec-devel] Nested contexts
In-Reply-To: <b6840c770606110054u34c28ce8rbac2491be590c3b8@mail.gmail.com>
References: <b6840c770606091828hf59cd92h779044d2b876a1fe@mail.gmail.com>
	<57c63afe0606091901w251c5c67g1262b550a857ad73@mail.gmail.com>
	<BAY108-DAV40F6AD5CF2A62055F776A99890@phx.gbl>
	<8d961d900606092309o6270df06g4f84f801605d0478@mail.gmail.com>
	<b6840c770606100225l775c8ec7t222a062e1afb074c@mail.gmail.com>
	<C124C0B2-9307-4ABC-AD69-1A97286F0D92@daveastels.com>
	<b6840c770606110054u34c28ce8rbac2491be590c3b8@mail.gmail.com>
Message-ID: <46285A1E-F7F0-4F57-B989-940DEE94BA8B@daveastels.com>


On 11-Jun-06, at 4:54 AM, Evgeny wrote:

> I could include it, but then for those 3 lines of code i'd have to
> have an extra include line in each separate setup in each context that
> is using these 3 lines.

ok.. bottom line for me is that having those 3 lines in each context  
that needs them is worth more in clarity than you pay in duplication.

Dave



From dchelimsky at gmail.com  Sun Jun 11 16:37:53 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 11 Jun 2006 15:37:53 -0500
Subject: [Rspec-devel] underscores vs dots revisited
Message-ID: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>

All,

I've been playing around with the rails plugin and I ran into some
trouble with this spec:

context "List Item Link with no list item" do
  specify "should return nil for 'name'" do
    ListItemLink.new.name.should_be nil
  end
end

notice "should_be nil"

This was failing, giving me the following error:

You have a nil object when you didn't expect it!
The error occured while evaluating nil.should_be

indicating that somehow there was a conflict between our use of
method_missing in rspec and that in rails or active_record

As it turns out "should.be nil" (with a "." instead of "_") does work just fine.

So this has me rethinking my stance on "_" vs ".". I realize that "_"
seems like nicer syntax, but what I learned when we first introduced
it is that there are a lot of exceptions that have to be handled (a
bunch of standard rspec expectations didn't work right away).

Now that this is creating a conflict with the rails plugin, it occurs
to me that we're going to run into problems any time rspec is trying
to play nice with some other tool or framework that also uses
method_missing to do its magic.

I therefore, emphatically, recommend that we DO NOT SUPPORT "_", we
remove the sugar, and we change the docs back.

Thoughts?

From aslak.hellesoy at gmail.com  Sun Jun 11 17:08:45 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 11 Jun 2006 16:08:45 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
Message-ID: <8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>

On 6/11/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> All,
>
> I've been playing around with the rails plugin and I ran into some
> trouble with this spec:
>
> context "List Item Link with no list item" do
>   specify "should return nil for 'name'" do
>     ListItemLink.new.name.should_be nil
>   end
> end
>
> notice "should_be nil"
>
> This was failing, giving me the following error:
>
> You have a nil object when you didn't expect it!
> The error occured while evaluating nil.should_be
>
> indicating that somehow there was a conflict between our use of
> method_missing in rspec and that in rails or active_record
>
> As it turns out "should.be nil" (with a "." instead of "_") does work just fine.
>
> So this has me rethinking my stance on "_" vs ".". I realize that "_"
> seems like nicer syntax, but what I learned when we first introduced
> it is that there are a lot of exceptions that have to be handled (a
> bunch of standard rspec expectations didn't work right away).
>
> Now that this is creating a conflict with the rails plugin, it occurs
> to me that we're going to run into problems any time rspec is trying
> to play nice with some other tool or framework that also uses
> method_missing to do its magic.
>
> I therefore, emphatically, recommend that we DO NOT SUPPORT "_", we
> remove the sugar, and we change the docs back.
>

I think that we should at least try to address the problem first.

Can you check in a failing spec for this in the rails demo app?

Aslak

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

From dchelimsky at gmail.com  Sun Jun 11 17:25:46 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 11 Jun 2006 16:25:46 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
Message-ID: <57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>

On 6/11/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/11/06, David Chelimsky <dchelimsky at gmail.com> wrote:

> I think that we should at least try to address the problem first.

I disagree. I'm not saying the problem is insurmountable. I'm saying
that it's going to come up whenever we're trying to integrate w/ other
tools. method_missing is extraordinarily invasive, and I think we're
asking for trouble by agreeing to support this over the long run.

This is a problem w/ all frameworks. They try to do too much and it
ends up screwing up reasonable usage of it later. I think doing this
is a mistake.

> Can you check in a failing spec for this in the rails demo app?

Heading out right now. I'll do this later tonight, in spite of my
objection. But I still object.

David

From dchelimsky at gmail.com  Sun Jun 11 18:45:21 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 11 Jun 2006 17:45:21 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
	<57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
Message-ID: <57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>

On 6/11/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> Heading out right now. I'll do this later tonight, in spite of my
> objection. But I still object.

OK. I checked it in. To see this fail, stand in vendor/rspec_on_rails
and say 'rake spec'.

Cheers,
David

From dchelimsky at gmail.com  Tue Jun 13 07:13:19 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 13 Jun 2006 06:13:19 -0500
Subject: [Rspec-devel] Fwd: rspec, duplication in setup, etc.
In-Reply-To: <2f288f8c0606122120j7f851fa6g3878287b583b69db@mail.gmail.com>
References: <2f288f8c0606122120j7f851fa6g3878287b583b69db@mail.gmail.com>
Message-ID: <57c63afe0606130413v7d23f263ob675664ab1c5d9ed@mail.gmail.com>

Last night Dave Astels, Aslak Hellesoy and I spoke about BDD and rspec
at the Chicago Ruby Users Group meeting. After our talk, I had a
conversation w/ Nate Austin about the whole nested context issue and
here's most of an email he sent to me (forwarded to you w/ his
permission). I'll reply in a separate post.

---------- Forwarded message ----------
From: Nate Austin <navision at gmail.com>
Date: Jun 12, 2006 11:20 PM
Subject: rspec, duplication in setup, etc.
To: dchelimsky at gmail.com


Hi David,

I hacked up a quick example of what I was talking about based on the
conversation we had at CHIRB tonight.  I would reply to the Nested
contexts thread on rspec-devel, but I've only joined now.  So, rather
than breaking the thread, I'm sending this directly to you.  Feel free
to post it to rspec-devel if you like.  Please excuse my lack of
Ruby-foo.  I'm still just looking through the fence at the Ruby world.

This adds an additional level of indirection for the setup and the
contextual naming that allows the duplication to be removed.  I think
it does so without loss of clarity, but that is, of course,
subjective.

 behavior_for person do
  context of_age, citizen do
    specify "can vote in an election" do
      @person.can_vote?.should_be true
    end
  end

  context not_of_age, non_citizen do
    specify "can vote in an election" do
      @person.can_vote?.should_be false
    end
  end
end

person {  // I don't know the proper syntax for something like this,
so this is somewhat pseudo-ish
    // is this really necessary, or could the type be used in the
behavior_for line?

  contextual_name do
    "A person"
  end

  construct_with(args) do
    Person.new(args)  // this probably isn't needed.  Maybe just get
the type back and have framework call new?  My Ruby-foo is weak.
  end

}

of_age {
  contextual_name do
    "18 years old"
  end

  constructor_contribution do
    birthdate => 18.years_ago
  end
}

citizen {
  contextual_name do
    "is a citizen"
  end

  constructor_contribution do
    citizen => true
  end
}


Also, not required for this example, but could also have an optional
modify(object) method that would just allow you to bombard the poor
constructed object with all sorts of nasty side-effects.
So, framework would gather all of the various BehaviorParts for the
context, gather the constructor_contributions, construct the object
and put it in a variable, pass it to all of the modify() methods, and
execute the specs
The display would be similar to this:

Person:

  - 18 years old, is a citizen
    - can vote in an election
    - can serve in the military
  - 17 years old, is a citizen
    - can not vote in an election
    - can not serve in the military

    etc.



-Nate Austin

From dchelimsky at gmail.com  Tue Jun 13 07:39:59 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 13 Jun 2006 06:39:59 -0500
Subject: [Rspec-devel] rspec, duplication in setup, etc.
In-Reply-To: <57c63afe0606130413v7d23f263ob675664ab1c5d9ed@mail.gmail.com>
References: <2f288f8c0606122120j7f851fa6g3878287b583b69db@mail.gmail.com>
	<57c63afe0606130413v7d23f263ob675664ab1c5d9ed@mail.gmail.com>
Message-ID: <57c63afe0606130439l13b5affte2412f6572e1a65a@mail.gmail.com>

> From: Nate Austin <navision at gmail.com>
>
> This adds an additional level of indirection for the setup and the
> contextual naming that allows the duplication to be removed.  I think
> it does so without loss of clarity, but that is, of course,
> subjective.
>
>  behavior_for person do
>   context of_age, citizen do
>     specify "can vote in an election" do
>       @person.can_vote?.should_be true
>     end
>   end
>
>   context not_of_age, non_citizen do
>     specify "can vote in an election" do
>       @person.can_vote?.should_be false
>     end
>   end
> end
>
> person {  // I don't know the proper syntax for something like this,
> so this is somewhat pseudo-ish
>     // is this really necessary, or could the type be used in the
> behavior_for line?
>
>   contextual_name do
>     "A person"
>   end
>
>   construct_with(args) do
>     Person.new(args)  // this probably isn't needed.  Maybe just get
> the type back and have framework call new?  My Ruby-foo is weak.
>   end
>
> }
>
> of_age {
>   contextual_name do
>     "18 years old"
>   end
>
>   constructor_contribution do
>     birthdate => 18.years_ago
>   end
> }
>
> citizen {
>   contextual_name do
>     "is a citizen"
>   end
>
>   constructor_contribution do
>     citizen => true
>   end
> }
>
>
> Also, not required for this example, but could also have an optional
> modify(object) method that would just allow you to bombard the poor
> constructed object with all sorts of nasty side-effects.
> So, framework would gather all of the various BehaviorParts for the
> context, gather the constructor_contributions, construct the object
> and put it in a variable, pass it to all of the modify() methods, and
> execute the specs
> The display would be similar to this:
>
> Person:
>
>   - 18 years old, is a citizen
>     - can vote in an election
>     - can serve in the military
>   - 17 years old, is a citizen
>     - can not vote in an election
>     - can not serve in the military
>

Interesting idea. Thank you for taking the time to post it.

In our conversation, one of the things you brought up was that
duplication becomes more of a problem with more complex setups
(multiple objects, etc). My instinct is that this will start to break
down in terms of clarity as you start to add more objects with varying
states.

Since the framework would have to assemble the context line in the
output, the more variables you add, the more cumbersome the output
would become:

17 years old, is a citizen, has a clean record, martial status is
single, is currently unemployed

vs

jobless single 17 year old citizen with a clean record

What if we were also interested in when a person can legally drink?
Now "of_age" needs to be rethought - perhaps "of_voting_age" and
"of_drinking_age". So then the law changes so that voting age and
military induction age differ. Now we have to break this down to
"of_age_to_vote", "of_age_to_serve" and "of_age_to_drink" and in order
to know what those are while looking at the code, I have to leave the
current context to go look at these various setups in order to know
the rules (what age IS of age to drink, etc).

Thoughts?

From aslak.hellesoy at gmail.com  Thu Jun 15 10:30:56 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 09:30:56 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
	<57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
	<57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>
Message-ID: <8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>

On 6/11/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 6/11/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > Heading out right now. I'll do this later tonight, in spite of my
> > objection. But I still object.
>
> OK. I checked it in. To see this fail, stand in vendor/rspec_on_rails
> and say 'rake spec'.
>

Yep, I get the same error too.

One problem with going for dots instead of underscores is test2spec.
To explain why, let me highlight how it now works.

For each test class to be translated, test2spec creates a parse tree
(using ParseTree). Then this tree is transformed, replacing class with
context, test_ with specify and assert_ with should. Finally the
transformed tree is written to disk using Ruby2Ruby (which takes a
parse tree as input and spits out ruby source code).

The transformation step is somewhat complex (see sexp_transformer.rb).
However, it would be *way* more complex if we were to translate into a
dotted syntax, because dotted calls are much more verbose in parse
tree.

Therefore, test2spec will always output specs using the underscored syntax.

This convention would conflict with the rest of RSpec not supporting
underscores.
There are several ways to deal with this (assuming we go back and say
that underscores are not supported):

1) We post-process test2spec's generated specs with a simple regexp
tool that would replace all should underscores with dots.

2) We print a big warning (in the docs, and also at the console when
running test2spec) that test2spec's output is using underscores and
may therefore break in some cases.

Which one do you prefer?
Aslak

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

From ryan at platte.name  Thu Jun 15 10:43:59 2006
From: ryan at platte.name (Ryan Platte)
Date: Thu, 15 Jun 2006 09:43:59 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
	<57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
	<57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>
	<8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>
Message-ID: <2f1a1dcb0606150743k5ab968adt9e4226e5b41821e@mail.gmail.com>

On 6/15/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> 1) We post-process test2spec's generated specs with a simple regexp
> tool that would replace all should underscores with dots.
>
> 2) We print a big warning (in the docs, and also at the console when
> running test2spec) that test2spec's output is using underscores and
> may therefore break in some cases.
>
> Which one do you prefer?

I don't know if it's a vote, but #1 sure looks like a nicer option.
It's just an implementation detail, and the code is being generated,
so why not go ahead and do a manual transform?

There's enough of an impedance mismatch between rSpec and normal
coding as it is, I think it would be best to get the tool out of the
way wherever possible.

-- 
Ryan Platte

From dastels at daveastels.com  Thu Jun 15 11:28:21 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 15 Jun 2006 10:28:21 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
	<57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
	<57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>
	<8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>
Message-ID: <3A76DB56-6887-4998-98E2-731BEDF43B32@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- - -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15-Jun-06, at 9:30 AM, aslak hellesoy wrote:


> There are several ways to deal with this (assuming we go back and say
> that underscores are not supported):
>
> 1) We post-process test2spec's generated specs with a simple regexp
> tool that would replace all should underscores with dots.
>
> 2) We print a big warning (in the docs, and also at the console when
> running test2spec) that test2spec's output is using underscores and
> may therefore break in some cases.
>
> Which one do you prefer?

I'd vote for 3) Do the appropriate translation of the parse trees to  
generate dotted output

Dave

- - -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEkXZBauez/L4x7g4RAhx0AKDA3ZC/5KPMaUsQBZec/9z2h8Kk8wCg23Zf
OjXt/52NcIAgxBJVW8UULBA=
=u+cy
- - -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEkXZVauez/L4x7g4RAuXdAKDCNEJCdotRy9yG5rSB+HwUxtIk0gCbB2cA
nM1PO2+bU288GRpZlebBOSw=
=Iyqc
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEkXyVauez/L4x7g4RAnKAAJkBKulJBXQrlVRWyrLdY2m7E2xy6ACg1W7Z
DaeNqDuu65Gwx6zUHsyu3yw=
=Xyjd
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Thu Jun 15 11:52:09 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 10:52:09 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <3A76DB56-6887-4998-98E2-731BEDF43B32@daveastels.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
	<57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
	<57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>
	<8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>
	<3A76DB56-6887-4998-98E2-731BEDF43B32@daveastels.com>
Message-ID: <8d961d900606150852o7a71474cj4072c07cf2627edc@mail.gmail.com>

> > There are several ways to deal with this (assuming we go back and say
> > that underscores are not supported):
> >
> > 1) We post-process test2spec's generated specs with a simple regexp
> > tool that would replace all should underscores with dots.
> >
> > 2) We print a big warning (in the docs, and also at the console when
> > running test2spec) that test2spec's output is using underscores and
> > may therefore break in some cases.
> >
> > Which one do you prefer?
>
> I'd vote for 3) Do the appropriate translation of the parse trees to
> generate dotted output
>

Why do you prefer this over 1) ?
3) would require generation of much more complex s-expressions than
with underscores.
I think 1) would produce the same result, with much simpler code.

Aslak

> Dave
>

From dastels at daveastels.com  Thu Jun 15 12:11:47 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 15 Jun 2006 11:11:47 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <8d961d900606150852o7a71474cj4072c07cf2627edc@mail.gmail.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
	<57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
	<57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>
	<8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>
	<3A76DB56-6887-4998-98E2-731BEDF43B32@daveastels.com>
	<8d961d900606150852o7a71474cj4072c07cf2627edc@mail.gmail.com>
Message-ID: <C61E0E3C-034C-453E-824E-7858D2274EE1@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15-Jun-06, at 10:52 AM, aslak hellesoy wrote:

>>> There are several ways to deal with this (assuming we go back and  
>>> say
>>> that underscores are not supported):
>>>
>>> 1) We post-process test2spec's generated specs with a simple regexp
>>> tool that would replace all should underscores with dots.
>>>
>>> 2) We print a big warning (in the docs, and also at the console when
>>> running test2spec) that test2spec's output is using underscores and
>>> may therefore break in some cases.
>>>
>>> Which one do you prefer?
>>
>> I'd vote for 3) Do the appropriate translation of the parse trees to
>> generate dotted output
>>
>
> Why do you prefer this over 1) ?
> 3) would require generation of much more complex s-expressions than
> with underscores.
> I think 1) would produce the same result, with much simpler code.

Of the two options presented, I would vote for 1), but 3) strikes me  
to be more robust, and "the right way".  If you are manipulating  
syntax trees anyway, why not just do it all there.  Using a two stage  
process to do what is essentially a single operation seems wrong and  
more error prone.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEkYbDauez/L4x7g4RAs38AKCXQpDcJiV8CdMpnkgFzknwIZyumACfYlXT
dlt4JJUSLRjWxymkL1B27do=
=gF26
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Thu Jun 15 13:02:58 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 12:02:58 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <C61E0E3C-034C-453E-824E-7858D2274EE1@daveastels.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
	<57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
	<57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>
	<8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>
	<3A76DB56-6887-4998-98E2-731BEDF43B32@daveastels.com>
	<8d961d900606150852o7a71474cj4072c07cf2627edc@mail.gmail.com>
	<C61E0E3C-034C-453E-824E-7858D2274EE1@daveastels.com>
Message-ID: <8d961d900606151002w44f137ect1544a62b1b9accd0@mail.gmail.com>

On 6/15/06, David Astels <dastels at daveastels.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 15-Jun-06, at 10:52 AM, aslak hellesoy wrote:
>
> >>> There are several ways to deal with this (assuming we go back and
> >>> say
> >>> that underscores are not supported):
> >>>
> >>> 1) We post-process test2spec's generated specs with a simple regexp
> >>> tool that would replace all should underscores with dots.
> >>>
> >>> 2) We print a big warning (in the docs, and also at the console when
> >>> running test2spec) that test2spec's output is using underscores and
> >>> may therefore break in some cases.
> >>>
> >>> Which one do you prefer?
> >>
> >> I'd vote for 3) Do the appropriate translation of the parse trees to
> >> generate dotted output
> >>
> >
> > Why do you prefer this over 1) ?
> > 3) would require generation of much more complex s-expressions than
> > with underscores.
> > I think 1) would produce the same result, with much simpler code.
>
> Of the two options presented, I would vote for 1), but 3) strikes me
> to be more robust, and "the right way".  If you are manipulating
> syntax trees anyway, why not just do it all there.  Using a two stage
> process to do what is essentially a single operation seems wrong and
> more error prone.
>

It might be more "right", but the post processing is IMO more
pragmatic, or "simple".
I think this will become more if you try to implement option 3).
Feel free to give it a stab. It's not a walk in the park.

Aslak

> Dave
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEkYbDauez/L4x7g4RAs38AKCXQpDcJiV8CdMpnkgFzknwIZyumACfYlXT
> dlt4JJUSLRjWxymkL1B27do=
> =gF26
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Thu Jun 15 13:04:18 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 12:04:18 -0500
Subject: [Rspec-devel] underscores vs dots revisited
In-Reply-To: <8d961d900606151002w44f137ect1544a62b1b9accd0@mail.gmail.com>
References: <57c63afe0606111337w383d71adn3366b8401d5a35d4@mail.gmail.com>
	<8d961d900606111408u2174e68bs222d254d756bd94b@mail.gmail.com>
	<57c63afe0606111425q4d6679a8ve0da39acd70e36bf@mail.gmail.com>
	<57c63afe0606111545h6f7608b8lc7c009c5fe8705ce@mail.gmail.com>
	<8d961d900606150730h6f9dc4e7xa82794d4c9d015b4@mail.gmail.com>
	<3A76DB56-6887-4998-98E2-731BEDF43B32@daveastels.com>
	<8d961d900606150852o7a71474cj4072c07cf2627edc@mail.gmail.com>
	<C61E0E3C-034C-453E-824E-7858D2274EE1@daveastels.com>
	<8d961d900606151002w44f137ect1544a62b1b9accd0@mail.gmail.com>
Message-ID: <8d961d900606151004y632acd4fxd37c2568c539a979@mail.gmail.com>

> I think this will become more if you try to implement option 3).
I think this will become more APPARENT if you try to implement option 3).

From aslak.hellesoy at gmail.com  Thu Jun 15 13:59:13 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 12:59:13 -0500
Subject: [Rspec-devel] test2spec on rails
Message-ID: <8d961d900606151059j2b474ef8i98ad4eaab25000bf@mail.gmail.com>

I've just released RSpec 0.5.11

The RSpec core has not changed, but the test2spec tool is steadily improving.
It now seems to work ok with Rails.
It also translates 'helper' methods (non-test_ and setup/teardown
ones) properly and moves them to the setup block.

See http://rspec.rubyforge.org/tools/test2spec.html and
http://rspec.rubyforge.org/tools/rails.html for updated doco.

OK, I'm off trying to test2spec all of RSpec's own tests. I'll bloody
get them all to pass!

Aslak

Cheers,
Aslak

From aslak.hellesoy at gmail.com  Thu Jun 15 15:00:03 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 14:00:03 -0500
Subject: [Rspec-devel] All test2spec translations of RSpec's own tests are
	passing - FAST
Message-ID: <8d961d900606151200v1ad6c1b9n4469c170767803ac@mail.gmail.com>

Woohoo

In order to see it in action, get the latest source from svn, and run
rake test2spec_test

All translated specs are passing.

Poke around in spec/translated to see the translated specs. If you
want to do this step by step, run:

rake test2spec
bin/spec spec

In order to make this work I had to move all 'fixture' classes (custom
classes used by the tests) to test/test_classes.rb.

I think this is a milestone for RSpec adoption.

Benchmark:
In order to ensure the same number of specs/tests are run I renamed
the test files that are not translated
(sexp_transformer_assertion_test.rb and sexp_transformer_test.rb)

rake test2spec_test : 0.29 secs on average
rake test: 0.85 secs on average

(OS X 10.4.6, 1.5 GHz PowerPC G4, 1GB DDR SDRAM)

RSpec (at least for this example) is 3 times faster than Test::Unit.

Cheers,
Aslak

From dastels at daveastels.com  Thu Jun 15 15:07:29 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 15 Jun 2006 14:07:29 -0500
Subject: [Rspec-devel] All test2spec translations of RSpec's own tests
	are passing - FAST
In-Reply-To: <8d961d900606151200v1ad6c1b9n4469c170767803ac@mail.gmail.com>
References: <8d961d900606151200v1ad6c1b9n4469c170767803ac@mail.gmail.com>
Message-ID: <B3CE2F7F-B74C-49EF-AE9D-A7ACAE0302B5@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> RSpec (at least for this example) is 3 times faster than Test::Unit.

If this is true in the general case... it's a BIG selling feature

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEka/xauez/L4x7g4RAsjEAKDeBrFUzbs7YtgxZ+waM2T7TNKGUgCg2QBB
iV+mjlWEBULJ+rMIXIGsQg8=
=HGAW
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Thu Jun 15 15:17:33 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 14:17:33 -0500
Subject: [Rspec-devel] All test2spec translations of RSpec's own tests
	are passing - FAST
In-Reply-To: <B3CE2F7F-B74C-49EF-AE9D-A7ACAE0302B5@daveastels.com>
References: <8d961d900606151200v1ad6c1b9n4469c170767803ac@mail.gmail.com>
	<B3CE2F7F-B74C-49EF-AE9D-A7ACAE0302B5@daveastels.com>
Message-ID: <8d961d900606151217m577f79c8h81309610532f101c@mail.gmail.com>

On 6/15/06, David Astels <dastels at daveastels.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> >
> > RSpec (at least for this example) is 3 times faster than Test::Unit.
>
> If this is true in the general case... it's a BIG selling feature
>

I don't think it can be applied for the general case.
Most times, the bulk of the time is spent in the code being tested
(spit), in which
case the speediness of RSpec versus Test::Unit will be negligeable.

And for well-factored, I/O-abstracted code (i.e that can be tested
almost excusively w/o any I/O by using mocks) the time spent in code
will be so small that the increased speed of RSpec will not be that
significant - since everything is fast in the first place.

So for a set of tests with Test::Unit that takes, say 10 seconds, the
corresponding
RSpec specs would probably take at least 9 seconds.

It would be great to get some benchmarks from others who dare to migrate their
tests with test2spec.

Aslak

> Dave
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEka/xauez/L4x7g4RAsjEAKDeBrFUzbs7YtgxZ+waM2T7TNKGUgCg2QBB
> iV+mjlWEBULJ+rMIXIGsQg8=
> =HGAW
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Thu Jun 15 15:27:09 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 14:27:09 -0500
Subject: [Rspec-devel] All test2spec translations of RSpec's own tests
	are passing - FAST
In-Reply-To: <8d961d900606151200v1ad6c1b9n4469c170767803ac@mail.gmail.com>
References: <8d961d900606151200v1ad6c1b9n4469c170767803ac@mail.gmail.com>
Message-ID: <8d961d900606151227k29402bd7qd008bdaee9018b1a@mail.gmail.com>

On 6/15/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> Woohoo
>
> In order to see it in action, get the latest source from svn, and run
> rake test2spec_test
>
> All translated specs are passing.
>
> Poke around in spec/translated to see the translated specs. If you
> want to do this step by step, run:
>
> rake test2spec
> bin/spec spec
>
> In order to make this work I had to move all 'fixture' classes (custom
> classes used by the tests) to test/test_classes.rb.
>
> I think this is a milestone for RSpec adoption.
>
> Benchmark:
> In order to ensure the same number of specs/tests are run I renamed
> the test files that are not translated
> (sexp_transformer_assertion_test.rb and sexp_transformer_test.rb)
>
> rake test2spec_test : 0.29 secs on average
> rake test: 0.85 secs on average
>
> (OS X 10.4.6, 1.5 GHz PowerPC G4, 1GB DDR SDRAM)
>
> RSpec (at least for this example) is 3 times faster than Test::Unit.
>

This should be taken with a grain of salt, because looking closer I
realised that 3
of the tests didn't translate (so there are less specs than tests). The ones not
translating are:

Spec::Runner::ContextTest
TestCaseExtTest
Spec::Api::MockTest

FWIW, this is probably due to bugs in RubyToRuby.
I have contacted the RubyToRuby authors and asked them to make it a
separate project. We currently have a fork of the RubyToRuby code in
RSpec since it's not
packaged as a gem yet.

Cheers,
Aslak

> Cheers,
> Aslak
>

From aslak.hellesoy at gmail.com  Thu Jun 15 18:28:45 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 17:28:45 -0500
Subject: [Rspec-devel] 0.5.12 released, now with --diff option
Message-ID: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com>

Release notes here:
http://rubyforge.org/frs/shownotes.php?release_id=5689

More info on diffing here:
http://rspec.rubyforge.org/tools/spec.html

Note that anyone using the --diff option must also gem install lcs-diff
And all RSpec developers must of course install it in order to run the tests.

Enjoy!
Aslak

From aslak.hellesoy at gmail.com  Thu Jun 15 19:50:30 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 15 Jun 2006 18:50:30 -0500
Subject: [Rspec-devel] Remove doc folder from gem?
Message-ID: <8d961d900606151650q6268859aw8ebdd2dcce3acf52@mail.gmail.com>

The RSpec gem is now 0.5 Mb

If we remove the doc folder from the gem, it's 45 Kb

Shall we? I don't see a lot of value having the website *.page files
and images in the gem.

WDYT?

Aslak

From dastels at daveastels.com  Thu Jun 15 20:32:46 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 15 Jun 2006 19:32:46 -0500
Subject: [Rspec-devel] Remove doc folder from gem?
In-Reply-To: <8d961d900606151650q6268859aw8ebdd2dcce3acf52@mail.gmail.com>
References: <8d961d900606151650q6268859aw8ebdd2dcce3acf52@mail.gmail.com>
Message-ID: <FB9CDEE3-0388-492F-97CB-33A5DCEAB00A@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15-Jun-06, at 6:50 PM, aslak hellesoy wrote:

> The RSpec gem is now 0.5 Mb
>
> If we remove the doc folder from the gem, it's 45 Kb
>
> Shall we? I don't see a lot of value having the website *.page files
> and images in the gem.
>
> WDYT?

+10

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEkfwuauez/L4x7g4RAs0nAKCN5TsMOadPXxOvTe/gcBZ0qlTH3gCfSIny
3y4w3Ve+JJ47Bj9zWh7qKcA=
=5WrY
-----END PGP SIGNATURE-----

From dchelimsky at gmail.com  Thu Jun 15 22:34:11 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 15 Jun 2006 21:34:11 -0500
Subject: [Rspec-devel] Remove doc folder from gem?
In-Reply-To: <FB9CDEE3-0388-492F-97CB-33A5DCEAB00A@daveastels.com>
References: <8d961d900606151650q6268859aw8ebdd2dcce3acf52@mail.gmail.com>
	<FB9CDEE3-0388-492F-97CB-33A5DCEAB00A@daveastels.com>
Message-ID: <57c63afe0606151934j1af67910xfd908b32d7da7d6@mail.gmail.com>

On 6/15/06, David Astels <dastels at daveastels.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 15-Jun-06, at 6:50 PM, aslak hellesoy wrote:
>
> > The RSpec gem is now 0.5 Mb
> >
> > If we remove the doc folder from the gem, it's 45 Kb
> >
> > Shall we? I don't see a lot of value having the website *.page files
> > and images in the gem.
> >
> > WDYT?
>
> +10

+1

From svenfuchs at artweb-design.de  Fri Jun 16 00:26:10 2006
From: svenfuchs at artweb-design.de (Sven Fuchs)
Date: Fri, 16 Jun 2006 06:26:10 +0200
Subject: [Rspec-devel] 0.5.12 released, now with --diff option
In-Reply-To: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com>
References: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com>
Message-ID: <449232E2.8040303@artweb-design.de>

I get a "buffer error" when trying to install 0.5.12 (both remote and 
local)

Attempting local installation of 'rspec_generator'
Local gem file not found: rspec_generator*.gem
Attempting remote installation of 'rspec_generator'
Install required dependency rspec? [Yn]  Y
ERROR:  While executing gem ... (Zlib::BufError)
     buffer error


0.5.11 works though.

--
Sven

aslak hellesoy schrieb:
> Release notes here:
> http://rubyforge.org/frs/shownotes.php?release_id=5689
> 
> More info on diffing here:
> http://rspec.rubyforge.org/tools/spec.html
> 
> Note that anyone using the --diff option must also gem install lcs-diff
> And all RSpec developers must of course install it in order to run the tests.
> 
> Enjoy!
> Aslak
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
> 


From aslak.hellesoy at gmail.com  Fri Jun 16 12:12:31 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 16 Jun 2006 11:12:31 -0500
Subject: [Rspec-devel] 0.5.12 released, now with --diff option
In-Reply-To: <449232E2.8040303@artweb-design.de>
References: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com>
	<449232E2.8040303@artweb-design.de>
Message-ID: <8d961d900606160912u7d57d7e4sbf370b49ae28ac93@mail.gmail.com>

On 6/15/06, Sven Fuchs <svenfuchs at artweb-design.de> wrote:
> I get a "buffer error" when trying to install 0.5.12 (both remote and
> local)
>
> Attempting local installation of 'rspec_generator'
> Local gem file not found: rspec_generator*.gem
> Attempting remote installation of 'rspec_generator'
> Install required dependency rspec? [Yn]  Y
> ERROR:  While executing gem ... (Zlib::BufError)
>      buffer error
>

I have re-released 0.5.12.
The new gem is ok.

>From now on the gems don't include the doc folder (website sources),
so it has shrinked from 500 Kb to 45 Kb. This will hopefully reduce the
chances of corrupt gems in the future.

(We're using http://xforge.rubyforge.org/ to publish releases and it
might be that it doesn't handle very big binary files well).

Since yesterday, I've also added to 0.5.12 a HTML formatter.
http://rspec.rubyforge.org/tools/rake.html
http://rspec.rubyforge.org/tools/failing_examples.html

Aslak

>
> 0.5.11 works though.
>
> --
> Sven
>
> aslak hellesoy schrieb:
> > Release notes here:
> > http://rubyforge.org/frs/shownotes.php?release_id=5689
> >
> > More info on diffing here:
> > http://rspec.rubyforge.org/tools/spec.html
> >
> > Note that anyone using the --diff option must also gem install lcs-diff
> > And all RSpec developers must of course install it in order to run the tests.
> >
> > Enjoy!
> > Aslak
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Fri Jun 16 14:42:15 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 16 Jun 2006 13:42:15 -0500
Subject: [Rspec-devel] 5.should.be true
Message-ID: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>

This passes.

At first it looked weird to me, but I guess it makes sense - Ruby's
if() behaves the same way.

In fact,
anything.should.be true

passes as long as anything is not nil.

Is everybody ok with this?

Aslak

From dastels at daveastels.com  Fri Jun 16 15:39:13 2006
From: dastels at daveastels.com (David Astels)
Date: Fri, 16 Jun 2006 14:39:13 -0500
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
Message-ID: <7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 16-Jun-06, at 1:42 PM, aslak hellesoy wrote:

> This passes.
>
> At first it looked weird to me, but I guess it makes sense - Ruby's
> if() behaves the same way.
>
> In fact,
> anything.should.be true
>
> passes as long as anything is not nil.

or not false

>
> Is everybody ok with this?

it follows Ruby's notion of true & false, I don;t particularly like  
it or agree with it, but that's how it is.  I think we should respect  
(or at least support) Ruby's notions about such things.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEkwjhauez/L4x7g4RAm68AKDU7iOny6X6Ewvg/NZkSgZXnJgAZACgyE6u
ZrJWlQJJ6Kz+Yx8FK91QZE0=
=dpQE
-----END PGP SIGNATURE-----

From dastels at daveastels.com  Fri Jun 16 15:44:44 2006
From: dastels at daveastels.com (David Astels)
Date: Fri, 16 Jun 2006 14:44:44 -0500
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
Message-ID: <7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 16-Jun-06, at 2:39 PM, David Astels wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 16-Jun-06, at 1:42 PM, aslak hellesoy wrote:
>
>> This passes.
>>
>> At first it looked weird to me, but I guess it makes sense - Ruby's
>> if() behaves the same way.
>>
>> In fact,
>> anything.should.be true
>>
>> passes as long as anything is not nil.
>
> or not false

um.. AND not false

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEkwotauez/L4x7g4RAvomAJ9c2OsytpSdgaK/FnX6J2U6Rfl76QCfWMwQ
MqZJNYK7nVTwSTlNt6xrGpY=
=89bd
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Fri Jun 16 15:50:04 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 16 Jun 2006 14:50:04 -0500
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
Message-ID: <8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>

On 6/16/06, David Astels <dastels at daveastels.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 16-Jun-06, at 2:39 PM, David Astels wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > On 16-Jun-06, at 1:42 PM, aslak hellesoy wrote:
> >
> >> This passes.
> >>
> >> At first it looked weird to me, but I guess it makes sense - Ruby's
> >> if() behaves the same way.
> >>
> >> In fact,
> >> anything.should.be true
> >>
> >> passes as long as anything is not nil.
> >
> > or not false
>
> um.. AND not false
>

false is not nil, so i had included that already in my statement ;-)

Aslak

> Dave
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEkwotauez/L4x7g4RAvomAJ9c2OsytpSdgaK/FnX6J2U6Rfl76QCfWMwQ
> MqZJNYK7nVTwSTlNt6xrGpY=
> =89bd
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dastels at daveastels.com  Fri Jun 16 16:00:25 2006
From: dastels at daveastels.com (David Astels)
Date: Fri, 16 Jun 2006 15:00:25 -0500
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
Message-ID: <95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 16-Jun-06, at 2:50 PM, aslak hellesoy wrote:

> On 6/16/06, David Astels <dastels at daveastels.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On 16-Jun-06, at 2:39 PM, David Astels wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>
>>> On 16-Jun-06, at 1:42 PM, aslak hellesoy wrote:
>>>
>>>> This passes.
>>>>
>>>> At first it looked weird to me, but I guess it makes sense - Ruby's
>>>> if() behaves the same way.
>>>>
>>>> In fact,
>>>> anything.should.be true
>>>>
>>>> passes as long as anything is not nil.
>>>
>>> or not false
>>
>> um.. AND not false
>>
>
> false is not nil, so i had included that already in my statement ;-)

false.should.be true will fail... or we have a bug
and nil.should.be true will fail

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEkw3Zauez/L4x7g4RAn54AKDiEdL63+thVs/Q6opMBq5o+d8jkwCgpDlS
bk1TFVlvNpwC/ryKq9CI8T8=
=q09O
-----END PGP SIGNATURE-----

From lists-rspec at shopwatch.org  Fri Jun 16 16:08:16 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Fri, 16 Jun 2006 16:08:16 -0400
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
	<95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
Message-ID: <44930FB0.2070407@rubyforge.org>

David Astels wrote:
> false.should.be true will fail... or we have a bug

I think you're missing out on the huge government market that way.

Jay


From jim.weirich at gmail.com  Fri Jun 16 16:16:31 2006
From: jim.weirich at gmail.com (Jim Weirich)
Date: Fri, 16 Jun 2006 16:16:31 -0400
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
	<95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
Message-ID: <d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>

On 6/16/06, David Astels <dastels at daveastels.com> wrote:
>
>
> false.should.be true will fail... or we have a bug
> and nil.should.be true will fail


Is there a way to distinguish between "should be treated as true in a Ruby
conditional" and "should be the object represented by 'true'"? (also same
question for false and nil)

-- 
-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060616/b6b7522a/attachment.htm 

From brasten at nagilum.com  Fri Jun 16 16:29:54 2006
From: brasten at nagilum.com (Brasten Sager)
Date: Fri, 16 Jun 2006 13:29:54 -0700
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
	<95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
	<d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>
Message-ID: <1B87C5E4-ADAB-4803-95C7-242C3289710E@nagilum.com>

It's not pretty, but....

irb(main):019:0> im_true = true         #=> true
irb(main):020:0> im_true.should_be_instance_of TrueClass		#=> nil
irb(main):021:0> im_true_too = "true" 		#=> "true"
irb(main):022:0> im_true_too.should_be true		#=> nil
irb(main):023:0> im_true_too.should_be_instance_of TrueClass
Spec::Api::ExpectationNotMetError: "true" should be instance_of  
TrueClass
         from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/spec/ 
api/helper/should_base.rb:28:in `fail_with_message'
         from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/spec/ 
api/helper/should_helper.rb:53:in `method_missing'
         from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/spec/ 
api/sugar.rb:15:in `method_missing'
         from (irb):23

On Jun 16, 2006, at 1:16 PM, Jim Weirich wrote:

> On 6/16/06, David Astels <dastels at daveastels.com> wrote:
>
> false.should.be true will fail... or we have a bug
> and nil.should.be true will fail
>
> Is there a way to distinguish between "should be treated as true in  
> a Ruby conditional" and "should be the object represented by  
> 'true'"? (also same question for false and nil)
>
> -- 
> -- 
> -- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
> -----------------------------------------------------------------
> "Beware of bugs in the above code; I have only proved it correct,
> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Fri Jun 16 16:55:28 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 16 Jun 2006 15:55:28 -0500
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <1B87C5E4-ADAB-4803-95C7-242C3289710E@nagilum.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
	<95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
	<d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>
	<1B87C5E4-ADAB-4803-95C7-242C3289710E@nagilum.com>
Message-ID: <8d961d900606161355j1dd0be73t21faeaf57aabd5de@mail.gmail.com>

On 6/16/06, Brasten Sager <brasten at nagilum.com> wrote:
> It's not pretty, but....
>
> irb(main):019:0> im_true = true         #=> true
> irb(main):020:0> im_true.should_be_instance_of TrueClass                #=> nil
> irb(main):021:0> im_true_too = "true"           #=> "true"
> irb(main):022:0> im_true_too.should_be true             #=> nil
> irb(main):023:0> im_true_too.should_be_instance_of TrueClass
> Spec::Api::ExpectationNotMetError: "true" should be instance_of
> TrueClass
>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/spec/
> api/helper/should_base.rb:28:in `fail_with_message'
>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/spec/
> api/helper/should_helper.rb:53:in `method_missing'
>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/spec/
> api/sugar.rb:15:in `method_missing'
>          from (irb):23
>

I don't understand what you're trying to demonstrate.

Aslak

> On Jun 16, 2006, at 1:16 PM, Jim Weirich wrote:
>
> > On 6/16/06, David Astels <dastels at daveastels.com> wrote:
> >
> > false.should.be true will fail... or we have a bug
> > and nil.should.be true will fail
> >
> > Is there a way to distinguish between "should be treated as true in
> > a Ruby conditional" and "should be the object represented by
> > 'true'"? (also same question for false and nil)
> >
> > --
> > --
> > -- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
> > -----------------------------------------------------------------
> > "Beware of bugs in the above code; I have only proved it correct,
> > not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> > _______________________________________________
> > 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 brasten at nagilum.com  Fri Jun 16 17:06:37 2006
From: brasten at nagilum.com (Brasten Sager)
Date: Fri, 16 Jun 2006 14:06:37 -0700
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <8d961d900606161355j1dd0be73t21faeaf57aabd5de@mail.gmail.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
	<95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
	<d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>
	<1B87C5E4-ADAB-4803-95C7-242C3289710E@nagilum.com>
	<8d961d900606161355j1dd0be73t21faeaf57aabd5de@mail.gmail.com>
Message-ID: <483A0EC2-2A3E-4D69-8196-C2CB78A3F08E@nagilum.com>

I was replying to the question of whether it was possible to  
distinguish between something being true in the Ruby conditional  
sense and actually being true.  I was showing it's doable.  Which is  
useful if you need to make sure the the object is literally set to  
true, and not simply checking that it's not nil (or false).

Perhaps I misunderstood the question.

On Jun 16, 2006, at 1:55 PM, aslak hellesoy wrote:

> On 6/16/06, Brasten Sager <brasten at nagilum.com> wrote:
>> It's not pretty, but....
>>
>> irb(main):019:0> im_true = true         #=> true
>> irb(main):020:0> im_true.should_be_instance_of  
>> TrueClass                #=> nil
>> irb(main):021:0> im_true_too = "true"           #=> "true"
>> irb(main):022:0> im_true_too.should_be true             #=> nil
>> irb(main):023:0> im_true_too.should_be_instance_of TrueClass
>> Spec::Api::ExpectationNotMetError: "true" should be instance_of
>> TrueClass
>>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/ 
>> spec/
>> api/helper/should_base.rb:28:in `fail_with_message'
>>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/ 
>> spec/
>> api/helper/should_helper.rb:53:in `method_missing'
>>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/ 
>> spec/
>> api/sugar.rb:15:in `method_missing'
>>          from (irb):23
>>
>
> I don't understand what you're trying to demonstrate.
>
> Aslak
>
>> On Jun 16, 2006, at 1:16 PM, Jim Weirich wrote:
>>
>>> On 6/16/06, David Astels <dastels at daveastels.com> wrote:
>>>
>>> false.should.be true will fail... or we have a bug
>>> and nil.should.be true will fail
>>>
>>> Is there a way to distinguish between "should be treated as true in
>>> a Ruby conditional" and "should be the object represented by
>>> 'true'"? (also same question for false and nil)
>>>
>>> --
>>> --
>>> -- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
>>> -----------------------------------------------------------------
>>> "Beware of bugs in the above code; I have only proved it correct,
>>> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
>>> _______________________________________________
>>> Rspec-devel mailing list
>>> Rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Fri Jun 16 17:10:47 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 16 Jun 2006 16:10:47 -0500
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
	<95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
	<d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>
Message-ID: <8d961d900606161410g76d7a91aicbf1103dd525e863@mail.gmail.com>

On 6/16/06, Jim Weirich <jim.weirich at gmail.com> wrote:
> On 6/16/06, David Astels <dastels at daveastels.com> wrote:
>
> >
> > false.should.be true will fail... or we have a bug
> > and nil.should.be true will fail
>
>
> Is there a way to distinguish between "should be treated as true in a Ruby
> conditional" and "should be the object represented by 'true'"? (also same
> question for false and nil)
>

Currently not, which is why I partly why I raised the question

What actually happens when we do:

foo = ...
if(foo)
  puts 'true-ish'
end

Does ruby invoke any methods on foo to figure out whether or not to
enter the if block? I have no idea.

In any case, are we right in making RSpec's interpretation of true to
be similar to that of the if expression (yes, if is an expression, not
a statement in Ruby).

-Or would it be more correct to let RSpec handle true and false in a
stricter sense?

Aslak

> --
> --
> -- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
> -----------------------------------------------------------------
> "Beware of bugs in the above code; I have only proved it correct,
> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From aslak.hellesoy at gmail.com  Fri Jun 16 17:17:58 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 16 Jun 2006 16:17:58 -0500
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <483A0EC2-2A3E-4D69-8196-C2CB78A3F08E@nagilum.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
	<95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
	<d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>
	<1B87C5E4-ADAB-4803-95C7-242C3289710E@nagilum.com>
	<8d961d900606161355j1dd0be73t21faeaf57aabd5de@mail.gmail.com>
	<483A0EC2-2A3E-4D69-8196-C2CB78A3F08E@nagilum.com>
Message-ID: <8d961d900606161417g76a606a9jd272e31a7d4f73d4@mail.gmail.com>

On 6/16/06, Brasten Sager <brasten at nagilum.com> wrote:
> I was replying to the question of whether it was possible to
> distinguish between something being true in the Ruby conditional
> sense and actually being true.  I was showing it's doable.  Which is
> useful if you need to make sure the the object is literally set to
> true, and not simply checking that it's not nil (or false).
>
> Perhaps I misunderstood the question.

I don't think so - I just misunderstood your answer.
Now I understand. :-)

Aslak

>
> On Jun 16, 2006, at 1:55 PM, aslak hellesoy wrote:
>
> > On 6/16/06, Brasten Sager <brasten at nagilum.com> wrote:
> >> It's not pretty, but....
> >>
> >> irb(main):019:0> im_true = true         #=> true
> >> irb(main):020:0> im_true.should_be_instance_of
> >> TrueClass                #=> nil
> >> irb(main):021:0> im_true_too = "true"           #=> "true"
> >> irb(main):022:0> im_true_too.should_be true             #=> nil
> >> irb(main):023:0> im_true_too.should_be_instance_of TrueClass
> >> Spec::Api::ExpectationNotMetError: "true" should be instance_of
> >> TrueClass
> >>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/
> >> spec/
> >> api/helper/should_base.rb:28:in `fail_with_message'
> >>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/
> >> spec/
> >> api/helper/should_helper.rb:53:in `method_missing'
> >>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/
> >> spec/
> >> api/sugar.rb:15:in `method_missing'
> >>          from (irb):23
> >>
> >
> > I don't understand what you're trying to demonstrate.
> >
> > Aslak
> >
> >> On Jun 16, 2006, at 1:16 PM, Jim Weirich wrote:
> >>
> >>> On 6/16/06, David Astels <dastels at daveastels.com> wrote:
> >>>
> >>> false.should.be true will fail... or we have a bug
> >>> and nil.should.be true will fail
> >>>
> >>> Is there a way to distinguish between "should be treated as true in
> >>> a Ruby conditional" and "should be the object represented by
> >>> 'true'"? (also same question for false and nil)
> >>>
> >>> --
> >>> --
> >>> -- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
> >>> -----------------------------------------------------------------
> >>> "Beware of bugs in the above code; I have only proved it correct,
> >>> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> >>> _______________________________________________
> >>> Rspec-devel mailing list
> >>> Rspec-devel at rubyforge.org
> >>> http://rubyforge.org/mailman/listinfo/rspec-devel
> >>
> >> _______________________________________________
> >> Rspec-devel mailing list
> >> Rspec-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-devel
> >>
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brasten at nagilum.com  Fri Jun 16 17:44:51 2006
From: brasten at nagilum.com (Brasten Sager)
Date: Fri, 16 Jun 2006 14:44:51 -0700
Subject: [Rspec-devel] 5.should.be true
In-Reply-To: <8d961d900606161417g76a606a9jd272e31a7d4f73d4@mail.gmail.com>
References: <8d961d900606161142i72bd3c00wd6c29c45a4b5f32d@mail.gmail.com>
	<7F95929F-E937-4008-B37D-7F232B0C16BA@daveastels.com>
	<7E8CDC50-FEC1-4381-B3D5-BA0961904846@daveastels.com>
	<8d961d900606161250o321c9b61wd5ff34b250a08b8@mail.gmail.com>
	<95058183-A0D8-4FCE-B9B0-E9039281E817@daveastels.com>
	<d4dd9080606161316q6d288664n46f772bcdbe09158@mail.gmail.com>
	<1B87C5E4-ADAB-4803-95C7-242C3289710E@nagilum.com>
	<8d961d900606161355j1dd0be73t21faeaf57aabd5de@mail.gmail.com>
	<483A0EC2-2A3E-4D69-8196-C2CB78A3F08E@nagilum.com>
	<8d961d900606161417g76a606a9jd272e31a7d4f73d4@mail.gmail.com>
Message-ID: <1909C950-0E22-4EF9-BD5A-7064F3927FC0@nagilum.com>

Sorry, I just kind of pasted the code in there without saying  
anything. :)

Just to clarify what I was demonstrating, both true and any non-nil  
object (except false) will pass "should_be true", but only true will  
pass "should_be_instance_of TrueClass", anything else fails.

If I may add my opinion, I don't like the idea of making rSpec's  
understanding of true and false more strict than Ruby's.  Even though  
{ "Some String".should_be true } passing feels a little strange to  
me, that is how Ruby works, so technically it is correct.

But I'm new here, so... :)

-Brasten

On Jun 16, 2006, at 2:17 PM, aslak hellesoy wrote:

> On 6/16/06, Brasten Sager <brasten at nagilum.com> wrote:
>> I was replying to the question of whether it was possible to
>> distinguish between something being true in the Ruby conditional
>> sense and actually being true.  I was showing it's doable.  Which is
>> useful if you need to make sure the the object is literally set to
>> true, and not simply checking that it's not nil (or false).
>>
>> Perhaps I misunderstood the question.
>
> I don't think so - I just misunderstood your answer.
> Now I understand. :-)
>
> Aslak
>
>>
>> On Jun 16, 2006, at 1:55 PM, aslak hellesoy wrote:
>>
>>> On 6/16/06, Brasten Sager <brasten at nagilum.com> wrote:
>>>> It's not pretty, but....
>>>>
>>>> irb(main):019:0> im_true = true         #=> true
>>>> irb(main):020:0> im_true.should_be_instance_of
>>>> TrueClass                #=> nil
>>>> irb(main):021:0> im_true_too = "true"           #=> "true"
>>>> irb(main):022:0> im_true_too.should_be true             #=> nil
>>>> irb(main):023:0> im_true_too.should_be_instance_of TrueClass
>>>> Spec::Api::ExpectationNotMetError: "true" should be instance_of
>>>> TrueClass
>>>>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/
>>>> spec/
>>>> api/helper/should_base.rb:28:in `fail_with_message'
>>>>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/
>>>> spec/
>>>> api/helper/should_helper.rb:53:in `method_missing'
>>>>          from /opt/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/lib/
>>>> spec/
>>>> api/sugar.rb:15:in `method_missing'
>>>>          from (irb):23
>>>>
>>>
>>> I don't understand what you're trying to demonstrate.
>>>
>>> Aslak
>>>
>>>> On Jun 16, 2006, at 1:16 PM, Jim Weirich wrote:
>>>>
>>>>> On 6/16/06, David Astels <dastels at daveastels.com> wrote:
>>>>>
>>>>> false.should.be true will fail... or we have a bug
>>>>> and nil.should.be true will fail
>>>>>
>>>>> Is there a way to distinguish between "should be treated as  
>>>>> true in
>>>>> a Ruby conditional" and "should be the object represented by
>>>>> 'true'"? (also same question for false and nil)
>>>>>
>>>>> --
>>>>> --
>>>>> -- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
>>>>> -----------------------------------------------------------------
>>>>> "Beware of bugs in the above code; I have only proved it correct,
>>>>> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
>>>>> _______________________________________________
>>>>> Rspec-devel mailing list
>>>>> Rspec-devel at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>
>>>> _______________________________________________
>>>> Rspec-devel mailing list
>>>> Rspec-devel at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>>>
>>> _______________________________________________
>>> Rspec-devel mailing list
>>> Rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From brasten at nagilum.com  Sat Jun 17 03:09:17 2006
From: brasten at nagilum.com (Brasten Sager)
Date: Sat, 17 Jun 2006 00:09:17 -0700
Subject: [Rspec-devel] A couple ideas to bat around...
Message-ID: <C7704D35-7052-4917-841F-50D90ED50B4C@nagilum.com>

Hello!  A couple days ago, while converting a couple Rails projects  
to RSpec, I  made some changes to the RSpec code that I wanted to run  
past you guys.

I added a class called ControllerHarness (for lack of a better name)  
that includes TestProcess.  This allowed me to remove almost all the  
code from the ControllerExecution module that was duplicated from  
Rails.  Calling an action on the controller is done through a method  
called "http_service" which is passed a block.  Anyway, yada yada  
yada, here's what it looks like:

 From person_controller_spec.rb:
context "Rendering /create" do
   fixtures :people
   controller_name :person

   specify "should create a new unpersisted Person on GET" do
     http_service :create do				# <-- get performed here.
       @response.should_be_success
       assigns(:person).should_not_be_nil
     end
   end
end

Another interesting benefit is I have access to all the current  
assertions.  This isn't necessarily desirable in the long run, but  
until a more BDD-way of specifying some of these things is available,  
it works.  For example:

...
   specify "should add some items to page" do
     http_service :post, :update_person do
       @response.should_be_success
       lambda {
	assert_rjs :insert_html, :bottom, 'my_div', 'person info'
	assert_rjs :replace_html, 'header_div', 'person name'
       }.should.not.raise
     end
   end
...

A couple extra things I like about it:
- RSpec doesn't have to maintain a near-duplicate copy of Rails'  
testing methods in controller_mixin.rb
- specifications are not being cluttered with a bunch of instance  
variables and methods that are only meaningful in the context of  
spec'ing a controller action. (get, post, @response, @deliveries, etc.)
- Personal Preference: It feels more behavioral specification-ish to  
me.  context --> specify --> http_service (or xml_service/xhr_service  
in the future perhaps?).

Anyway, I've been trying this change on a project for a couple days  
now and it seems to work quite well.  I've uploaded a patch to the  
tracker so you can see what I'm talking about.

Feedback, positive and/or constructively critical, is desired! :)

-Brasten

From lachiec at gmail.com  Sat Jun 17 04:35:30 2006
From: lachiec at gmail.com (Lachie)
Date: Sat, 17 Jun 2006 18:35:30 +1000
Subject: [Rspec-devel] A couple ideas to bat around...
In-Reply-To: <C7704D35-7052-4917-841F-50D90ED50B4C@nagilum.com>
References: <C7704D35-7052-4917-841F-50D90ED50B4C@nagilum.com>
Message-ID: <2c5e719e0606170135k7601f6aan5186f0f5c3ebc797@mail.gmail.com>

I'd like to point out at the beginning of this discussion that the
ControllerExecution code is actaully a near-duplicate of ZenSpider's
Test::Rails::ControllerTestCase which is in turn similar to Rails'
test process.

This distinction in important, because the idea behind ZenSpider's
alternatives is that controller and view tests are separated. Pulling
in the view-only setup stuff was going to come later.

I think this is the way to go, as it allows for finer-grained, more
flexible specification. For example, you could choose to spec
controllers and views together (as Rails' functional tests currently
do) or completely separately (as ZenSpider's can).

-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From itsme213 at hotmail.com  Sat Jun 17 09:58:31 2006
From: itsme213 at hotmail.com (itsme213)
Date: Sat, 17 Jun 2006 08:58:31 -0500
Subject: [Rspec-devel] 0.5.12 released, now with --diff option
References: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com><449232E2.8040303@artweb-design.de>
	<8d961d900606160912u7d57d7e4sbf370b49ae28ac93@mail.gmail.com>
Message-ID: <BAY108-DAV916BCEEBCE2AEF3731E7499800@phx.gbl>

> Since yesterday, I've also added to 0.5.12 a HTML formatter.
> http://rspec.rubyforge.org/tools/rake.html
> http://rspec.rubyforge.org/tools/failing_examples.html

Wow, this looks great. Thanks a bunch!


From brasten at nagilum.com  Sat Jun 17 16:35:35 2006
From: brasten at nagilum.com (Brasten Sager)
Date: Sat, 17 Jun 2006 13:35:35 -0700
Subject: [Rspec-devel] A couple ideas to bat around...
In-Reply-To: <2c5e719e0606170135k7601f6aan5186f0f5c3ebc797@mail.gmail.com>
References: <C7704D35-7052-4917-841F-50D90ED50B4C@nagilum.com>
	<2c5e719e0606170135k7601f6aan5186f0f5c3ebc797@mail.gmail.com>
Message-ID: <28ECEC46-9D12-4305-B0DF-FBB4911EC41C@nagilum.com>

You make a good point.  In fact I really like ZenTest's ideas on that.

I think ultimately it'd be a good idea to allow for separate  
controller/view specifications and strongly encourage it.  The  
TestProcess module that ControllerHarness uses primarily contains the  
plumbing for setting up a controller and making requests.  That  
functionality would be nearly identical in both controller and view  
specs.

The greatest distinction between controller and view specs would be  
the types of expectations one can/does set.  Test::Rails does this by  
separating the assertions that are available to each type of test.   
We can also do this.  For the moment I've included the Rails  
assertions (Test::Unit::Assertions) because there are things they  
check for that I can't yet set expectations on, but as soon as we're  
able to set expectations for most/all those cases,  
Test::Unit::Assertions can be removed.

-Brasten

On Jun 17, 2006, at 1:35 AM, Lachie wrote:

> I'd like to point out at the beginning of this discussion that the
> ControllerExecution code is actaully a near-duplicate of ZenSpider's
> Test::Rails::ControllerTestCase which is in turn similar to Rails'
> test process.
>
> This distinction in important, because the idea behind ZenSpider's
> alternatives is that controller and view tests are separated. Pulling
> in the view-only setup stuff was going to come later.
>
> I think this is the way to go, as it allows for finer-grained, more
> flexible specification. For example, you could choose to spec
> controllers and views together (as Rails' functional tests currently
> do) or completely separately (as ZenSpider's can).
>
> -- 
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From smartgpx at gmail.com  Sun Jun 18 14:06:27 2006
From: smartgpx at gmail.com (DeeJay)
Date: Sun, 18 Jun 2006 19:06:27 +0100
Subject: [Rspec-devel] 0.5.12 released
Message-ID: <533048b70606181106o4a0b7cc3j3f08a9d3679a29b0@mail.gmail.com>

1) there is no 'lcs-diff' gem. will 'diff-lcs' do instead?  :-)}

2) I assumed the number newly appeared on the project webpage
indicated the current release - but it doesn't. Perhaps it
represents the most recent development version? As a mere
would-be user, having the current stable release reported
there would be more useful, please.

3) could someone who understands these things write a few
words about how to use the Mock API please? I can see
what the methods are, but I don't get how to use them.

For instance, my 'real-life' code would need to open a
Windows binary file and read a sequence of 32 bytes from
a specified offset in the file, then interpret and report on those
32 bytes.

How much of this should be mocked for the purposes of
BDD using rspec, and how?

Thanks for your time.

DeeJay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060618/c127146c/attachment.htm 

From brasten at nagilum.com  Sun Jun 18 22:02:45 2006
From: brasten at nagilum.com (Brasten Sager)
Date: Sun, 18 Jun 2006 19:02:45 -0700
Subject: [Rspec-devel] A couple ideas to bat around...
In-Reply-To: <C7704D35-7052-4917-841F-50D90ED50B4C@nagilum.com>
References: <C7704D35-7052-4917-841F-50D90ED50B4C@nagilum.com>
Message-ID: <A968341F-2FA7-4676-8EB8-A79D6BA672B2@nagilum.com>

I've refined my proposal a bit and submitted a second patch for  
discussion.

Gone is the ControllerHarness.  http_service now clones the current  
ExecutionContext and extends it with TestProcess methods.

http_service blocks no longer have Rails' assertions by default.   
While I originally included them for my use, you wouldn't want anyone  
thinking it's a long-term solution.  They can be added quite easily  
with one line of code on a case-by-case basis, as I've done in my  
projects.

The person_controller specification and person model specification  
all function properly in this second patch, using http_service calls,  
so you can see a larger example of what this looks like from a spec- 
writer's point of view.

   -Brasten

On Jun 17, 2006, at 12:09 AM, Brasten Sager wrote:

> Hello!  A couple days ago, while converting a couple Rails projects
> to RSpec, I  made some changes to the RSpec code that I wanted to run
> past you guys.
>
> I added a class called ControllerHarness (for lack of a better name)
> that includes TestProcess.  This allowed me to remove almost all the
> code from the ControllerExecution module that was duplicated from
> Rails.  Calling an action on the controller is done through a method
> called "http_service" which is passed a block.  Anyway, yada yada
> yada, here's what it looks like:
>
>  From person_controller_spec.rb:
> context "Rendering /create" do
>    fixtures :people
>    controller_name :person
>
>    specify "should create a new unpersisted Person on GET" do
>      http_service :create do				# <-- get performed here.
>        @response.should_be_success
>        assigns(:person).should_not_be_nil
>      end
>    end
> end
>
> Another interesting benefit is I have access to all the current
> assertions.  This isn't necessarily desirable in the long run, but
> until a more BDD-way of specifying some of these things is available,
> it works.  For example:
>
> ...
>    specify "should add some items to page" do
>      http_service :post, :update_person do
>        @response.should_be_success
>        lambda {
> 	assert_rjs :insert_html, :bottom, 'my_div', 'person info'
> 	assert_rjs :replace_html, 'header_div', 'person name'
>        }.should.not.raise
>      end
>    end
> ...
>
> A couple extra things I like about it:
> - RSpec doesn't have to maintain a near-duplicate copy of Rails'
> testing methods in controller_mixin.rb
> - specifications are not being cluttered with a bunch of instance
> variables and methods that are only meaningful in the context of
> spec'ing a controller action. (get, post, @response, @deliveries,  
> etc.)
> - Personal Preference: It feels more behavioral specification-ish to
> me.  context --> specify --> http_service (or xml_service/xhr_service
> in the future perhaps?).
>
> Anyway, I've been trying this change on a project for a couple days
> now and it seems to work quite well.  I've uploaded a patch to the
> tracker so you can see what I'm talking about.
>
> Feedback, positive and/or constructively critical, is desired! :)
>
> -Brasten
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From chad at clearwaterassociates.ca  Tue Jun 20 18:10:03 2006
From: chad at clearwaterassociates.ca (Chad Nantais)
Date: Tue, 20 Jun 2006 18:10:03 -0400
Subject: [Rspec-devel] Using symbols for actions not working in controller
	specs
Message-ID: <3de931600606201510n5d77bba0we2d2bf3256b2f941@mail.gmail.com>

With respect to rspec_on_rails,

In my controller,
  response.should_render 'list'
works fine, while
  response.should_render :list
gives me the error:
   undefined method `include?' for :list:Symbol

Why can't I use symbols to represent an action in a spec?  Is this by design?

Thanks,

Chad

From aslak.hellesoy at gmail.com  Tue Jun 20 20:38:23 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 20 Jun 2006 19:38:23 -0500
Subject: [Rspec-devel] Using symbols for actions not working in
	controller specs
In-Reply-To: <3de931600606201510n5d77bba0we2d2bf3256b2f941@mail.gmail.com>
References: <3de931600606201510n5d77bba0we2d2bf3256b2f941@mail.gmail.com>
Message-ID: <8d961d900606201738x46ac16das4ec663956fee1410@mail.gmail.com>

On 6/20/06, Chad Nantais <chad at clearwaterassociates.ca> wrote:
> With respect to rspec_on_rails,
>
> In my controller,
>   response.should_render 'list'
> works fine, while
>   response.should_render :list
> gives me the error:
>    undefined method `include?' for :list:Symbol
>
> Why can't I use symbols to represent an action in a spec?  Is this by design?
>

It sounds like a bug. Please file a bug report at RubyForge.

Cheers,
Aslak

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

From chad at clearwaterassociates.ca  Tue Jun 20 23:12:37 2006
From: chad at clearwaterassociates.ca (Chad Nantais)
Date: Tue, 20 Jun 2006 23:12:37 -0400
Subject: [Rspec-devel] Using symbols for actions not working in
	controller specs
In-Reply-To: <8d961d900606201738x46ac16das4ec663956fee1410@mail.gmail.com>
References: <3de931600606201510n5d77bba0we2d2bf3256b2f941@mail.gmail.com>
	<8d961d900606201738x46ac16das4ec663956fee1410@mail.gmail.com>
Message-ID: <3de931600606202012jc8f137ek7ab19b6493c05115@mail.gmail.com>

Bug filed.

Cheers,

Chad

On 6/20/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/20/06, Chad Nantais <chad at clearwaterassociates.ca> wrote:
> > With respect to rspec_on_rails,
> >
> > In my controller,
> >   response.should_render 'list'
> > works fine, while
> >   response.should_render :list
> > gives me the error:
> >    undefined method `include?' for :list:Symbol
> >
> > Why can't I use symbols to represent an action in a spec?  Is this by design?
> >
>
> It sounds like a bug. Please file a bug report at RubyForge.
>
> Cheers,
> Aslak
>
> > Thanks,
> >
> > Chad
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Wed Jun 21 00:04:34 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 20 Jun 2006 23:04:34 -0500
Subject: [Rspec-devel] 0.5.12 released
In-Reply-To: <533048b70606181106o4a0b7cc3j3f08a9d3679a29b0@mail.gmail.com>
References: <533048b70606181106o4a0b7cc3j3f08a9d3679a29b0@mail.gmail.com>
Message-ID: <8d961d900606202104o1dee0fa1qe74d5ac122cbf92a@mail.gmail.com>

On 6/18/06, DeeJay <smartgpx at gmail.com> wrote:
>
>
> 1) there is no 'lcs-diff' gem. will 'diff-lcs' do instead?  :-)}
>

the diff-lcs will do much better ;-) I have corrected the docs in svn

> 2) I assumed the number newly appeared on the project webpage
> indicated the current release - but it doesn't. Perhaps it
> represents the most recent development version? As a mere
> would-be user, having the current stable release reported
> there would be more useful, please.
>

We occiasionally publish the website between releases to fix general
documentation 'bugs'. Now that the release number is automatically
included in the docs I realise this is a problem.

>From now on we'll try to remember to temporarily bump down the release
number when we do such intermediary website updates.

> 3) could someone who understands these things write a few
> words about how to use the Mock API please? I can see
> what the methods are, but I don't get how to use them.
>

There aren't a lot of examples in the documentation that demonstrate
'good use' of mocks. We'll put some in later.

For more in-depth, general description of how to use mocks, check out
these resources:
http://www.jmock.org/oopsla2004.pdf
http://www.martinfowler.com/articles/mocksArentStubs.html

> For instance, my 'real-life' code would need to open a
> Windows binary file and read a sequence of 32 bytes from
> a specified offset in the file, then interpret and report on those
> 32 bytes.
>
> How much of this should be mocked for the purposes of
> BDD using rspec, and how?
>

As a general rule, don't mock interfaces you don't own. (By mocking I
mean the stricter definition of mocks as described by the references
above).

Write your code in such a way that it has only minimal dependencies on
the File, FileStat, FileUtils etc classes. Logic that interprets file
contents (let's call it processor logic) should be separated from
logic that provides access to that IO (access logic). -Preferrably in
separate classes.

This will allow you to write specs for the processor logic without
needing to access the filesystem at all. You can embed testdata
in-memory and hand it to the processor logic to see that it works as
expected. In this case you're not using a 'mock io', but a stub - a
StringIO object. (stubs don't have expectations)

I have checked in a minimal example that illustrates this.
See examples/io_processor_spec.rb and examples/io_processor.rb

If you want to write a spec for the other part - the part that
actually opens a file (and possibly hands it over to some processor
logic - I would use 2 mocks.
-One for the file (using the more OO Pathname API which is easier to
mock that File)
-One for the processor

See examples/file_accessor_spec.rb and examples/file_accessor.rb

Study the code and try to understand the object converation that this
spec expresses.

I hope these examples will help you get further into the wonders of
mocks. If not, just ask again :-)

HTH,
Aslak

> Thanks for your time.
>
>
> DeeJay
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From smartgpx at gmail.com  Wed Jun 21 12:17:33 2006
From: smartgpx at gmail.com (DeeJay)
Date: Wed, 21 Jun 2006 17:17:33 +0100
Subject: [Rspec-devel] 0.5.12 released (about running specs with ruby or
	spec)
Message-ID: <533048b70606210917n34911ae9y18172e9c726a02c4@mail.gmail.com>

I'm sure everyone knows by now that I am new to all this OO/Ruby/TDD stuff,
but I'm  trying to start getting the right habits by using BDD. But it's a
bootstrapping
process, and I'm not getting the basics... so little things make me wobble a
lot.

If I run examples/file_accessor_spec.rb with ruby, it passes -

examples> ruby file_accessor_spec.rb -fs

A FileAccessor
- should open a file and pass it to the processor's process method

Finished in 0.0 seconds

1 specification, 0 failures

But if I run it through rspec's spec tool, if fails -

examples> spec file_accessor_spec.rb -fs

A FileAccessor
- should open a file and pass it to the processor's process method (FAILED -
1)

1)
MockExpectationError in 'A FileAccessor should open a file and pass it to
the pr
ocessor's process method'
Mock 'IoProcessor' received unexpected message 'process' with
[<#<StringIO:0x2ca
0818>:Array>]
./file_accessor.rb:4:in `open_and_handle_with'
./file_accessor.rb:3:in `open_and_handle_with'
./file_accessor_spec.rb:15:in `should open a file and pass it to the
processor's
 process method'

Finished in 0.0 seconds

1 specification, 1 failure



Staring at it doesn't help - I've tried that! What is going on here, please?

(I'm off to a mid-summer's evening concert of Vivaldi, Monteverdi and
Gabrieli - perhaps it will all look clearer in the second half of the year!)

Regards -

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

From dastels at daveastels.com  Wed Jun 21 23:39:05 2006
From: dastels at daveastels.com (David Astels)
Date: Wed, 21 Jun 2006 22:39:05 -0500
Subject: [Rspec-devel]  should_be_nil or should.be.nil
In-Reply-To: <448640A0.3090900@warwick.ac.uk>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>	<b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
	<3DAC1871-8678-4B8B-AEB6-6C6A0947D475@daveastels.com>
	<448640A0.3090900@warwick.ac.uk>
Message-ID: <7A439DE9-A522-4C2C-87E5-09EE227D7833@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 6-Jun-06, at 9:57 PM, Keith Hodges wrote:
>
> I am looking forward to the squeak version of sspec

No squeak version yet... but the VisualWorks (Cincom Smalltalk)  
version is solid/complete enough to play with now.  It's in the  
Cincom public Store repository... SSpec

Dave


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEmhDaauez/L4x7g4RAmIHAJoChISnAtawiuJuWRVOHAu+wheu8gCggUcI
qsN9PfNzGwZuzEMd5vEFqL8=
=NGUF
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Thu Jun 22 09:22:04 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 22 Jun 2006 08:22:04 -0500
Subject: [Rspec-devel] 0.5.12 released (about running specs with ruby or
	spec)
In-Reply-To: <533048b70606210917n34911ae9y18172e9c726a02c4@mail.gmail.com>
References: <533048b70606210917n34911ae9y18172e9c726a02c4@mail.gmail.com>
Message-ID: <8d961d900606220622k5ae571e1jbf66aac03cd145a7@mail.gmail.com>

On 6/21/06, DeeJay <smartgpx at gmail.com> wrote:
>
>
> I'm sure everyone knows by now that I am new to all this OO/Ruby/TDD stuff,
> but I'm  trying to start getting the right habits by using BDD. But it's a
> bootstrapping
> process, and I'm not getting the basics... so little things make me wobble a
> lot.
>
> If I run examples/file_accessor_spec.rb with ruby, it passes -
>
>
> examples> ruby file_accessor_spec.rb -fs
>
> A FileAccessor
> - should open a file and pass it to the processor's process method
>
> Finished in 0.0 seconds
>
> 1 specification, 0 failures
>
> But if I run it through rspec's spec tool, if fails -
>
> examples> spec file_accessor_spec.rb -fs

Try this instead:

../bin/spec file_accessor_spec.rb -fs

When you just say 'spec' you'll be running the spec command from the
last installed gem, not the one from svn. When I wrote the
file_accessor example I discovered a subtle bug in RSpec's mock code
that I fixed (the bug that you see when you run with the old spec
command).

You can also uninstall your current rspec gem:
  gem uninstall gem

And install a gem based on the svn head code:

  rake gem
  gem install pkg/rspec-x.x.x.gem

This will aloow you to say 'spec' anywhere and use the latest code.

HTH,
Aslak

>
> A FileAccessor
> - should open a file and pass it to the processor's process method (FAILED -
> 1)
>
> 1)
> MockExpectationError in 'A FileAccessor should open a file and pass it to
> the pr
> ocessor's process method'
> Mock 'IoProcessor' received unexpected message 'process' with
> [<#<StringIO:0x2ca
> 0818>:Array>]
> ./file_accessor.rb:4:in `open_and_handle_with'
> ./file_accessor.rb:3:in `open_and_handle_with'
> ./file_accessor_spec.rb:15:in `should open a file and pass it to the
> processor's
>  process method'
>
> Finished in 0.0 seconds
>
> 1 specification, 1 failure
>
>
>
> Staring at it doesn't help - I've tried that! What is going on here, please?
>
> (I'm off to a mid-summer's evening concert of Vivaldi, Monteverdi and
> Gabrieli - perhaps it will all look clearer in the second half of the year!)
>

Nice. I went to see Mahler's Parsifal a couple of weeks ago. That just
made me confused.

Aslak

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

From chad at clearwaterassociates.ca  Thu Jun 22 10:20:17 2006
From: chad at clearwaterassociates.ca (Chad Nantais)
Date: Thu, 22 Jun 2006 10:20:17 -0400
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <7A439DE9-A522-4C2C-87E5-09EE227D7833@daveastels.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
	<3DAC1871-8678-4B8B-AEB6-6C6A0947D475@daveastels.com>
	<448640A0.3090900@warwick.ac.uk>
	<7A439DE9-A522-4C2C-87E5-09EE227D7833@daveastels.com>
Message-ID: <3de931600606220720v4ec20113h430868d84b00bad@mail.gmail.com>

Thanks Dave.

Is there going to be any type of sSpec development mailing list?  I
was just wondering what's the best place to pose any sSpec related
questions.

Cheers,

Chad

On 6/21/06, David Astels <dastels at daveastels.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 6-Jun-06, at 9:57 PM, Keith Hodges wrote:
> >
> > I am looking forward to the squeak version of sspec
>
> No squeak version yet... but the VisualWorks (Cincom Smalltalk)
> version is solid/complete enough to play with now.  It's in the
> Cincom public Store repository... SSpec
>
> Dave
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEmhDaauez/L4x7g4RAmIHAJoChISnAtawiuJuWRVOHAu+wheu8gCggUcI
> qsN9PfNzGwZuzEMd5vEFqL8=
> =NGUF
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From lists-rspec at shopwatch.org  Sun Jun 25 10:22:49 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Sun, 25 Jun 2006 10:22:49 -0400
Subject: [Rspec-devel] 0.5.12 released, now with --diff option
In-Reply-To: <8d961d900606160912u7d57d7e4sbf370b49ae28ac93@mail.gmail.com>
References: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com>	<449232E2.8040303@artweb-design.de>
	<8d961d900606160912u7d57d7e4sbf370b49ae28ac93@mail.gmail.com>
Message-ID: <449E9C39.7060902@rubyforge.org>

aslak hellesoy wrote:

> Since yesterday, I've also added to 0.5.12 a HTML formatter.


This is really, really nice - I like the pop-down detail.  Seems like it 
ought to be easy for me to run an instance of webrick in the test 
environment, and set up an action to run my specs, then show me the 
output.  Then, running my specs is as simple as pressing F5.

But I don't *quite* see how to do it.  I'm guessing it starts somewhere 
near kernel_ext.rb, but I'm staring at the code and I haven't yet found 
where spec.rb actually starts running at the main level.  Any clues?

Jay Levitt


From dastels at daveastels.com  Thu Jun 22 11:14:41 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 22 Jun 2006 10:14:41 -0500
Subject: [Rspec-devel] should_be_nil or should.be.nil
In-Reply-To: <3de931600606220720v4ec20113h430868d84b00bad@mail.gmail.com>
References: <8d961d900606061428tdc61bf5t5fa7e3c69ba3503a@mail.gmail.com>
	<DAC3DFC0-763F-44FA-80E2-7D397BD0FDC7@pobox.com>
	<3de931600606061439s20988f8fn534cb93290895e9d@mail.gmail.com>
	<1FD264EA-CB98-42A4-9BF3-A47E4B04CE42@FaerieMUD.org>
	<b6840c770606061605t385d2b91yb034f845859304b6@mail.gmail.com>
	<8d961d900606061625i6a405347t520485d4485c5a7e@mail.gmail.com>
	<b6840c770606061638r68a7df2er681303ccfece02fd@mail.gmail.com>
	<3DAC1871-8678-4B8B-AEB6-6C6A0947D475@daveastels.com>
	<448640A0.3090900@warwick.ac.uk>
	<7A439DE9-A522-4C2C-87E5-09EE227D7833@daveastels.com>
	<3de931600606220720v4ec20113h430868d84b00bad@mail.gmail.com>
Message-ID: <3720CA42-D79E-48C9-8F83-77AF0DE5542B@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 22-Jun-06, at 9:20 AM, Chad Nantais wrote:

> Thanks Dave.
>
> Is there going to be any type of sSpec development mailing list?  I
> was just wondering what's the best place to pose any sSpec related
> questions.

I'll be setting up a support site with all the trimmings over the  
next week or so.

You can keep an eye on www.behaviourdriven.org/sspec, but I will be  
posting an announcement here & on my blog.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEmrPhauez/L4x7g4RAtUWAJ9WiwIKAxKDUgaUD9KBNMhqrWmjWQCePlNZ
/D7+bWbYX6RJ/rVk9iC+icM=
=soPb
-----END PGP SIGNATURE-----

From dastels at daveastels.com  Mon Jun 26 18:57:34 2006
From: dastels at daveastels.com (David Astels)
Date: Mon, 26 Jun 2006 19:57:34 -0300
Subject: [Rspec-devel] 0.5.12 released, now with --diff option
In-Reply-To: <449E9C39.7060902@rubyforge.org>
References: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com>	<449232E2.8040303@artweb-design.de>
	<8d961d900606160912u7d57d7e4sbf370b49ae28ac93@mail.gmail.com>
	<449E9C39.7060902@rubyforge.org>
Message-ID: <E75E94DB-42A9-409A-AB07-2D299054E1B6@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 25-Jun-06, at 11:22 AM, Jay Levitt wrote:
>
> But I don't *quite* see how to do it.  I'm guessing it starts  
> somewhere
> near kernel_ext.rb, but I'm staring at the code and I haven't yet  
> found
> where spec.rb actually starts running at the main level.  Any clues?

Look at context() in kernel_ext.rb, as well as context_runner.rb  
(specifically run() )

context() is called form your specification file and is what creates  
the context/specifications

the runner is used to orchestrate their execution

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEoGZfauez/L4x7g4RApLMAKCew6gPcFHli8hvb6Kw/Upxp0l4hQCguRZj
Hj8Ctk2wnYZxD3Vf1a+oHcY=
=8BcQ
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Mon Jun 26 20:09:53 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 26 Jun 2006 19:09:53 -0500
Subject: [Rspec-devel] 0.5.12 released, now with --diff option
In-Reply-To: <449E9C39.7060902@rubyforge.org>
References: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com>
	<449232E2.8040303@artweb-design.de>
	<8d961d900606160912u7d57d7e4sbf370b49ae28ac93@mail.gmail.com>
	<449E9C39.7060902@rubyforge.org>
Message-ID: <8d961d900606261709l2b2bb718qfed33557175b4d62@mail.gmail.com>

On 6/25/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> aslak hellesoy wrote:
>
> > Since yesterday, I've also added to 0.5.12 a HTML formatter.
>
>
> This is really, really nice - I like the pop-down detail.  Seems like it
> ought to be easy for me to run an instance of webrick in the test
> environment, and set up an action to run my specs, then show me the
> output.  Then, running my specs is as simple as pressing F5.
>

I have something like this in the pipe - based on mongrel and camping.
I'll make it available on a branch this week probably.

> But I don't *quite* see how to do it.  I'm guessing it starts somewhere
> near kernel_ext.rb, but I'm staring at the code and I haven't yet found
> where spec.rb actually starts running at the main level.  Any clues?
>

The rspec server I'm playing with just invokes the commandline.
At a later stage I might integrate it more tightly with the 'inner' api.

Aslak

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

From lists-rspec at shopwatch.org  Mon Jun 26 20:32:26 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Mon, 26 Jun 2006 20:32:26 -0400
Subject: [Rspec-devel] 0.5.12 released, now with --diff option
In-Reply-To: <8d961d900606261709l2b2bb718qfed33557175b4d62@mail.gmail.com>
References: <8d961d900606151528k69e8c19ah96e6ac40184bb24a@mail.gmail.com>	<449232E2.8040303@artweb-design.de>	<8d961d900606160912u7d57d7e4sbf370b49ae28ac93@mail.gmail.com>	<449E9C39.7060902@rubyforge.org>
	<8d961d900606261709l2b2bb718qfed33557175b4d62@mail.gmail.com>
Message-ID: <44A07C9A.8090209@rubyforge.org>

aslak hellesoy wrote:

> The rspec server I'm playing with just invokes the commandline.
> At a later stage I might integrate it more tightly with the 'inner' api.

That'd be nice to save the rails startup time..

Jay


From lists-rspec at shopwatch.org  Thu Jun 29 10:04:46 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Thu, 29 Jun 2006 10:04:46 -0400
Subject: [Rspec-devel] Semi-OT: Pronunciation
Message-ID: <44A3DDFE.7030706@shopwatch.org>

Am I the last one to realize that "rspec" can be pronounced, 
Borat-style, as "ruh-SPECK"?

Thought I'd share.

Jay Levitt


From dastels at daveastels.com  Thu Jun 29 10:35:43 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 29 Jun 2006 11:35:43 -0300
Subject: [Rspec-devel] Semi-OT: Pronunciation
In-Reply-To: <44A3DDFE.7030706@shopwatch.org>
References: <44A3DDFE.7030706@shopwatch.org>
Message-ID: <DBC52E5C-667D-4ECD-BFB2-8578D796AE63@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 29-Jun-06, at 11:04 AM, Jay Levitt wrote:

> Am I the last one to realize that "rspec" can be pronounced,
> Borat-style, as "ruh-SPECK"?

heh... does that mean sSpec can be pronounced suh-SPECK?

Dave


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEo+U/auez/L4x7g4RAvqUAJ473swBBr8tphxZjMDziuh6d+pC8gCfW8rf
HsAX1YAsV4iXO28PzVF+54U=
=oILX
-----END PGP SIGNATURE-----

From maillist at steelskies.com  Thu Jun 29 13:11:30 2006
From: maillist at steelskies.com (Jonathan del Strother)
Date: Thu, 29 Jun 2006 18:11:30 +0100
Subject: [Rspec-devel] Rspec on Rails - 'lock_mutex' is missing?
Message-ID: <BBF2C9A8-2B45-452C-B4FF-22FC51B0FA86@steelskies.com>

I've just installed rspec on a bleeding-edge Rails installation.   On  
trying to run the default spec, I got this:

==

(in /Users/jon/Developer/OneMod)
ruby -Ilib "/usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/ 
spec"   "spec/models/active_user_spec.rb"

FF

1)
NoMethodError in 'ActiveUser class with fixtures loaded should count  
two ActiveUsers'
undefined method `lock_mutex' for ActiveRecord::Base:Class
/Users/jon/Developer/OneMod/config/../vendor/rails/activerecord/lib/ 
active_record/base.rb:1177:in `method_missing'

2)
NoMethodError in 'ActiveUser class with fixtures loaded should have  
more specifications'
undefined method `lock_mutex' for ActiveRecord::Base:Class
/Users/jon/Developer/OneMod/config/../vendor/rails/activerecord/lib/ 
active_record/base.rb:1177:in `method_missing'

Finished in 0.032169 seconds

2 specifications, 2 failures
rake aborted!
RSpec failures


==



The lock_mutex method doesn't seem to exist anywhere in ActiveRecord.
I 'fixed' this by replacing lock_mutex & unlock_mutex in  
fixture_loading.rb  with  
"ActiveRecord::Base.send :increment_open_transactions" and  
"ActiveRecord::Base.send :decrement_open_transactions", which seems  
to work, but I'm not familiar enough with either rspec or rails to  
say that this is the correct way of doing things.

Is no-one else getting this error?  I couldn't find any references to  
it anywhere.


Jon

From maillist at steelskies.com  Thu Jun 29 13:26:01 2006
From: maillist at steelskies.com (Jonathan del Strother)
Date: Thu, 29 Jun 2006 18:26:01 +0100
Subject: [Rspec-devel] Rspec on Rails - 'lock_mutex' is missing?
In-Reply-To: <BBF2C9A8-2B45-452C-B4FF-22FC51B0FA86@steelskies.com>
References: <BBF2C9A8-2B45-452C-B4FF-22FC51B0FA86@steelskies.com>
Message-ID: <93CD5E64-3AD7-4A4F-9069-F28CFED22444@steelskies.com>

Oh.  Looked what happened to Rails' transactions.rb on revision 4460  
(19th June) :

-      def lock_mutex#:nodoc:
-        Thread.current['open_transactions'] ||= 0
-        TRANSACTION_MUTEX.lock if Thread.current 
['open_transactions'] == 0
-        Thread.current['start_db_transaction'] = (Thread.current 
['open_transactions'] == 0)
-        Thread.current['open_transactions'] += 1
-      end
-
-      def unlock_mutex#:nodoc:
-        Thread.current['open_transactions'] -= 1
-        TRANSACTION_MUTEX.unlock if Thread.current 
['open_transactions'] == 0
-      end
+
+      private
+        def increment_open_transactions #:nodoc:
+          open = Thread.current['open_transactions'] ||= 0
+          Thread.current['start_db_transaction'] = open.zero?
+          Thread.current['open_transactions'] = open + 1
+        end
+
+        def decrement_open_transactions #:nodoc:
+          Thread.current['open_transactions'] -= 1
+        end


That would explain a lot.


Jon



On 29 Jun 2006, at 18:11, Jonathan del Strother wrote:

> I've just installed rspec on a bleeding-edge Rails installation.   On
> trying to run the default spec, I got this:
>
> ==
>
> (in /Users/jon/Developer/OneMod)
> ruby -Ilib "/usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/
> spec"   "spec/models/active_user_spec.rb"
>
> FF
>
> 1)
> NoMethodError in 'ActiveUser class with fixtures loaded should count
> two ActiveUsers'
> undefined method `lock_mutex' for ActiveRecord::Base:Class
> /Users/jon/Developer/OneMod/config/../vendor/rails/activerecord/lib/
> active_record/base.rb:1177:in `method_missing'
>
> 2)
> NoMethodError in 'ActiveUser class with fixtures loaded should have
> more specifications'
> undefined method `lock_mutex' for ActiveRecord::Base:Class
> /Users/jon/Developer/OneMod/config/../vendor/rails/activerecord/lib/
> active_record/base.rb:1177:in `method_missing'
>
> Finished in 0.032169 seconds
>
> 2 specifications, 2 failures
> rake aborted!
> RSpec failures
>
>
> ==
>
>
>
> The lock_mutex method doesn't seem to exist anywhere in ActiveRecord.
> I 'fixed' this by replacing lock_mutex & unlock_mutex in
> fixture_loading.rb  with
> "ActiveRecord::Base.send :increment_open_transactions" and
> "ActiveRecord::Base.send :decrement_open_transactions", which seems
> to work, but I'm not familiar enough with either rspec or rails to
> say that this is the correct way of doing things.
>
> Is no-one else getting this error?  I couldn't find any references to
> it anywhere.
>
>
> Jon
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Thu Jun 29 20:36:24 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 29 Jun 2006 19:36:24 -0500
Subject: [Rspec-devel] Semi-OT: Pronunciation
In-Reply-To: <DBC52E5C-667D-4ECD-BFB2-8578D796AE63@daveastels.com>
References: <44A3DDFE.7030706@shopwatch.org>
	<DBC52E5C-667D-4ECD-BFB2-8578D796AE63@daveastels.com>
Message-ID: <8d961d900606291736h736ca181l1e007e986321a37a@mail.gmail.com>

On 6/29/06, David Astels <dastels at daveastels.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 29-Jun-06, at 11:04 AM, Jay Levitt wrote:
>
> > Am I the last one to realize that "rspec" can be pronounced,
> > Borat-style, as "ruh-SPECK"?
>

You mean Borat style or Ali G style?

http://insanity-inc6.tripod.com/sitebuildercontent/sitebuilderfiles/mywordisrespect.wav

RSpec!

> heh... does that mean sSpec can be pronounced suh-SPECK?
>
> Dave
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEo+U/auez/L4x7g4RAvqUAJ473swBBr8tphxZjMDziuh6d+pC8gCfW8rf
> HsAX1YAsV4iXO28PzVF+54U=
> =oILX
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From lachiec at gmail.com  Thu Jun 29 21:19:34 2006
From: lachiec at gmail.com (Lachie)
Date: Fri, 30 Jun 2006 11:19:34 +1000
Subject: [Rspec-devel] Semi-OT: Pronunciation
In-Reply-To: <8d961d900606291736h736ca181l1e007e986321a37a@mail.gmail.com>
References: <44A3DDFE.7030706@shopwatch.org>
	<DBC52E5C-667D-4ECD-BFB2-8578D796AE63@daveastels.com>
	<8d961d900606291736h736ca181l1e007e986321a37a@mail.gmail.com>
Message-ID: <2c5e719e0606291819j7d0511c6v72914e5035ed6b9a@mail.gmail.com>

R should S P E C be
find out what it means to me

On 6/30/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/29/06, David Astels <dastels at daveastels.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > On 29-Jun-06, at 11:04 AM, Jay Levitt wrote:
> >
> > > Am I the last one to realize that "rspec" can be pronounced,
> > > Borat-style, as "ruh-SPECK"?
> >
>
> You mean Borat style or Ali G style?
>
> http://insanity-inc6.tripod.com/sitebuildercontent/sitebuilderfiles/mywordisrespect.wav
>
> RSpec!
>
> > heh... does that mean sSpec can be pronounced suh-SPECK?
> >
> > Dave
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.1 (Darwin)
> >
> > iD8DBQFEo+U/auez/L4x7g4RAvqUAJ473swBBr8tphxZjMDziuh6d+pC8gCfW8rf
> > HsAX1YAsV4iXO28PzVF+54U=
> > =oILX
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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
>


-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From lists-rspec at shopwatch.org  Fri Jun 30 08:00:07 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Fri, 30 Jun 2006 08:00:07 -0400
Subject: [Rspec-devel] Semi-OT: Pronunciation
In-Reply-To: <8d961d900606291736h736ca181l1e007e986321a37a@mail.gmail.com>
References: <44A3DDFE.7030706@shopwatch.org>	<DBC52E5C-667D-4ECD-BFB2-8578D796AE63@daveastels.com>
	<8d961d900606291736h736ca181l1e007e986321a37a@mail.gmail.com>
Message-ID: <44A51247.8040805@rubyforge.org>

aslak hellesoy wrote:
> 
> You mean Borat style or Ali G style?

Oops!  Ali G of course.

R-spec, man.

Jay


From maillist at steelskies.com  Fri Jun 30 09:25:59 2006
From: maillist at steelskies.com (Jonathan del Strother)
Date: Fri, 30 Jun 2006 14:25:59 +0100
Subject: [Rspec-devel] TextMate command for RSpec on Rails
Message-ID: <1D2C9158-5C28-4DFE-B88C-6F54AE1B01AC@steelskies.com>

Don't know how many TextMate users we've got here, but:

I was getting a little tired of tweaking a spec file, swapping to  
Terminal, running specs, and swapping back again, so I came up with a  
TextMate command to do this for me.  It runs 'rake spec' and display  
the output, complete with clickable links to any files.



===

#!/usr/bin/env ruby

def process_for_html(string)
   string.gsub!("\n", "<br/>")

   #try to find file names and make them into proper links
   string.gsub! /\.(\/[^:]*):([\d]*)/ do |m|
     path = Dir.pwd + $1
     "<a href=\"txmt://open?url=file://#{path}&line=#{$2}\">#{m}</a>"
   end
   string
end

Dir.chdir(ENV['TM_PROJECT_DIRECTORY'])

output = `rake spec`
output.gsub!("\n", "<br/>")

#try to find file names and make them into proper links
output.gsub! /\.(\/[^:]*):([\d]*)/ do |m|
   path = Dir.pwd + $1
   "<a href=\"txmt://open?url=file://#{path}&line=#{$2}\">#{m}</a>"
end

puts "<html><body style='font-size:0.8em'>#{"<h1>rspec</h1>"+output}</ 
body></html>"


===


Just create a new bundle command, and set its output to 'Show as  
HTML', and you should be good to go.


There's a few limitations though - mainly that stderr isn't captured,  
so any stderr gets dumped at the top of the file , without  
formatting.  This includes the ruby invocation commands (ruby -Ilib "/ 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.13/bin/spec" "spec/models/ 
active_user_spec.rb"), and any syntax errors in your specs.  I've  
been trying for the past hour to properly capture stderr and  
interpolate it into the normal output, without success.  popen3 just  
gives you stdout and stderr as separate objects, with no way of re- 
joining them up in the order they occurred.
So, if anyone has a fix to the stderr problem, or any other additions  
& improvements, I'd love to see them.