Deprecating the mocking framework?

[Zach Dennis-2]

On 9/2/07, Andrew WC Brown <omen.king@...> wrote:
> I think that makes sense.
>
> Which do you recommend? Flexmock or Mocha?
>

I wouldn't recommend either of them by themselves, at least the
current way they sit.

Jim Weirich may be adding globally ordered strict mocks, which if he
does then I think Flexmock will be the first mocking library in ruby
to cover all mocking needs (as far as I know).

Mocha (and RSpec mocks too) don't support globally strict ordered
mocks. Hardmock is another mocking library which is just strict
mocking (no stubs, no partial mocks). Right now I prefer Mocha +
Hardmock, but I'm eagerly awaiting to see if Flexmock gets globally
strict ordered mocks.

Zach Dennis
http://www.continuousthinking.com
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Rodrigo Alvarez Fernández]

I would like to know if the mock framework will be deprecated, since I
have a pair of feature requests, and I don't know where to request
them:

1) Alternative expectations:

mock.should_receive(:save).
  and_return(false).
  or_receive(:save!).
  and_raise(ActiveRecord::RecordNotSaved)

2) Chained stubs/expectations

mock.stub!(:valid?).and_return(false)
mock.stub!(:valid?).and_return(true).after_receiving(:save).and_return(true)

I'm sure that this needs no more explanation :)

On 9/3/07, Zach Dennis <zach.dennis@...> wrote:

> On 9/2/07, Andrew WC Brown <omen.king@...> wrote:
> > I think that makes sense.
> >
> > Which do you recommend? Flexmock or Mocha?
> >
>
> I wouldn't recommend either of them by themselves, at least the
> current way they sit.
>
> Jim Weirich may be adding globally ordered strict mocks, which if he
> does then I think Flexmock will be the first mocking library in ruby
> to cover all mocking needs (as far as I know).
>
> Mocha (and RSpec mocks too) don't support globally strict ordered
> mocks. Hardmock is another mocking library which is just strict
> mocking (no stubs, no partial mocks). Right now I prefer Mocha +
> Hardmock, but I'm eagerly awaiting to see if Flexmock gets globally
> strict ordered mocks.
>
> Zach Dennis
> http://www.continuousthinking.com
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>

--
http://papipo.blogspot.com
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Peter Marklund-2]

> 2) Chained stubs/expectations
>
> mock.stub!(:valid?).and_return(false)
> mock.stub!(:valid?).and_return(true).after_receiving
> (:save).and_return(true)

On first look, that last line is pretty hard to read. I think I  
understand the intention now, but I'm not sure it harmonizes with the  
"Clarity over Cleverness" motto.

Peter

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Rodrigo Alvarez Fernández]

On 9/3/07, Peter Marklund <peter_marklund@...> wrote:

> > 2) Chained stubs/expectations
> >
> > mock.stub!(:valid?).and_return(false)
> > mock.stub!(:valid?).and_return(true).after_receiving
> > (:save).and_return(true)
>
> On first look, that last line is pretty hard to read. I think I
> understand the intention now, but I'm not sure it harmonizes with the
> "Clarity over Cleverness" motto.
>

I understand that there are maybe too many method calls there, but it
would be a nice feature.

Another approach could be using blocks:

mock.stub?(:save).and_return(true) do |saved_mock|
  saved_mock.stub!(:valid?).and_return(true)
end

WDYT?

--
http://papipo.blogspot.com
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Pat Maddox]

On 9/3/07, Rodrigo Alvarez Fernández <papipo@...> wrote:

> On 9/3/07, Peter Marklund <peter_marklund@...> wrote:
> > > 2) Chained stubs/expectations
> > >
> > > mock.stub!(:valid?).and_return(false)
> > > mock.stub!(:valid?).and_return(true).after_receiving
> > > (:save).and_return(true)
> >
> > On first look, that last line is pretty hard to read. I think I
> > understand the intention now, but I'm not sure it harmonizes with the
> > "Clarity over Cleverness" motto.
> >
> I understand that there are maybe too many method calls there, but it
> would be a nice feature.
>
> Another approach could be using blocks:
>
> mock.stub?(:save).and_return(true) do |saved_mock|
>   saved_mock.stub!(:valid?).and_return(true)
> end
>
> WDYT?

This seems kind of funky.  If an AR object can be saved then it's
going to be valid anyway.  In other words

my_object.valid?  #  false
my_object.save    #  true
my_object.valid?  #  true

is a super weird sequence.  What context is this in?

At first glance (i.e. with no context) I don't think that's a good use
for mocks.  You're introducing behavior and state into the mock ("when
save is called, change my valid state to true") which is getting a bit
clever and mixing concerns imo.  The mocks created via the framework
should be pretty stupid and just respond how you want them to.  If you
do need some actual behavior then I suggest you code up another object
that behaves as you need.

However as I said that's just a strange sequence anyway, which
suggests that maybe your design is a bit off.

Pat
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Rodrigo Alvarez Fernández]

On 9/3/07, Pat Maddox <pergesu@...> wrote:

> On 9/3/07, Rodrigo Alvarez Fernández <papipo@...> wrote:
> > On 9/3/07, Peter Marklund <peter_marklund@...> wrote:
> > > > 2) Chained stubs/expectations
> > > >
> > > > mock.stub!(:valid?).and_return(false)
> > > > mock.stub!(:valid?).and_return(true).after_receiving
> > > > (:save).and_return(true)
> > >
> > > On first look, that last line is pretty hard to read. I think I
> > > understand the intention now, but I'm not sure it harmonizes with the
> > > "Clarity over Cleverness" motto.
> > >
> > I understand that there are maybe too many method calls there, but it
> > would be a nice feature.
> >
> > Another approach could be using blocks:
> >
> > mock.stub?(:save).and_return(true) do |saved_mock|
> >   saved_mock.stub!(:valid?).and_return(true)
> > end
> >
> > WDYT?
>
> This seems kind of funky.  If an AR object can be saved then it's
> going to be valid anyway.  In other words
>
> my_object.valid?  #  false
> my_object.save    #  true
> my_object.valid?  #  true
>
> is a super weird sequence.  What context is this in?

Ok, I meant new_record? instead of valid? ;-)
I think that now it makes sense, doesn't it?

>
> At first glance (i.e. with no context) I don't think that's a good use
> for mocks.  You're introducing behavior and state into the mock ("when
> save is called, change my valid state to true") which is getting a bit
> clever and mixing concerns imo.  The mocks created via the framework
> should be pretty stupid and just respond how you want them to.  If you
> do need some actual behavior then I suggest you code up another object
> that behaves as you need.
>
> However as I said that's just a strange sequence anyway, which
> suggests that maybe your design is a bit off.
>
> Pat
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>

--
http://papipo.blogspot.com
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Scott Taylor-6]

On Sep 3, 2007, at 5:19 AM, Rodrigo Alvarez Fernández wrote:

> I would like to know if the mock framework will be deprecated, since I
> have a pair of feature requests, and I don't know where to request
> them:
>
> 1) Alternative expectations:
>
> mock.should_receive(:save).
>   and_return(false).
>   or_receive(:save!).
>   and_raise(ActiveRecord::RecordNotSaved)
>
> 2) Chained stubs/expectations
>
> mock.stub!(:valid?).and_return(false)
> mock.stub!(:valid?).and_return(true).after_receiving
> (:save).and_return(true)
>
> I'm sure that this needs no more explanation :)

Or we could do as flexmock does (and which I find much more readable):

mock.stub!("method1.method2.method3").and_return(true)

Scott

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Rodrigo Alvarez Fernández]

On 9/3/07, Scott Taylor <mailing_lists@...> wrote:

>
> On Sep 3, 2007, at 5:19 AM, Rodrigo Alvarez Fernández wrote:
>
> > I would like to know if the mock framework will be deprecated, since I
> > have a pair of feature requests, and I don't know where to request
> > them:
> >
> > 1) Alternative expectations:
> >
> > mock.should_receive(:save).
> >   and_return(false).
> >   or_receive(:save!).
> >   and_raise(ActiveRecord::RecordNotSaved)
> >
> > 2) Chained stubs/expectations
> >
> > mock.stub!(:valid?).and_return(false)
> > mock.stub!(:valid?).and_return(true).after_receiving
> > (:save).and_return(true)
> >

Maybe this can be accomplished with ordered stubs. rSpec mocks support
only ordered expectations, doesn't it?

> > I'm sure that this needs no more explanation :)
>
> Or we could do as flexmock does (and which I find much more readable):
>
> mock.stub!("method1.method2.method3").and_return(true)
>
> Scott
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>

--
http://papipo.blogspot.com
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Chad Humphries]

Zach,

I believe version 0.7.0 has the global ordering you are looking for:
Version 0.7.0

Added and_yield as an expectation clause.
Inspect on Mocks now yield a more consise description.
Global ordering across all mocks in a container is now allowed.
Added support for Demeter chain mocking.
Deprecated a number of mock_* methods.


-Chad

On Sep 3, 2007, at 12:08 AM, Zach Dennis wrote:

> On 9/2/07, Andrew WC Brown <omen.king@...> wrote:
>> I think that makes sense.
>>
>> Which do you recommend? Flexmock or Mocha?
>>
>
> I wouldn't recommend either of them by themselves, at least the
> current way they sit.
>
> Jim Weirich may be adding globally ordered strict mocks, which if he
> does then I think Flexmock will be the first mocking library in ruby
> to cover all mocking needs (as far as I know).
>
> Mocha (and RSpec mocks too) don't support globally strict ordered
> mocks. Hardmock is another mocking library which is just strict
> mocking (no stubs, no partial mocks). Right now I prefer Mocha +
> Hardmock, but I'm eagerly awaiting to see if Flexmock gets globally
> strict ordered mocks.
>
> Zach Dennis
> http://www.continuousthinking.com
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[David Chelimsky-2]

Hi all,

I've talked this over w/ a couple of the other committers and we've
decided that we will NOT be deprecating the mock framework, at least
for the foreseeable future. If/when we do, it will happen with plenty
of notice and a clear, painless (as much as is possible) upgrade path.

To be clear: this decision is purely pragmatic. Benefits of the
existing framework cited in this thread are significant (one-stop
shop, generated specs for the rails plugin, etc). And the amount of
work it would take to do it right (backwards compatibility, easy
upgrade path, support for multiple external frameworks, etc) far
exceeds the perceived cost of maintaining the existing framework.

Cheers,
David
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[s.ross]

This is and important enough announcement that I though it wise to  
put in a new thread so it doesn't get buried:


On Sep 3, 2007, at 8:42 AM, David Chelimsky wrote:

> Hi all,
>
> I've talked this over w/ a couple of the other committers and we've
> decided that we will NOT be deprecating the mock framework, at least
> for the foreseeable future. If/when we do, it will happen with plenty
> of notice and a clear, painless (as much as is possible) upgrade path.
>
> To be clear: this decision is purely pragmatic. Benefits of the
> existing framework cited in this thread are significant (one-stop
> shop, generated specs for the rails plugin, etc). And the amount of
> work it would take to do it right (backwards compatibility, easy
> upgrade path, support for multiple external frameworks, etc) far
> exceeds the perceived cost of maintaining the existing framework.
>
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Jonathan Linowes]

Personally, I dont want to become an expert at the range of possible  
testing and mocking tools. I just want a solid framework to get my  
work done, recommended by experts like you. And the less different  
components I need to install and maintain, the better. So I prefer  
the integrated approach we've had in Rspec up to now.

Jonathan


On Sep 3, 2007, at 12:08 AM, Zach Dennis wrote:

> On 9/2/07, Andrew WC Brown <omen.king@...> wrote:
>> I think that makes sense.
>>
>> Which do you recommend? Flexmock or Mocha?
>>
>
> I wouldn't recommend either of them by themselves, at least the
> current way they sit.
>
> Jim Weirich may be adding globally ordered strict mocks, which if he
> does then I think Flexmock will be the first mocking library in ruby
> to cover all mocking needs (as far as I know).
>
> Mocha (and RSpec mocks too) don't support globally strict ordered
> mocks. Hardmock is another mocking library which is just strict
> mocking (no stubs, no partial mocks). Right now I prefer Mocha +
> Hardmock, but I'm eagerly awaiting to see if Flexmock gets globally
> strict ordered mocks.
>
> Zach Dennis
> http://www.continuousthinking.com
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Priit Tamboom]

On 9/3/07, David Chelimsky <dchelimsky@...> wrote:

> Hi all,
>
> I've talked this over w/ a couple of the other committers and we've
> decided that we will NOT be deprecating the mock framework, at least
> for the foreseeable future. If/when we do, it will happen with plenty
> of notice and a clear, painless (as much as is possible) upgrade path.
>
> To be clear: this decision is purely pragmatic. Benefits of the
> existing framework cited in this thread are significant (one-stop
> shop, generated specs for the rails plugin, etc). And the amount of
> work it would take to do it right (backwards compatibility, easy
> upgrade path, support for multiple external frameworks, etc) far
> exceeds the perceived cost of maintaining the existing framework.
>
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Very good news indeed, all thanks to rspec core!

Priit@...
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Christoph Sturm]

everybody in this thread is reacting like you are about to remove the
built in mocking. The idea was to deprecate it, something like

"if you use the build in mocking right now, fine. If you start a new
project dont use it"

One thing is clear, mocha is much nicer than the integrated mocking,
nicer syntax, better errormessages, better everything. The rspec
mocking framework could never compete with mocha or flexmock on its
own. At the time it was created there were good reasons for that, just
like there are good reasons to deprecate it now.

No one should be forced to migrate an old project over to new mocks,
but thats not what we are talking about.

Maybe you should just keep the built in mocking, but recommend mocha
for new projects, and start using mocha for the samples and generated
specs.

I recognize that some people like flexmock better, but having one
recommended framework would make it much easier for people to get
started. (It will almost feel like mocha was built in :P)

It really feels strange to hear these complains about rspec not having
everything built in, because the main complain for me and others about
rspec was always that its too big and has its own mocking that you
have to use. (This is fixed now and rspec plays very nice with mocha,
great)

regards
 christoph
On 9/3/07, David Chelimsky <dchelimsky@...> wrote:

> Hi all,
>
> I've talked this over w/ a couple of the other committers and we've
> decided that we will NOT be deprecating the mock framework, at least
> for the foreseeable future. If/when we do, it will happen with plenty
> of notice and a clear, painless (as much as is possible) upgrade path.
>
> To be clear: this decision is purely pragmatic. Benefits of the
> existing framework cited in this thread are significant (one-stop
> shop, generated specs for the rails plugin, etc). And the amount of
> work it would take to do it right (backwards compatibility, easy
> upgrade path, support for multiple external frameworks, etc) far
> exceeds the perceived cost of maintaining the existing framework.
>
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>

--
christoph.sturm@...
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Ingo Weiss-3]

Hi,

is there a way to assert in rspec that a template is rendered in a  
specific layout?

Thanks!
Ingo
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Jonathan Linowes]

Here's how I did it

http://rubyforge.org/pipermail/rspec-users/2007-May/001818.html

linoj


On Sep 5, 2007, at 9:58 AM, Ingo Weiss wrote:

> Hi,
>
> is there a way to assert in rspec that a template is rendered in a
> specific layout?
>
> Thanks!
> Ingo
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

do you mean

get :index
response.should render_template(:index)

?

On 9/5/07, Jonathan Linowes <jonathan@...> wrote:

> Here's how I did it
>
> http://rubyforge.org/pipermail/rspec-users/2007-May/001818.html
>
> linoj
>
>
> On Sep 5, 2007, at 9:58 AM, Ingo Weiss wrote:
>
> > Hi,
> >
> > is there a way to assert in rspec that a template is rendered in a
> > specific layout?
> >
> > Thanks!
> > Ingo
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users@...
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

If core was to deprecate the included mocking framework, then why
would they favor mocha over flexmock? I agree we need to have some
agreement as to which one to use, but why the favoritism?

On 9/5/07, Christoph Sturm <christoph.sturm@...> wrote:

> everybody in this thread is reacting like you are about to remove the
> built in mocking. The idea was to deprecate it, something like
>
> "if you use the build in mocking right now, fine. If you start a new
> project dont use it"
>
> One thing is clear, mocha is much nicer than the integrated mocking,
> nicer syntax, better errormessages, better everything. The rspec
> mocking framework could never compete with mocha or flexmock on its
> own. At the time it was created there were good reasons for that, just
> like there are good reasons to deprecate it now.
>
> No one should be forced to migrate an old project over to new mocks,
> but thats not what we are talking about.
>
> Maybe you should just keep the built in mocking, but recommend mocha
> for new projects, and start using mocha for the samples and generated
> specs.
>
> I recognize that some people like flexmock better, but having one
> recommended framework would make it much easier for people to get
> started. (It will almost feel like mocha was built in :P)
>
> It really feels strange to hear these complains about rspec not having
> everything built in, because the main complain for me and others about
> rspec was always that its too big and has its own mocking that you
> have to use. (This is fixed now and rspec plays very nice with mocha,
> great)
>
> regards
>  christoph
> On 9/3/07, David Chelimsky <dchelimsky@...> wrote:
> > Hi all,
> >
> > I've talked this over w/ a couple of the other committers and we've
> > decided that we will NOT be deprecating the mock framework, at least
> > for the foreseeable future. If/when we do, it will happen with plenty
> > of notice and a clear, painless (as much as is possible) upgrade path.
> >
> > To be clear: this decision is purely pragmatic. Benefits of the
> > existing framework cited in this thread are significant (one-stop
> > shop, generated specs for the rails plugin, etc). And the amount of
> > work it would take to do it right (backwards compatibility, easy
> > upgrade path, support for multiple external frameworks, etc) far
> > exceeds the perceived cost of maintaining the existing framework.
> >
> > Cheers,
> > David
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users@...
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
> --
> christoph.sturm@...
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Jay Levitt-7]

Lance Carlson wrote:
> If core was to deprecate the included mocking framework, then why
> would they favor mocha over flexmock? I agree we need to have some
> agreement as to which one to use, but why the favoritism?

If my grandmother had wheels, would she be a skateboard?

They're not deprecating it.. we don't need to choose which one we would
potentially hypothetically someday choose.

Jay

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Wilson Bilkovich]

On 9/2/07, David Chelimsky <dchelimsky@...> wrote:

> On 9/2/07, Wilson Bilkovich <wilsonb@...> wrote:
> > On 9/1/07, rupert <rupert_apsc@...> wrote:
> > >
> > > On 1 Sep 2007, at 10:04, Tom Stuart wrote:
> > >
> > > > On 1 Sep 2007, at 09:31, rupert wrote:
> > > >>>  Are we planning on dumping the mock framework in favor of using
> > > >>> Mocha
> > > >> The idea has been bandied around on the dev list recently
> >
> > This decision, if it is made in this manner, is suicide for RSpec.
>
> I simply don't understand this statement. Why is this such a big deal?
> RSpec's mock framework offers pretty much ZERO over mocha or flexmock
> - the only thing is that it saves you from typing 24 or 27 characters
> in a config file, depending on your preference. 21 if you use RR.
>
> After that, the functionality is pretty much the same as the other frameworks.
>
> > I have been a huge RSpec booster, but this will make me drop it like a hot coal.
>
> Again - I can't understand where you're coming from here. If you start
> using test/unit or test/spec or any of the other bdd frameworks you'll
> still need to make a decision about a mock framework.
>
> What is the pain that you're perceiving that will come along w/ us
> dumping the mock framework? Perhaps there's something we can do to
> minimize that pain once we know what it is.
>
> Cheers,
> David
>
>

Hi David;
While I see that later in the thread you have announced a good
(correct, in my opinion) decision, I apologize for being too busy to
get back and answer your question.  I'll do so now, for posterity,
even though it looks like the point is moot.

RSpec is now an extremely 'rich' framework of tools. Sometimes that is
a good thing, sometimes that is a drawback. I and, if I am overhearing
a sane cross-section of folks in #caboose, quite a few others are
willing to 'pay' the price of RSpec's complexity in exchange for the
integrated, end-to-end experience.

RSpec is definitely not the only library that supports 'describe' /
'it' / 'before', 'mock', etc these days.  We wrote one for Rubinius,
for example, because we weren't yet compatible enough with Ruby 1.8 to
run RSpec itself, but we wanted to be able to write specs that would
be RSpec-compatible.

For me, at least, RSpec is on the edge of being too complex to trust,
particularly when probably 95% of my existing specs would pass without
modification under mini_rspec, which is currently 313 LOC.

I don't mean this as a criticism.. it's simply that RSpec has decided
(wisely) to be a 'full stack' BDD framework, and not just a way to
execute expectations and print spec output. If RSpec 'splits', by
removing mocking support, and I now have to think about which
'RSpec-like combo' a given project decided to use before diving in,
that will probably push the cost/benefit ratio into the red for me.

I hope I didn't sound like I was planning to boycott RSpec over this
decision. It's simply that the vast majority of RSpec's value to me,
as a user, lies in its integration.

Regards,
--Wilson.
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users