Deprecating the mocking framework?

[Wilson Bilkovich]

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.
>

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.
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Steven R. Baker]

Wilson Bilkovich wrote:

> 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.
>>
>>    
>
> 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

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

[Wilson Bilkovich]

On 9/5/07, Steven R. Baker <srbaker@...> wrote:

> Wilson Bilkovich wrote:
> > 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.
> >>
> >>
> >
> > 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.
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Christoph Sturm]

On 9/5/07, Steven R. Baker <srbaker@...> wrote:

> Wilson Bilkovich wrote:
> > On 9/5/07, Christoph Sturm <christoph.sturm@...> 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@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Chris Pratt-2]

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@...> wrote:

On 9/5/07, Steven R. Baker <srbaker@...> wrote:

> Wilson Bilkovich wrote:
> > On 9/5/07, Christoph Sturm <christoph.sturm@...> 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@...
http://rubyforge.org/mailman/listinfo/rspec-users

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

[Christoph Sturm]

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@...> 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@...> wrote:
> >
> > On 9/5/07, Steven R. Baker <srbaker@...> wrote:
> > > Wilson Bilkovich wrote:
> > > > On 9/5/07, Christoph Sturm <christoph.sturm@... > 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@...
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
> _______________________________________________
> 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,

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


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

[David Chelimsky-2]

On 9/6/07, Ingo Weiss <ingo@...> 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@...
> http://rubyforge.org/mailman/listinfo/rspec-users
>

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

[Ingo Weiss-3]

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@...> 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@...
>> 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