rspec users - Aug 2007 - Deprecating the mocking framework?

I saw in one of Dave C.''s comments to a ticket that "our current
plan
is to deprecate the mocking framework."  I hadn''t heard anything
about
that, but then again I haven''t paid super close attention to the list.
 Are we planning on dumping the mock framework in favor of using Mocha
(or any other framework one might want to plug in?).

Pat

> I saw in one of Dave C.''s comments to a ticket that "our
current plan
> is to deprecate the mocking framework."  I hadn''t heard
anything about
> that, but then again I haven''t paid super close attention to the
list.
>  Are we planning on dumping the mock framework in favor of using Mocha
> (or any other framework one might want to plug in?).
The idea has been banded around on the dev list recently, see.....

http://www.nabble.com/mock-framework-tf4312137.html#a12276473

for the discussion

Cheers

Rupert

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 banded around on the dev list recently
This makes me sad, because it means only one thing for the majority  
of users: more hassle. So now I have to choose a mocking framework  
too (an arbitrary choice, thus a gamble), or else configure RSpec to  
keep working the way it used to work, and watch my mocking code slide  
into obsolescence? Sigh.

I agree that it''s a big win for the RSpec developers to not have to  
deal with the distraction of maintaining a mocking framework, but  
it''s vaguely surprising that nobody''s mentioned how valuable
it is
that RSpec is a tidy, coherent, consistent, integrated BDD tool that  
just works out of the box right now. (And newcomers still find it  
impenetrable!) It looks like it''s inevitable that it''ll be
broken up,
but, yeah, it''s a real shame.

Cheers,
-Tom

I understand where you''re coming from Tom. But it''s currently
two
script/plugin installs to start using RSpec with Rails, making it be  
three (the current two plus a mocking framework) is presumably not  
going to change adoption or the hurdle of using RSpec by much. I  
currently use Mocha because I can use it both with Test::Unit and  
RSpec. I have a big legacy of Test::Unit tests and I want to be able  
to maintain those and use mocking there, with the same syntax as in  
RSpec. That''s why I don''t use the built in mocking in RSpec.

Peter

On Sep 1, 2007, at 11:04 AM, 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 banded around on the dev list recently
>
> This makes me sad, because it means only one thing for the majority
> of users: more hassle. So now I have to choose a mocking framework
> too (an arbitrary choice, thus a gamble), or else configure RSpec to
> keep working the way it used to work, and watch my mocking code slide
> into obsolescence? Sigh.
>
> I agree that it''s a big win for the RSpec developers to not have
to
> deal with the distraction of maintaining a mocking framework, but
> it''s vaguely surprising that nobody''s mentioned how
valuable it is
> that RSpec is a tidy, coherent, consistent, integrated BDD tool that
> just works out of the box right now. (And newcomers still find it
> impenetrable!) It looks like it''s inevitable that it''ll
be broken up,
> but, yeah, it''s a real shame.
>
> Cheers,
> -Tom
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


----------------------------
Peter Marklund
Garvar Lundins Gr?nd 7
11220 Stockholm
Sweden

Mobile Phone: +46-(0)70-4164857
Home Phone: +46-(0)8-50091315
Skype: peter_marklund

IM: AIM - petermarklund, MSN - peter_marklund at hotmail.com, Yahoo -  
peter_marklund2002

http://marklunds.com
----------------------------

On 9/1/07, rupert <rupert_apsc at rupespad.com>
wrote:
> > I saw in one of Dave C.''s comments to a ticket that "our
current plan
> > is to deprecate the mocking framework."  I hadn''t heard
anything about
> > that, but then again I haven''t paid super close attention to
the list.
> >  Are we planning on dumping the mock framework in favor of using Mocha
> > (or any other framework one might want to plug in?).
>
> The idea has been banded around on the dev list recently, see.....
>
> http://www.nabble.com/mock-framework-tf4312137.html#a12276473
>
> for the discussion
>
> Cheers
>
> Rupert
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Thanks for the link.

Pat

El 1/9/2007, a las 11:15, Peter Marklund escribi?:
> I understand where you''re coming from Tom. But it''s
currently two
> script/plugin installs to start using RSpec with Rails, making it be
> three (the current two plus a mocking framework) is presumably not
> going to change adoption or the hurdle of using RSpec by much. I
> currently use Mocha because I can use it both with Test::Unit and
> RSpec. I have a big legacy of Test::Unit tests and I want to be able
> to maintain those and use mocking there, with the same syntax as in
> RSpec. That''s why I don''t use the built in mocking in
RSpec.
Ouch. I used the built-in RSpec mocking because it was the default  
and I figured that it would be less likely to have compatibility  
issues in the future (say when Mocha or any of the others made subtle  
updates outside the control of the RSpec team). I liked the idea of  
having one integrated package which just worked.

I actually thought the trend was in the opposite direction; to  
include things in RSpec (isn''t RBehave part of trunk now?) rather  
than pare them down.

Luckily, however, I don''t have too many mocks yet, and the ones which  
are there aren''t that complex. Could probably convert them over to  
something else in about a day''s work.

Cheers,
Wincent

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 banded around on the dev list recently
>
> This makes me sad, because it means only one thing for the majority
> of users: more hassle. So now I have to choose a mocking framework
> too (an arbitrary choice, thus a gamble), or else configure RSpec to
> keep working the way it used to work, and watch my mocking code slide
> into obsolescence? Sigh.
It won''t be removed, so you''ll still be able to use it (as
Peter
pointed out) .  I had exactly the same initial reaction as you (mine  
was a sort of "nooooo, they can''t do that") so I know where
you''re
coming from. But having read through the discussion on the dev list  
and thought about it, the rspec mocking framework is pretty stable  
and complete so I don''t think depreciating it is going to be too big  
a problem for those (like me!) that have a bundle of specs that use  
the rspec mocking framework - I''m going to keep using it for now, but  
have a look at the alternatives as a background task with the intent  
to use one of them on a new project as some point in the future.

Cheers

Rupert

My question is what would you recommend for Mocking?

Mocha or FlexMock?

On 9/1/07, rupert <rupert_apsc at rupespad.com>
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 banded around on the dev list recently
> >
> > This makes me sad, because it means only one thing for the majority
> > of users: more hassle. So now I have to choose a mocking framework
> > too (an arbitrary choice, thus a gamble), or else configure RSpec to
> > keep working the way it used to work, and watch my mocking code slide
> > into obsolescence? Sigh.
>
> It won''t be removed, so you''ll still be able to use it
(as Peter
> pointed out) .  I had exactly the same initial reaction as you (mine
> was a sort of "nooooo, they can''t do that") so I know
where you''re
> coming from. But having read through the discussion on the dev list
> and thought about it, the rspec mocking framework is pretty stable
> and complete so I don''t think depreciating it is going to be too
big
> a problem for those (like me!) that have a bundle of specs that use
> the rspec mocking framework - I''m going to keep using it for now,
but
> have a look at the alternatives as a background task with the intent
> to use one of them on a new project as some point in the future.
>
> Cheers
>
> Rupert
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070901/0ee4ed1b/attachment.html

On 1 Sep 2007, at 18:16, Andrew WC Brown wrote:
> My question is what would you recommend for Mocking?
>
> Mocha or FlexMock?
Personally, I''ve not got a clue as all I''ve used to date is
the rspec
mocking framework.  I''ve had a quick look at Mocha and it seems  
pretty good, but haven''t looked into FlexMock at all yet.

+1 to anyone who''s used both these can comment on the differences!

After a quick google search:

http://www.slideshare.net/viget/mockfight-flexmock-vs-mocha

I have no problem using a external mocking framework but its the choosing.
convention over configuration.



On 9/1/07, rupert <rupert_apsc at rupespad.com>
wrote:
>
>
> On 1 Sep 2007, at 18:16, Andrew WC Brown wrote:
>
> > My question is what would you recommend for Mocking?
> >
> > Mocha or FlexMock?
>
> Personally, I''ve not got a clue as all I''ve used to date
is the rspec
> mocking framework.  I''ve had a quick look at Mocha and it seems
> pretty good, but haven''t looked into FlexMock at all yet.
>
> +1 to anyone who''s used both these can comment on the differences!
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Monsterbox Productions
putting small businesses on-line

1319 Victoria Avenue East
Thunder Bay, Ontario P7C 1C3
Canada

Andrew WC Brown
web-developer and owner
andrew at monsterboxpro.com
P: 807-626-9009
F: 807-624-2705
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070901/7645460f/attachment.html

On 9/1/07, Andrew WC Brown <omen.king at gmail.com>
wrote:
> After a quick google search:
>
> http://www.slideshare.net/viget/mockfight-flexmock-vs-mocha
In fairness - there is something lacking in the slide set - it
suggests that mocha supports parameter matchers and flexmock does not.
In fact, flexmock does. You can do this:

mock.should_receive(:message).with(String).once

and it will pass if the mock receives the message w/ a String. In
mocha, you have to say:

mock.expects(:message).with(kind_of(String))

Flexmock compares args using ===, which is why this works implicitly.

Similarly, mocha, flexmock, and rspec can all take an argument matcher
- an object that responds to == and gives you the right answer. So,
you can do this w/ any of these frameworks:

class LessThan
  def initialize(threshold)
    @threshold = threshold
  end

  def ==(other)
    other < @threshold
  end
end

def less_than(expected)
  LessThan.new(expected)
end

mock.expects(:message).with(less_than(3))
mock.should_receive(:message).with(less_than(3))

Cheers,
David
>
> I have no problem using a external mocking framework but its the choosing.
> convention over configuration.
>
>
>
> On 9/1/07, rupert <rupert_apsc at rupespad.com> wrote:
> >
> > On 1 Sep 2007, at 18:16, Andrew WC Brown wrote:
> >
> > > My question is what would you recommend for Mocking?
> > >
> > > Mocha or FlexMock?
> >
> > Personally, I''ve not got a clue as all I''ve used to
date is the rspec
> > mocking framework.  I''ve had a quick look at Mocha and it
seems
> > pretty good, but haven''t looked into FlexMock at all yet.
> >
> > +1 to anyone who''s used both these can comment on the
differences!
> >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
>
> --
> Monsterbox Productions
> putting small businesses on-line
>
> 1319 Victoria Avenue East
> Thunder Bay, Ontario P7C 1C3
> Canada
>
> Andrew WC Brown
> web-developer and owner
> andrew at monsterboxpro.com
> P: 807-626-9009
>  F: 807-624-2705
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 9/1/07, rupert <rupert_apsc at rupespad.com>
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 have been a huge RSpec booster, but this will make me drop it like a hot coal.
=(

On 9/1/07, Wilson Bilkovich <wilsonb at gmail.com>
wrote:
> On 9/1/07, rupert <rupert_apsc at rupespad.com> 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 have been a huge RSpec booster, but this will make me drop it like a hot
coal.
> =(
While I won''t drop RSpec ;) I agree that removing the mocking
framework is a mistake.

With the integration of rbehave, RSpec is a complete BDD framework.
It allows for behavior specification at the app-level and at the
object-level.  I''m sure everyone will agree that mocking is integral
to the object specification component of BDD.  To paraphrase Aslak,
"if you''re not using mock objects then it ain''t
BDD."

I can understand not wanting to reinvent the wheel, and there are mock
frameworks that sufficiently do the job.  However the whole point of
RSpec is that we''re not satisfied with "sufficient" but
instead demand
a tool that works the way our brains think.  I haven''t used Mocha or
Flexmock extensively because RSpec''s mocking has been great for
me...but I remember taking a look at them when Mocha support was first
added to RSpec.  There were some things that RSpec''s framework did
better and more clearly than Mocha.  I wish I could remember them
precisely, but it was quite a while back.  The point is, if the mock
framework feels off even a little bit, it basically defeats the
purpose of RSpec.  At the very least, it undermines it to a degree.

RSpec should keep its mocking framework because it''s the only
framework that is designed with the same philosophy as RSpec.  In fact
I feel insanely strange thinking of them as separate entities.  The
best scenario, imo, is one where we have a mocking framework tightly
coupled to the overall vision of the RSpec project, but that allows
people to use something else if they really want.  I think it''s
important that RSpec remain a complete BDD framework with all
necessary components working in harmony.

Pat

On 9/2/07, Wilson Bilkovich <wilsonb at gmail.com>
wrote:
> On 9/1/07, rupert <rupert_apsc at rupespad.com> 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 have been a huge RSpec booster, but this will make me drop it like a hot
coal.
> =(
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Eh! The first reactions :-) However I also have to admit and wonder
why rspec dev didn''t make this kind of decisions before version 1.0. I
hate (as a nuby) that now I have to make decision (mocka or flexmock)
at the time where I''m not even a big mock fan yet (now it''s
even more
harder to sell the idea to co-workers as well).

For the very first look, I prefer mocka syntax more than flexmock.

However I like rspec''s clean it ''should'' specs (and
generating doc
from it) so much more compared to test::unit way is.

Oki,
Priit

On 9/2/07, Wilson Bilkovich <wilsonb at gmail.com>
wrote:
> On 9/1/07, rupert <rupert_apsc at rupespad.com> 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

> =(
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Sep 2, 2007, at 12:55 PM, David Chelimsky wrote:
> On 9/2/07, Wilson Bilkovich <wilsonb at gmail.com> wrote:
>> On 9/1/07, rupert <rupert_apsc at rupespad.com> 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''m a little confused about this discussion.  Why don''t we
just do
the following:

1. Hand off the mocking/stubbing framework off to someone else.  It  
will be their project

2. Make the mocking/stubbing framework a dependency of the rspec gem

3. Make it the default (as it is now)

4. Provide clear directions for changing mocking frameworks (as we  
have now).

I thought the end goal with refactoring the mocking framework out was  
not that we shouldn''t be using it, but, that we (David, Aslak, Brian,  
etc) won''t have to maintain it.  Or am I missing something?

Scott

I think that makes sense.

Which do you recommend? Flexmock or Mocha?

On 9/2/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
>
> On Sep 2, 2007, at 12:55 PM, David Chelimsky wrote:
>
> > On 9/2/07, Wilson Bilkovich <wilsonb at gmail.com> wrote:
> >> On 9/1/07, rupert <rupert_apsc at rupespad.com> 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''m a little confused about this discussion.  Why don''t
we just do
> the following:
>
> 1. Hand off the mocking/stubbing framework off to someone else.  It
> will be their project
>
> 2. Make the mocking/stubbing framework a dependency of the rspec gem
>
> 3. Make it the default (as it is now)
>
> 4. Provide clear directions for changing mocking frameworks (as we
> have now).
>
> I thought the end goal with refactoring the mocking framework out was
> not that we shouldn''t be using it, but, that we (David, Aslak,
Brian,
> etc) won''t have to maintain it.  Or am I missing something?
>
> Scott
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Monsterbox Productions
putting small businesses on-line

1319 Victoria Avenue East
Thunder Bay, Ontario P7C 1C3
Canada

Andrew WC Brown
web-developer and owner
andrew at monsterboxpro.com
P: 807-626-9009
F: 807-624-2705
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070902/52de5bc4/attachment.html

On 9/2/07, Scott Taylor <mailing_lists at railsnewbie.com>
wrote:
>
> On Sep 2, 2007, at 12:55 PM, David Chelimsky wrote:
>
> > On 9/2/07, Wilson Bilkovich <wilsonb at gmail.com> wrote:
> >> On 9/1/07, rupert <rupert_apsc at rupespad.com> 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''m a little confused about this discussion.  Why don''t
we just do
> the following:
>
> 1. Hand off the mocking/stubbing framework off to someone else.  It
> will be their project
>
> 2. Make the mocking/stubbing framework a dependency of the rspec gem
>
> 3. Make it the default (as it is now)
>
> 4. Provide clear directions for changing mocking frameworks (as we
> have now).
>
> I thought the end goal with refactoring the mocking framework out was
> not that we shouldn''t be using it, but, that we (David, Aslak,
Brian,
> etc) won''t have to maintain it.  Or am I missing something?
Well, it''s not simply a matter of US maintaining it. It''s a
matter of
it being maintained at all in light of the fact that mocha and
flexmock exist. Put simply, there never should have been an rspec mock
framework.

But here we are.

In my view, we either put the thing to sleep or keep it part of rspec
and forget the whole deprecation thing. Handling it off to someone
else to maintain seems silly to me.

FWIW,
David
>
> Scott
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

>
> Well, it''s not simply a matter of US maintaining it. It''s
a matter of
> it being maintained at all in light of the fact that mocha and
> flexmock exist. Put simply, there never should have been an rspec mock
> framework.
>
> But here we are.
>
> In my view, we either put the thing to sleep or keep it part of rspec
> and forget the whole deprecation thing. Handling it off to someone
> else to maintain seems silly to me.
>
> FWIW,
> David

Ah.  I had no idea.  Why was it originally created, then?  Were you  
guys not happy with mocha at the time?  I find it hard to believe  
that you were ignorant about it.

Plus - are you going to change all of rspec''s specs to use flexmock  
or mocha?

Scott

>
> Well, it''s not simply a matter of US maintaining it. It''s
a matter of
> it being maintained at all in light of the fact that mocha and
> flexmock exist. Put simply, there never should have been an rspec mock
> framework.
>
> But here we are.
>
> In my view, we either put the thing to sleep or keep it part of rspec
> and forget the whole deprecation thing. Handling it off to someone
> else to maintain seems silly to me.
Just to reiterate on my last point:

There are some advantages to keeping the framework - namely that we  
won''t have to convert a lot of specs.  But there are other  
advantages, too. New features are easier for us to implement for  
ourselves.  I''ve already had some ideas for how the mocking framework  
could become better (i.e. support for anonymous functions).  I think  
if we keep it, we should be looking to implement some of those  
advantages that the other mocking frameworks don''t have.  We also  
have steam, which I don''t think mocha and flexmock have (although I  
could be wrong about this).

I just took a look at flexmock - and must say that I don''t like the  
"partial mock" language, because it is confusing to my brain which  
distinguishes a stub from a mock.  And mocha/stubba has an ugly  
syntax (In my humble, and inexperienced, opinion).

If you did "put the thing [rspec''s mocking framework] to
sleep" -
which would you covert to - Mocha, or Flexmock?

Scott

On 9/2/07, Andrew WC Brown <omen.king at gmail.com>
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

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 at gmail.com>
wrote:
> On 9/2/07, Andrew WC Brown <omen.king at gmail.com> 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
http://papipo.blogspot.com

> 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

On 9/3/07, Peter Marklund <peter_marklund at fastmail.fm>
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

On 9/3/07, Rodrigo Alvarez Fern?ndez <papipo at gmail.com>
wrote:
> On 9/3/07, Peter Marklund <peter_marklund at fastmail.fm> 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

On 9/3/07, Pat Maddox <pergesu at gmail.com>
wrote:
> On 9/3/07, Rodrigo Alvarez Fern?ndez <papipo at gmail.com> wrote:
> > On 9/3/07, Peter Marklund <peter_marklund at fastmail.fm> 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

-- 
http://papipo.blogspot.com

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

On 9/3/07, Scott Taylor <mailing_lists at railsnewbie.com>
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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

-- 
http://papipo.blogspot.com

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 at gmail.com> 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

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

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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

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 at gmail.com> 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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On 9/3/07, David Chelimsky <dchelimsky at gmail.com>
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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
Very good news indeed, all thanks to rspec core!

Priit at happy.nuby.rspecter

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 at gmail.com>
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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

-- 
christoph.sturm at gmail.com

Hi,

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

Thanks!
Ingo

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 at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

do you mean

get :index
response.should render_template(:index)

?

On 9/5/07, Jonathan Linowes <jonathan at parkerhill.com>
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 at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> 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 at gmail.com>
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 at gmail.com> 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 at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
> --
> christoph.sturm at gmail.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

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

On 9/2/07, David Chelimsky <dchelimsky at gmail.com>
wrote:
> On 9/2/07, Wilson Bilkovich <wilsonb at gmail.com> wrote:
> > On 9/1/07, rupert <rupert_apsc at rupespad.com> 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.

On 9/5/07, Christoph Sturm <christoph.sturm at gmail.com>
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.
>
I would be 100% OK with this for version 1.1 or 1.2 or whatever, as
long as Mocha was the only ''recommendation'', and the rspec gem
had a
listed gem dependency on Mocha.
It''s the ''choice'' I object to, not the specifics of
which mock
framework we happen to use.

Wilson Bilkovich wrote:
> On 9/5/07, Christoph Sturm <christoph.sturm at gmail.com> 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.
>>
>>     
>
> I would be 100% OK with this for version 1.1 or 1.2 or whatever, as
> long as Mocha was the only ''recommendation'', and the
rspec gem had a
> listed gem dependency on Mocha.
> It''s the ''choice'' I object to, not the specifics
of which mock
> framework we happen to use.
>   
To clarify, you just want a default mock framework, instead of being 
forced to make the decision yourself?

I agree with this.  I also object to the idea that people should 
evaluate mock frameworks to get started.  We should set one of the 
existing ones as a default to relieve the maintenance burden.

-Steven

On 9/5/07, Steven R. Baker <srbaker at pobox.com>
wrote:
> Wilson Bilkovich wrote:
> > On 9/5/07, Christoph Sturm <christoph.sturm at gmail.com> 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.
> >>
> >>
> >
> > I would be 100% OK with this for version 1.1 or 1.2 or whatever, as
> > long as Mocha was the only ''recommendation'', and the
rspec gem had a
> > listed gem dependency on Mocha.
> > It''s the ''choice'' I object to, not the
specifics of which mock
> > framework we happen to use.
> >
> To clarify, you just want a default mock framework, instead of being
> forced to make the decision yourself?
>
Yep. Just so.

On 9/5/07, Steven R. Baker <srbaker at pobox.com>
wrote:
> Wilson Bilkovich wrote:
> > On 9/5/07, Christoph Sturm <christoph.sturm at gmail.com> wrote:
> >> 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.
> >>
> >>
> >
> > I would be 100% OK with this for version 1.1 or 1.2 or whatever, as
> > long as Mocha was the only ''recommendation'', and the
rspec gem had a
> > listed gem dependency on Mocha.
> > It''s the ''choice'' I object to, not the
specifics of which mock
> > framework we happen to use.
> >
> To clarify, you just want a default mock framework, instead of being
> forced to make the decision yourself?
>
Ok, I am in no way saying anything against flexmock, Its probably
great, but I never tried it. What I tried was rspec mocking and mocha,
and I liked mocha much better.

And I do think there should be a default, for the generated code.

regards
 chris

What''s the rationale behind removing the integrated mocking framework?
Can
you not still use Mocha or FlexMock or whatever else you''d like to use
still? Meanwhile, the integrated mocking framework in RSpec provides a ready
and able mocking framework for anyone just starting out with RSpec. In my
experience, people are more apt to begin to use a new thing if it''s
already
there waiting for them.

Chris Pratt

On 9/6/07, Christoph Sturm <christoph.sturm at gmail.com>
wrote:
>
> On 9/5/07, Steven R. Baker <srbaker at pobox.com> wrote:
> > Wilson Bilkovich wrote:
> > > On 9/5/07, Christoph Sturm <christoph.sturm at gmail.com>
wrote:
> > >> 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.
> > >>
> > >>
> > >
> > > I would be 100% OK with this for version 1.1 or 1.2 or whatever,
as
> > > long as Mocha was the only ''recommendation'',
and the rspec gem had a
> > > listed gem dependency on Mocha.
> > > It''s the ''choice'' I object to, not the
specifics of which mock
> > > framework we happen to use.
> > >
> > To clarify, you just want a default mock framework, instead of being
> > forced to make the decision yourself?
> >
>
> Ok, I am in no way saying anything against flexmock, Its probably
> great, but I never tried it. What I tried was rspec mocking and mocha,
> and I liked mocha much better.
>
> And I do think there should be a default, for the generated code.
>
> regards
> chris
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/rspec-users/attachments/20070906/635bfc17/attachment-0001.html

I think bundling/recommending/depending on a mock framework gives you
the same comfort and saves a lot of development time :D

-chris

On 9/6/07, Christopher D. Pratt <chrisdpratt at gmail.com>
wrote:
> What''s the rationale behind removing the integrated mocking
framework? Can
> you not still use Mocha or FlexMock or whatever else you''d like to
use
> still? Meanwhile, the integrated mocking framework in RSpec provides a
ready
> and able mocking framework for anyone just starting out with RSpec. In my
> experience, people are more apt to begin to use a new thing if
it''s already
> there waiting for them.
>
> Chris Pratt
>
>
> On 9/6/07, Christoph Sturm <christoph.sturm at gmail.com> wrote:
> >
> > On 9/5/07, Steven R. Baker <srbaker at pobox.com> wrote:
> > > Wilson Bilkovich wrote:
> > > > On 9/5/07, Christoph Sturm <christoph.sturm at gmail.com
> wrote:
> > > >> 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.
> > > >>
> > > >>
> > > >
> > > > I would be 100% OK with this for version 1.1 or 1.2 or
whatever, as
> > > > long as Mocha was the only
''recommendation'', and the rspec gem had a
> > > > listed gem dependency on Mocha.
> > > > It''s the ''choice'' I object to,
not the specifics of which mock
> > > > framework we happen to use.
> > > >
> > > To clarify, you just want a default mock framework, instead of
being
> > > forced to make the decision yourself?
> > >
> >
> > Ok, I am in no way saying anything against flexmock, Its probably
> > great, but I never tried it. What I tried was rspec mocking and mocha,
> > and I liked mocha much better.
> >
> > And I do think there should be a default, for the generated code.
> >
> > regards
> > chris
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

-- 
christoph.sturm at gmail.com

Hi,

I am stuck with a problem in my helper specs. Say I have a helper  
with two methods, method1 and method2, where method2 is calling  
method1 internally. How can I stub out method1 when testing method2?  
I guess it boils down to how I can access the helper object from  
within a helper spec.

   it ''should behave_correctly'' do
     ???.stub!(:method1).and_return(''mock'')
     method2.should eql(''...'')
   end

Thanks!
Ingo

On 9/6/07, Ingo Weiss <ingo at ingoweiss.com>
wrote:
> Hi,
>
> I am stuck with a problem in my helper specs. Say I have a helper
> with two methods, method1 and method2, where method2 is calling
> method1 internally. How can I stub out method1 when testing method2?
> I guess it boils down to how I can access the helper object from
> within a helper spec.
>
>    it ''should behave_correctly'' do
>      ???.stub!(:method1).and_return(''mock'')
>      method2.should eql(''...'')
>    end
2 schools of thought:

it "should behave correctly" do
 
self.should_receive(:method1).with(''foo'').and_return(whatever)
  method2(''foo'')
end

The other is don''t mock the call. Just spec the behaviour of method1
as though it does everything.

Deciding between these two approaches is where the art of mocking lies
- when to do it, when not to. In the end, it depends on a lot of
factors, but the overriding factor should be the answer to "what is
the simplest way I can get stuff done?"

I''m sure that''s not at all helpful :)

Cheers,
David
>
> Thanks!
> Ingo
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Thanks David,

in this case stubbing out method1 helped me a lot with focusing on  
what I want to test, without being distracted by having to follow  
down the call stack

Ingo

On Sep 6, 2007, at 5:40 PM, David Chelimsky wrote:
> On 9/6/07, Ingo Weiss <ingo at ingoweiss.com> wrote:
>> Hi,
>>
>> I am stuck with a problem in my helper specs. Say I have a helper
>> with two methods, method1 and method2, where method2 is calling
>> method1 internally. How can I stub out method1 when testing method2?
>> I guess it boils down to how I can access the helper object from
>> within a helper spec.
>>
>>    it ''should behave_correctly'' do
>>      ???.stub!(:method1).and_return(''mock'')
>>      method2.should eql(''...'')
>>    end
>
> 2 schools of thought:
>
> it "should behave correctly" do
>  
self.should_receive(:method1).with(''foo'').and_return(whatever)
>   method2(''foo'')
> end
>
> The other is don''t mock the call. Just spec the behaviour of
method1
> as though it does everything.
>
> Deciding between these two approaches is where the art of mocking lies
> - when to do it, when not to. In the end, it depends on a lot of
> factors, but the overriding factor should be the answer to "what is
> the simplest way I can get stuff done?"
>
> I''m sure that''s not at all helpful :)
>
> Cheers,
> David
>
>>
>> Thanks!
>> Ingo
>>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users