From jon.delStrother at bestbefore.tv  Thu Feb  1 09:11:08 2007
From: jon.delStrother at bestbefore.tv (Jonathan del Strother)
Date: Thu, 1 Feb 2007 14:11:08 +0000
Subject: [mocha-developer] with-arguments block is executed regardless of
	method?
Message-ID: <3B4F182F-2293-4954-A643-376DA3F58A43@bestbefore.tv>

I have a test case where I'm stubbing one method ('jobs'), and  
mocking another ('new_worker')

MiddleMan.stubs(:jobs)
MiddleMan.expects(:new_worker).with{|args| args[:class] 
==:download_worker}
MiddleMan.jobs()


The above code results in an error ("The error occurred while  
evaluating nil.[]") - calling 'jobs' results in the with-arguments  
block for new_worker getting executed.
Is this intended behaviour?

Jon

From jamesmead44 at gmail.com  Thu Feb  1 10:38:41 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 1 Feb 2007 15:38:41 +0000
Subject: [mocha-developer] with-arguments block is executed regardless
	of method?
In-Reply-To: <3B4F182F-2293-4954-A643-376DA3F58A43@bestbefore.tv>
References: <3B4F182F-2293-4954-A643-376DA3F58A43@bestbefore.tv>
Message-ID: <1db558f00702010738u70d8ea87o727c41f1a7c9c079@mail.gmail.com>

On 01/02/07, Jonathan del Strother <jon.delStrother at bestbefore.tv> wrote:
>
> I have a test case where I'm stubbing one method ('jobs'), and
> mocking another ('new_worker')
>
> MiddleMan.stubs(:jobs)
> MiddleMan.expects(:new_worker).with{|args| args[:class]
> ==:download_worker}
> MiddleMan.jobs()
>
>
> The above code results in an error ("The error occurred while
> evaluating nil.[]") - calling 'jobs' results in the with-arguments
> block for new_worker getting executed.
> Is this intended behaviour?


Thanks for your email.

Presumably it is the MiddleMan.jobs method that is expected to call the
MiddleMan.new_worker method? It would be helpful to have the code under test
as well as the test.

If yes, it seems strange that you would stub the MiddleMan.jobs method and
then call it. Stubbing it effectively temporarily replaces the
implementation of MiddleMan.jobs and so MiddleMan.new_worker will not be
called as expected.

All that being said, it looks like you've found a bug. It looks like Mocha
executes the with block even if the method name doesn't match. I'll try and
fix it asap.

BTW - you might want to subscribe to the list otherwise your emails won't
appear until I've got round to moderating them.

-- 
James.
http://blog.floehopper.org

From jamesmead44 at gmail.com  Thu Feb  1 10:51:20 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 1 Feb 2007 15:51:20 +0000
Subject: [mocha-developer] with-arguments block is executed regardless
	of method?
In-Reply-To: <1db558f00702010738u70d8ea87o727c41f1a7c9c079@mail.gmail.com>
References: <3B4F182F-2293-4954-A643-376DA3F58A43@bestbefore.tv>
	<1db558f00702010738u70d8ea87o727c41f1a7c9c079@mail.gmail.com>
Message-ID: <1db558f00702010751t411149cdy80ecbe1c2baae5fb@mail.gmail.com>

On 01/02/07, James Mead <jamesmead44 at gmail.com> wrote:
>
> All that being said, it looks like you've found a bug. It looks like Mocha
> executes the with block even if the method name doesn't match. I'll try and
> fix it asap.
>

Should be fixed in revision 98 of trunk.

-- 
James.
http://blog.floehopper.org

From jon.delStrother at bestbefore.tv  Thu Feb  1 13:02:25 2007
From: jon.delStrother at bestbefore.tv (Jonathan del Strother)
Date: Thu, 1 Feb 2007 18:02:25 +0000
Subject: [mocha-developer] with-arguments block is executed regardless
	of method?
In-Reply-To: <3B4F182F-2293-4954-A643-376DA3F58A43@bestbefore.tv>
References: <3B4F182F-2293-4954-A643-376DA3F58A43@bestbefore.tv>
Message-ID: <C573187E-AF05-4FAF-9146-3C3CF43C0C4F@bestbefore.tv>

On 01/02/07, James Mead <jamesmead44 at gmail.com> wrote:
>
> On 01/02/07, Jonathan del Strother <jon.delStrother at  
> bestbefore.tv> wrote:
>
>> I have a test case where I'm stubbing one method ('jobs'), and
>> mocking another ('new_worker')
>>
>> MiddleMan.stubs(:jobs)
>> MiddleMan.expects(:new_worker).with{|args| args[:class]
>> ==:download_worker}
>> MiddleMan.jobs()
>>
>>
>> The above code results in an error ("The error occurred while
>> evaluating nil.[]") - calling 'jobs' results in the with-arguments
>> block for new_worker getting executed.
>> Is this intended behaviour?
>
>
> Thanks for your email.
>
> Presumably it is the MiddleMan.jobs method that is expected to call  
> the
> MiddleMan.new_worker method? It would be helpful to have the code  
> under test
> as well as the test.
>
> If yes, it seems strange that you would stub the MiddleMan.jobs  
> method and
> then call it. Stubbing it effectively temporarily replaces the
> implementation of MiddleMan.jobs and so MiddleMan.new_worker will  
> not be
> called as expected.

Yeah, sorry.  MiddleMan.jobs was purely there to illustrate the  
problem - it's called by other unrelated actions within the test case.


On 01/02/07, James Mead <jamesmead44 at gmail.com> wrote:
> Should be fixed in revision 98 of trunk.

Thanks, I'll try it out.

From jamesmead44 at gmail.com  Fri Feb  2 08:12:04 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Fri, 2 Feb 2007 13:12:04 +0000
Subject: [mocha-developer] Fwd: [ mocha-Bugs-7834 ] infinte_range.rb makes
	incorrect assumption about to_f
In-Reply-To: <20070202130755.DBDAA5242C0E@rubyforge.org>
References: <20070202130755.DBDAA5242C0E@rubyforge.org>
Message-ID: <1db558f00702020512v70ce1fc6w33b9f7757682dc67@mail.gmail.com>

Thanks for reporting the bug below.

You're absolutely right. Renamed Range#to_s implementation to #mocha_inspect
and checked first and last respond_to?(:to_f) as you suggested.

Sorry for the delay - I wasn't monitoring the rubyforge trackers. I am now!

Should be fixed in revision 99 of trunk.

-- 
James.
http://blog.floehopper.org

---------- Forwarded message ----------
From: noreply at rubyforge.org <noreply at rubyforge.org>
Date: 02-Feb-2007 13:07
Subject: [ mocha-Bugs-7834 ] infinte_range.rb makes incorrect assumption
about to_f
To: noreply at rubyforge.org

Bugs item #7834, was opened at 2007-01-15 04:21
You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7477&aid=7834&group_id=1917

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 3
Submitted By: James Moore (banshee)
Assigned to: Nobody (None)
Summary: infinte_range.rb makes incorrect assumption about to_f

Initial Comment:
infinite_range.rb assumes that first and last elements of a Range respond to
to_f:



def to_s

    if first.to_f.infinite? then

      return "at most #{last}"

    elsif last.to_f.infinite? then

      return "at least #{first}"

    else

      __to_s__

    end

  end





This is incorrect - Ranges can include any objects that implement <=> and
succ; converting objects to float values isn't a safe assumption.  (I hit
this with  a range of Date objects)



The simple fix is to see if the object responds to to_f:



  def to_s

    if first.respond_to?(:to_f) && first.to_f.infinite?

      return "at most #{last}"

    elsif last.respond_to?(:to_f) && last.to_f.infinite?

      return "at least #{first}"

    else

      __to_s__

    end

  end



But it's suprising to me that mocha would do something like change the
behavior of to_s for a widely-used class like Range.  My real fix would be
to remove to_s completely.

----------------------------------------------------------------------

>Comment By: James Mead (jamesmead)
Date: 2007-02-02 13:07

Message:
You're absolutely right. Renamed Range#to_s implementation to #mocha_inspect
and checked first and last respond_to?(:to_f) as you suggested.



Sorry for the delay - I wasn't monitoring these trackers.



Should be fixed in revision 99 of trunk.

----------------------------------------------------------------------

You can respond by visiting:
http://rubyforge.org/tracker/?func=detail&atid=7477&aid=7834&group_id=1917

From rsanheim at gmail.com  Sat Feb  3 17:28:59 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Sat, 3 Feb 2007 16:28:59 -0600
Subject: [mocha-developer] allow stubbing of previously defined methods
	such as "id"
In-Reply-To: <1db558f00701030947i260a4af0o2a8175204c50aa33@mail.gmail.com>
References: <B7E19D0A-3776-4706-85B9-71D7D44690D2@jayfields.com>
	<1db558f00701030947i260a4af0o2a8175204c50aa33@mail.gmail.com>
Message-ID: <fc113d400702031428g561fd2a4ha7225064004e6020@mail.gmail.com>

On 1/3/07, James Mead <jamesmead44 at gmail.com> wrote:
> On 02/01/07, Jay <jay at jayfields.com> wrote:
>
> > On my current project I needed to create a stub that responded
> > correctly to the id message.  Here's the change I put into my copy of
> > head.
> >
> > Index: lib/mocha/mock_methods.rb
> >
> ===================================================================
> > --- lib/mocha/mock_methods.rb   (revision 1114)
> > +++ lib/mocha/mock_methods.rb   (working copy)
> > @@ -68,6 +68,7 @@
> >        method_names = method_names.is_a?(Hash) ? method_names :
> > { method_names => nil }
> >        method_names.each do |method_name, return_value|
> >          expectations << Stub.new(self, method_name,
> > backtrace).returns(return_value)
> > +        self.metaclass.send :undef_method, method_name if
> > self.metaclass.method_defined? method_name
> >        end
> >        expectations.last
> >      end
> >
> > Index: test/mocha/auto_verify_test.rb
> >
> ===================================================================
> > --- test/mocha/auto_verify_test.rb      (revision 1114)
> > +++ test/mocha/auto_verify_test.rb      (working copy)
> > @@ -155,6 +155,11 @@
> >      assert_equal 'named_stub', stub.__mock_name
> >    end
> >
> > +  def test_stub_should_respond_to_already_defined_method
> > +    stub = test_case.stub(:id=>"id")
> > +    assert_equal "id", stub.id
> > +  end
> > +
> >    def test_should_create_greedy_stub_with_name
> >      greedy_stub =
> test_case.stub_everything('named_greedy_stub')
> >      assert_equal 'named_greedy_stub', greedy_stub.__mock_name
>
> Thanks for the patch. This has been on the todo list for quite some time.
>
> Your solution works fine for some methods (e.g . id), but not for methods
> that Mocha currently relies on (e.g. inspect).
>
> I have been working on a more generic solution which I hope to commit
> shortly.
>

Did anything for this ever get committed?  I'm having issues stubbing
"id" in an ActiveRecord instance.

Code:
  def test_should_use_post_host_for_post_url_when_passed_post_id_only
    post = Post.new
    post.stubs(:id).returns(5)
    post.stubs(:host).returns("internet.seekingalpha.com")
    post_url(:id => post.id).should ==
"http://internet.seekingalpha.com/article/5"
  end

Error:

  1) Error:
test_should_use_post_host_for_post_url_when_passed_post_id_only(LinkSystemTest):
NoMethodError: private method `id' called for #<Mocha::Stub:0x569b224>
    ./test/functional/link_system_test.rb:33:in
`test_should_use_post_host_for_post_url_when_passed_post_id_only'

- Rob

From rsanheim at gmail.com  Sat Feb  3 17:49:59 2007
From: rsanheim at gmail.com (Rob Sanheim)
Date: Sat, 3 Feb 2007 16:49:59 -0600
Subject: [mocha-developer] allow stubbing of previously defined methods
	such as "id"
In-Reply-To: <fc113d400702031428g561fd2a4ha7225064004e6020@mail.gmail.com>
References: <B7E19D0A-3776-4706-85B9-71D7D44690D2@jayfields.com>
	<1db558f00701030947i260a4af0o2a8175204c50aa33@mail.gmail.com>
	<fc113d400702031428g561fd2a4ha7225064004e6020@mail.gmail.com>
Message-ID: <fc113d400702031449h27c78a93y80d676f59b343fda@mail.gmail.com>

On 2/3/07, Rob Sanheim <rsanheim at gmail.com> wrote:
> On 1/3/07, James Mead <jamesmead44 at gmail.com> wrote:
> > On 02/01/07, Jay <jay at jayfields.com> wrote:
> >
> > > On my current project I needed to create a stub that responded
> > > correctly to the id message.  Here's the change I put into my copy of
> > > head.
> > >
> > > Index: lib/mocha/mock_methods.rb
> > >
> > ===================================================================
> > > --- lib/mocha/mock_methods.rb   (revision 1114)
> > > +++ lib/mocha/mock_methods.rb   (working copy)
> > > @@ -68,6 +68,7 @@
> > >        method_names = method_names.is_a?(Hash) ? method_names :
> > > { method_names => nil }
> > >        method_names.each do |method_name, return_value|
> > >          expectations << Stub.new(self, method_name,
> > > backtrace).returns(return_value)
> > > +        self.metaclass.send :undef_method, method_name if
> > > self.metaclass.method_defined? method_name
> > >        end
> > >        expectations.last
> > >      end
> > >
> > > Index: test/mocha/auto_verify_test.rb
> > >
> > ===================================================================
> > > --- test/mocha/auto_verify_test.rb      (revision 1114)
> > > +++ test/mocha/auto_verify_test.rb      (working copy)
> > > @@ -155,6 +155,11 @@
> > >      assert_equal 'named_stub', stub.__mock_name
> > >    end
> > >
> > > +  def test_stub_should_respond_to_already_defined_method
> > > +    stub = test_case.stub(:id=>"id")
> > > +    assert_equal "id", stub.id
> > > +  end
> > > +
> > >    def test_should_create_greedy_stub_with_name
> > >      greedy_stub =
> > test_case.stub_everything('named_greedy_stub')
> > >      assert_equal 'named_greedy_stub', greedy_stub.__mock_name
> >
> > Thanks for the patch. This has been on the todo list for quite some time.
> >
> > Your solution works fine for some methods (e.g . id), but not for methods
> > that Mocha currently relies on (e.g. inspect).
> >
> > I have been working on a more generic solution which I hope to commit
> > shortly.
> >
>
> Did anything for this ever get committed?  I'm having issues stubbing
> "id" in an ActiveRecord instance.
>
> Code:
>   def test_should_use_post_host_for_post_url_when_passed_post_id_only
>     post = Post.new
>     post.stubs(:id).returns(5)
>     post.stubs(:host).returns("internet.seekingalpha.com")
>     post_url(:id => post.id).should ==
> "http://internet.seekingalpha.com/article/5"
>   end
>
> Error:
>
>   1) Error:
> test_should_use_post_host_for_post_url_when_passed_post_id_only(LinkSystemTest):
> NoMethodError: private method `id' called for #<Mocha::Stub:0x569b224>
>     ./test/functional/link_system_test.rb:33:in
> `test_should_use_post_host_for_post_url_when_passed_post_id_only'
>
> - Rob
>

Looks like this is an error in my code, sorry about that.  I also see
that the above patch is in 0.4 now...

- Rob

From jamesmead44 at gmail.com  Sun Feb  4 14:21:51 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Sun, 4 Feb 2007 19:21:51 +0000
Subject: [mocha-developer] allow stubbing of previously defined methods
	such as "id"
In-Reply-To: <fc113d400702031449h27c78a93y80d676f59b343fda@mail.gmail.com>
References: <B7E19D0A-3776-4706-85B9-71D7D44690D2@jayfields.com>
	<1db558f00701030947i260a4af0o2a8175204c50aa33@mail.gmail.com>
	<fc113d400702031428g561fd2a4ha7225064004e6020@mail.gmail.com>
	<fc113d400702031449h27c78a93y80d676f59b343fda@mail.gmail.com>
Message-ID: <1db558f00702041121q12dd60c5ld06f7483e6f85489@mail.gmail.com>

On 03/02/07, Rob Sanheim <rsanheim at gmail.com> wrote:
>
> Looks like this is an error in my code, sorry about that.  I also see
> that the above patch is in 0.4 now...
>


Yes - it should be in 0.4.

-- 
James.
http://blog.floehopper.org

From greg.hauptmann.ruby at gmail.com  Sun Feb  4 20:58:30 2007
From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann)
Date: Mon, 5 Feb 2007 11:58:30 +1000
Subject: [mocha-developer] Mock objects for stubbing out Paypal - anyone
	have any???
Message-ID: <d30068860702041758j72244642ycff10e8f4b619a8f@mail.gmail.com>

Hi,

Just wondering if anyone has already developed a mocking approach to stub
out the Paypal interface so that one can test on an internal PC which
doesn't provide a means for PayPal to callback to your webserver?  (i.e.
once the app is deployed to the hosting provider it would then work as
PayPal could then hit the application with the specified URL).

Anyone already solved this?  Would mocca be a good way to achieve this?
(basically the rails app has to receive a URL request from PayPal, send a
confirmation back to PayPal and receive a response - i.e. overall the app
therefore has to respond to a URL request, make HTTP requests back to Paypal
and process the response)

Tks
Greg

From greg.hauptmann.ruby at gmail.com  Sun Feb  4 23:17:18 2007
From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann)
Date: Mon, 5 Feb 2007 14:17:18 +1000
Subject: [mocha-developer] how does Mocha compare in terms of classical vs
	mock-based testing, and stubbing???
Message-ID: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>

Hi guys,

I've just been reading Martin Fowler's article re mock versus
stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
he compares traditional TDD testing techniques with mock based
testing. I'd be interested in comments from a ruby on rails perspective in
terms of this and Mocha?  For example:

a) Do you see Mocha as a robust way to test Ruby on Rails based apps?

b) Why would one use Mocha over traditional non-mock object based testing
for Ruby on Rails?

c) Is Mocha a good choice for stubbing out other components that the rails
app may interact with, for the purpose of testing?

Tks
Greg

From jamesmead44 at gmail.com  Mon Feb  5 06:06:31 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 5 Feb 2007 11:06:31 +0000
Subject: [mocha-developer] Mock objects for stubbing out Paypal - anyone
	have any???
In-Reply-To: <d30068860702041758j72244642ycff10e8f4b619a8f@mail.gmail.com>
References: <d30068860702041758j72244642ycff10e8f4b619a8f@mail.gmail.com>
Message-ID: <1db558f00702050306t5669e8aeg980bf1266917d34@mail.gmail.com>

On 05/02/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
>
> Just wondering if anyone has already developed a mocking approach to stub
> out the Paypal interface so that one can test on an internal PC which
> doesn't provide a means for PayPal to callback to your webserver?  (i.e.
> once the app is deployed to the hosting provider it would then work as
> PayPal could then hit the application with the specified URL).
>
> Anyone already solved this?  Would mocca be a good way to achieve this?
> (basically the rails app has to receive a URL request from PayPal, send a
> confirmation back to PayPal and receive a response - i.e. overall the app
> therefore has to respond to a URL request, make HTTP requests back to
> Paypal
> and process the response).
>

Hi Greg,

Although we haven't specifically done this with the PayPal interface, we
have done it with other external services e.g. Amazon ECS.

I've found the best approach is to build an adapter object or layer that
presents the external service as a simple interface for the rest of your
application to use. Then you can use a mock library such as Mocha to set up
expectations for tests where you expect calls to the PayPal interface to be
made. In other tests you can simply stub the interface.

You may also want to have unit tests for the internals of your PayPal
adapter and Mocha can also be used to stub significant methods within your
adapter layer to e.g. inject an expected http response.

Also I'm sure there are already PayPal ruby libraries out there - just try
googling for "paypal ruby".

-- 
James.
http://blog.floehopper.org

From dchelimsky at gmail.com  Mon Feb  5 07:46:05 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 5 Feb 2007 06:46:05 -0600
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
Message-ID: <57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>

On 2/4/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> Hi guys,
>
> I've just been reading Martin Fowler's article re mock versus
> stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
> he compares traditional TDD testing techniques with mock based
> testing. I'd be interested in comments from a ruby on rails perspective in
> terms of this and Mocha?  For example:
>
> a) Do you see Mocha as a robust way to test Ruby on Rails based apps?

Yes - though I think of mocking as one tool among many in a robust
testing-toolkit.

>
> b) Why would one use Mocha over traditional non-mock object based testing
> for Ruby on Rails?

Interface Discovery!!!!!! Read http://jmock.org/oopsla2004.pdf for
more info on that.

>
> c) Is Mocha a good choice for stubbing out other components that the rails
> app may interact with, for the purpose of testing?

Short version: Yes.

Longer version: A guideline that I like to follow is to wrap 3rd party
APIs with thin adapters that provide context-appropriate method names
and only those that your app needs. Then you mock your own API, not
the 3rd party API. You still need to test your adapter, but that test
is isolated from the tests that are about your application and what it
does.

Cheers,
David

>
> Tks
> Greg
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From jamesmead44 at gmail.com  Mon Feb  5 07:52:44 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 5 Feb 2007 12:52:44 +0000
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
Message-ID: <1db558f00702050452h3c3a1254ye1fd97f7f81a011b@mail.gmail.com>

On 05/02/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
>
> I've just been reading Martin Fowler's article re mock versus
> stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
> he compares traditional TDD testing techniques with mock based
> testing. I'd be interested in comments from a ruby on rails perspective in
> terms of this and Mocha?  For example:
>
> a) Do you see Mocha as a robust way to test Ruby on Rails based apps?
>
> b) Why would one use Mocha over traditional non-mock object based testing
> for Ruby on Rails?
>
> c) Is Mocha a good choice for stubbing out other components that the rails
> app may interact with, for the purpose of testing?


Hi Greg,

Some great questions!

The team at reevoo.com has been using Mocha and its earlier incarnations to
help us test drive Rails applications over the last 18 months or so. We find
it useful to be able to do interaction-based testing as well as traditional
state-based testing. But you could use any mocking library to achieve the
same effect. In general terms, I think doing interaction-based TDD can help
you write more cohesive, less coupled code, although of course it's not a
silver bullet. You will still need higher level functional/integration tests
which check that the real objects are all wired up correctly. I would say
you will see more benefits of using an interaction-based approach, the
bigger your application gets - mainly due to the reduction in coupling and
hence the reduction in brittleness of tests.

There are some great resources on the JMock & MockObjects websites (see
http://www.jmock.org/docs.html and http://www.mockobjects.com/) which
although they give examples in Java, are just as applicable in Ruby. In
particular the "Mock Roles, Not Objects" paper (
http://www.jmock.org/oopsla2004.pdf) is well worth a read.

I'm not sure I've completely answered your questions, but please feel free
to ask more questions like this on the mailing list. I find it's often
easier to talk about specific examples rather than generalities, so why not
have a go with Mocha in a Rails app and drop us a line if you have any
questions.

-- 
James.
http://blog.floehopper.org

From dchelimsky at gmail.com  Mon Feb  5 08:28:48 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 5 Feb 2007 07:28:48 -0600
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <1db558f00702050452h3c3a1254ye1fd97f7f81a011b@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
	<1db558f00702050452h3c3a1254ye1fd97f7f81a011b@mail.gmail.com>
Message-ID: <57c63afe0702050528n38f3366dl5a403f86b5c2c464@mail.gmail.com>

On 2/5/07, James Mead <jamesmead44 at gmail.com> wrote:
> On 05/02/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> >
> > I've just been reading Martin Fowler's article re mock versus
> > stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
> > he compares traditional TDD testing techniques with mock based
> > testing. I'd be interested in comments from a ruby on rails perspective in
> > terms of this and Mocha?  For example:
> >
> > a) Do you see Mocha as a robust way to test Ruby on Rails based apps?
> >
> > b) Why would one use Mocha over traditional non-mock object based testing
> > for Ruby on Rails?
> >
> > c) Is Mocha a good choice for stubbing out other components that the rails
> > app may interact with, for the purpose of testing?
>
>
> Hi Greg,
>
> Some great questions!
>
> The team at reevoo.com has been using Mocha and its earlier incarnations to
> help us test drive Rails applications over the last 18 months or so. We find
> it useful to be able to do interaction-based testing as well as traditional
> state-based testing. But you could use any mocking library to achieve the
> same effect. In general terms, I think doing interaction-based TDD can help
> you write more cohesive, less coupled code, although of course it's not a
> silver bullet. You will still need higher level functional/integration tests
> which check that the real objects are all wired up correctly. I would say
> you will see more benefits of using an interaction-based approach, the
> bigger your application gets - mainly due to the reduction in coupling and
> hence the reduction in brittleness of tests.

Very well put!

>
> There are some great resources on the JMock & MockObjects websites (see
> http://www.jmock.org/docs.html and http://www.mockobjects.com/) which
> although they give examples in Java, are just as applicable in Ruby. In
> particular the "Mock Roles, Not Objects" paper (
> http://www.jmock.org/oopsla2004.pdf) is well worth a read.
>
> I'm not sure I've completely answered your questions, but please feel free
> to ask more questions like this on the mailing list. I find it's often
> easier to talk about specific examples rather than generalities, so why not
> have a go with Mocha in a Rails app and drop us a line if you have any
> questions.
>
> --
> James.
> http://blog.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From greg.hauptmann.ruby at gmail.com  Mon Feb  5 15:10:19 2007
From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann)
Date: Tue, 6 Feb 2007 07:10:19 +1100
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
	<57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
Message-ID: <d30068860702051210u47686433p1fb78274b246dc47@mail.gmail.com>

Thanks James/David,

I'll read through the references.  I'm getting that same feeling I had when
I came across blocks for the 1st time in ruby actually :) [I still wonder if
I truly understand the full power of blocks and whether I'm missing
something]   I think perhaps I need to write/use the framework to have it
sink in.

In the meantime if you had a few minutes for a couple of followup
questions.  Actually I'll just focus around my stubing-out-paypal
requirement:

So the suggestion is to have (a) a thin paypal adaptor to stub out the
interface, (b) use of mocha for testing the interface.

Q1 - Was there a specific ruby on rails pattern/approach you had in mind
when you mentioned "adaptor"?

Q2 - Is the purpose of the components suggested per the below, i.e. do I
have it right.  Use cases:
Testing the application
(a) ability to manually test app - uses paypal adaptor
(b) ability to run state based unit tests - uses paypal adaptor
(c) ability to run mocha tests within the unit testing framework - My
understanding here is that Mocha wouldn't actually use the adaptor?  i.e.
looking at the examples it seems with Mocha you would treat the paypal
adaptor as a collaborator and effectively build the understanding of how it
behaves manually yourself into your Mocha test code?  (not sure if this is
DRY - maybe I'm missing something)
Testing the Paypal interface
(d) well I guess in terms of testing the Paypal interface this isn't what
we're focusing on here.   However it is an interesting question.  It would
have to be a test cases that run only in the non-development environment
when the system is deployed to production (i.e. so Paypal can call back to
my app)

Q3 - What method would you recommend in a situation where some test cases (
i.e. the final Paypal interface focused unit tests) should only run in one
particular environment.  I did see an article in the past from memory which
highlighted a ruby on rails approach for loading specific code based on
which environment one was in.  Perhaps I should dig this up?

Q4 - This was buried in Q2 probably, but just confirming: The Mocha based
tests don't actually run code within the collaborator do they?  i.e. rather
they seem to build up the expected responses from the collaborator that the
SUT (system under test) will see once the test is initiated?

Thanks again
Greg










development mode code insertion







On 2/5/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 2/4/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> > Hi guys,
> >
> > I've just been reading Martin Fowler's article re mock versus
> > stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
> > he compares traditional TDD testing techniques with mock based
> > testing. I'd be interested in comments from a ruby on rails perspective
> in
> > terms of this and Mocha?  For example:
> >
> > a) Do you see Mocha as a robust way to test Ruby on Rails based apps?
>
> Yes - though I think of mocking as one tool among many in a robust
> testing-toolkit.
>
> >
> > b) Why would one use Mocha over traditional non-mock object based
> testing
> > for Ruby on Rails?
>
> Interface Discovery!!!!!! Read http://jmock.org/oopsla2004.pdf for
> more info on that.
>
> >
> > c) Is Mocha a good choice for stubbing out other components that the
> rails
> > app may interact with, for the purpose of testing?
>
> Short version: Yes.
>
> Longer version: A guideline that I like to follow is to wrap 3rd party
> APIs with thin adapters that provide context-appropriate method names
> and only those that your app needs. Then you mock your own API, not
> the 3rd party API. You still need to test your adapter, but that test
> is isolated from the tests that are about your application and what it
> does.
>
> Cheers,
> David
>
> >
> > Tks
> > Greg
> > _______________________________________________
> > mocha-developer mailing list
> > mocha-developer at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mocha-developer
> >
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From jamesmead44 at gmail.com  Tue Feb  6 05:35:45 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 6 Feb 2007 10:35:45 +0000
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <d30068860702051210u47686433p1fb78274b246dc47@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
	<57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
	<d30068860702051210u47686433p1fb78274b246dc47@mail.gmail.com>
Message-ID: <1db558f00702060235v2e3d3687qbeffb6f06af6c125@mail.gmail.com>

On 05/02/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
>
> I'll read through the references.  I'm getting that same feeling I had
> when
> I came across blocks for the 1st time in ruby actually :) [I still wonder
> if
> I truly understand the full power of blocks and whether I'm missing
> something]   I think perhaps I need to write/use the framework to have it
> sink in.


I think that's very true. I'm still learning how to improve my TDD and
mocking techniques. I find a mixture of reading and trying things out is the
best way to learn. Don't be daunted by all the articles about mocking and
interaction based testing - there's never a right and wrong way - just
better and worse ways ;-)

In the meantime if you had a few minutes for a couple of followup
> questions.  Actually I'll just focus around my stubing-out-paypal
> requirement:
>
> So the suggestion is to have (a) a thin paypal adaptor to stub out the
> interface, (b) use of mocha for testing the interface.
>
> Q1 - Was there a specific ruby on rails pattern/approach you had in mind
> when you mentioned "adaptor"?


Not really - I was thinking of an "adapter" in fairly general terms. An
adapter could be useful to simplify the interface to the external service
e.g. you may not need all the flexibility of a 3rd party library. An adapter
can also be useful to decouple your application from a particular 3rd party
library - it's much better to mock/stub your own code (i.e. the adapter) and
not 3rd party code which may be subject to change. So an adapter is not
essential, but gives these advantages.

Q2 - Is the purpose of the components suggested per the below, i.e. do I
> have it right.  Use cases:
> Testing the application
> (a) ability to manually test app - uses paypal adaptor
> (b) ability to run state based unit tests - uses paypal adaptor
> (c) ability to run mocha tests within the unit testing framework - My
> understanding here is that Mocha wouldn't actually use the adaptor?  i.e.
> looking at the examples it seems with Mocha you would treat the paypal
> adaptor as a collaborator and effectively build the understanding of how
> it
> behaves manually yourself into your Mocha test code?  (not sure if this is
> DRY - maybe I'm missing something)
> Testing the Paypal interface
> (d) well I guess in terms of testing the Paypal interface this isn't what
> we're focusing on here.   However it is an interesting question.  It would
> have to be a test cases that run only in the non-development environment
> when the system is deployed to production (i.e. so Paypal can call back to
> my app)


Hmm - I'm a bit confused by all the above. In tests for the application I
would replace the adapter with a mock object and either expect or stub
method calls.

Q3 - What method would you recommend in a situation where some test cases (
> i.e. the final Paypal interface focused unit tests) should only run in one
> particular environment.  I did see an article in the past from memory
> which
> highlighted a ruby on rails approach for loading specific code based on
> which environment one was in.  Perhaps I should dig this up?


I'm not sure what you're getting at here. I think you might be talking about
the normal "Rails mocks"  approach i.e. alternative Fake Object definitions
of particular classes which are loaded in preference to the real definitions
in a particular environment. These are the classes you can put in the
test/mocks directory.

Q4 - This was buried in Q2 probably, but just confirming: The Mocha based
> tests don't actually run code within the collaborator do they?  i.e.
> rather
> they seem to build up the expected responses from the collaborator that
> the
> SUT (system under test) will see once the test is initiated?
>

Again, I'm not 100% sure I understand you correctly, but I think the answer
is yes!

At the risk of sounding like a broken record, I really recommend diving in
and having a go - conversations like this one tend to suffer from ambiguity
of language on both sides and so often go around in circles. Concrete
examples are worth a lot of words! If you get stuck or are unhappy about a
particular test, post it here and we'll try to help you.

-- 
James.
http://blog.floehopper.org

From maillist at steelskies.com  Tue Feb  6 08:19:02 2007
From: maillist at steelskies.com (Jonathan del Strother)
Date: Tue, 6 Feb 2007 13:19:02 +0000
Subject: [mocha-developer] Login systems : stubbing accounts and AR
	association proxies
Message-ID: <A9142162-6A63-4D8B-9432-B87E457A5BEB@steelskies.com>

My Rails site has a fair amount of login and 'ownership' logic.  For  
instance, we have a number of clients (companies), each of which has  
several accounts.  A client owns a number of different types of  
resources, and shouldn't see any other clients' resources, so, for  
example, our ScenesController contains a lot of references to   
'current_client.scenes', rather than Scene.find(:all)


All of which works pretty well, but it can make testing very  
tedious.  I always need to set up a fake client, and a fake account,  
and log in with that account, and make sure that whatever resource  
I'm dealing with in that unit test is assigned to the fake client,  
and so on.
I'm starting to wonder whether I ought to stub all the login and  
ownership logic out of my functional tests, so I can concentrate on  
whatever resource I'm dealing with in that given test.  All the login/ 
ownership stuff could be handled in integration testing, which is  
probably better suited to it anyway, due to having real sessions etc  
etc.

I'm having difficulty doing so, however.  The controller uses some  
current_account / current_client methods to find whoever's logged in  
- stubbing those to return a fake client/account is easy, but you're  
then left with problems with Rails' association proxies.  There's  
lots of use of things like  current_client.scenes.build, which are  
not so easy to stub out (particularly as, AFAICT, you can't make use  
of any arguments passed into a stubbed method).


Has anyone else done anything similar, or am I just creating more  
work for myself by trying to remove login details from functional  
testing?


Jon

From jamesmead44 at gmail.com  Tue Feb  6 09:33:40 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 6 Feb 2007 14:33:40 +0000
Subject: [mocha-developer] Login systems : stubbing accounts and AR
	association proxies
In-Reply-To: <A9142162-6A63-4D8B-9432-B87E457A5BEB@steelskies.com>
References: <A9142162-6A63-4D8B-9432-B87E457A5BEB@steelskies.com>
Message-ID: <1db558f00702060633q576784e3r4c5bf191ac228561@mail.gmail.com>

On 06/02/07, Jonathan del Strother <maillist at steelskies.com> wrote:
>
> My Rails site has a fair amount of login and 'ownership' logic.  For
> instance, we have a number of clients (companies), each of which has
> several accounts.  A client owns a number of different types of
> resources, and shouldn't see any other clients' resources, so, for
> example, our ScenesController contains a lot of references to
> 'current_client.scenes', rather than Scene.find(:all)
>
>
> All of which works pretty well, but it can make testing very
> tedious.  I always need to set up a fake client, and a fake account,
> and log in with that account, and make sure that whatever resource
> I'm dealing with in that unit test is assigned to the fake client,
> and so on.
> I'm starting to wonder whether I ought to stub all the login and
> ownership logic out of my functional tests, so I can concentrate on
> whatever resource I'm dealing with in that given test.  All the login/
> ownership stuff could be handled in integration testing, which is
> probably better suited to it anyway, due to having real sessions etc
> etc.
>
> I'm having difficulty doing so, however.  The controller uses some
> current_account / current_client methods to find whoever's logged in
> - stubbing those to return a fake client/account is easy, but you're
> then left with problems with Rails' association proxies.  There's
> lots of use of things like  current_client.scenes.build, which are
> not so easy to stub out (particularly as, AFAICT, you can't make use
> of any arguments passed into a stubbed method).
>
>
> Has anyone else done anything similar, or am I just creating more
> work for myself by trying to remove login details from functional
> testing?
>

I think your motivation is good. We have run into similar issues with
association proxies.

Rails association proxies encourage train-wreck code / violations of the Law
of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter).

We've tended to introduce public methods on the parent class which delegate
to their proxies. Then you can then stub the newly introduced methods. So in
your case a simple version would be...

class Client < ActiveRecord::Base

  has_many :scenes

  def build_scene
    scenes.build
  end

end

Then you can stub Client#build_scene.

My colleague Chris Roos has some thoughts on this subject here...
http://blog.seagul.co.uk/articles/2007/01/12/encapsulation-in-active-record-objects

-- 
James.
http://blog.floehopper.org

From zackchandler at gmail.com  Tue Feb  6 10:43:51 2007
From: zackchandler at gmail.com (Zack Chandler)
Date: Tue, 6 Feb 2007 07:43:51 -0800
Subject: [mocha-developer] Login systems : stubbing accounts and AR
	association proxies
In-Reply-To: <A9142162-6A63-4D8B-9432-B87E457A5BEB@steelskies.com>
References: <A9142162-6A63-4D8B-9432-B87E457A5BEB@steelskies.com>
Message-ID: <33841ac70702060743p6ac2daafhfe9eaf0bd6e70502@mail.gmail.com>

On 2/6/07, Jonathan del Strother <maillist at steelskies.com> wrote:
> My Rails site has a fair amount of login and 'ownership' logic.  For
> instance, we have a number of clients (companies), each of which has
> several accounts.  A client owns a number of different types of
> resources, and shouldn't see any other clients' resources, so, for
> example, our ScenesController contains a lot of references to
> 'current_client.scenes', rather than Scene.find(:all)
>
>
> All of which works pretty well, but it can make testing very
> tedious.  I always need to set up a fake client, and a fake account,
> and log in with that account, and make sure that whatever resource
> I'm dealing with in that unit test is assigned to the fake client,
> and so on.
> I'm starting to wonder whether I ought to stub all the login and
> ownership logic out of my functional tests, so I can concentrate on
> whatever resource I'm dealing with in that given test.  All the login/
> ownership stuff could be handled in integration testing, which is
> probably better suited to it anyway, due to having real sessions etc
> etc.
>
> I'm having difficulty doing so, however.  The controller uses some
> current_account / current_client methods to find whoever's logged in
> - stubbing those to return a fake client/account is easy, but you're
> then left with problems with Rails' association proxies.  There's
> lots of use of things like  current_client.scenes.build, which are
> not so easy to stub out (particularly as, AFAICT, you can't make use
> of any arguments passed into a stubbed method).
>
>
> Has anyone else done anything similar, or am I just creating more
> work for myself by trying to remove login details from functional
> testing?
>
>
> Jon

I've noticed too that association proxies are hard to mock up.  Here's
an example of how I have done it:

In your controller:

  def some_action
    @tasks = current_user.tasks.find(:all, :conditions => [...])
  end

In your functional test:

User.any_instance.stubs(:tasks).returns(Task)
Task.stubs(:find).returns([Task.new(...), Task.new(...)])

I would think their is a better way.  For one thing this hard-codes
the return values up so any call with any conditions would return the
same array of tasks.

Still it is super-simple and works in common cases.

I'd be interested to hear about better ways to do this.

--
Zack Chandler
http://depixelate.com

From jamesthepiper at gmail.com  Tue Feb  6 12:45:17 2007
From: jamesthepiper at gmail.com (James Moore)
Date: Tue, 6 Feb 2007 09:45:17 -0800
Subject: [mocha-developer] Using any_instance with Rails to make sure the
	right thing is saved?
Message-ID: <7cfed280702060945l72783c9bl9f723b9341f3f218@mail.gmail.com>

I'd like to test that an object with the correct attributes is saved,
something like:

  def test_create_without_existing_suite
    this = self
    w = Annotation.any_instance.expects(:save).with do |x|
      this.assert_equal 'fnord',
some_way_get_the_name_of_the_receiver_of_save
      true
    end
    w.returns true
  end

But the object is created inside the method being tested (in this case, a
test of a Rails controller's 'create' method), so
I don't think there's a way to just mock the method on the particular
object.

Is there a way to get the target of the mocked method from inside
any_instance?

Or am I going about this the wrong way?  Is there a way to be notified when
new instances of a class are created, and then do something like
automatically mock some of their methods?

 - James Moore

From jamesmead44 at gmail.com  Tue Feb  6 13:57:05 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 6 Feb 2007 18:57:05 +0000
Subject: [mocha-developer] Using any_instance with Rails to make sure
	the right thing is saved?
In-Reply-To: <7cfed280702060945l72783c9bl9f723b9341f3f218@mail.gmail.com>
References: <7cfed280702060945l72783c9bl9f723b9341f3f218@mail.gmail.com>
Message-ID: <1db558f00702061057x3869b27fh776d6eaa480410ef@mail.gmail.com>

On 06/02/07, James Moore <jamesthepiper at gmail.com> wrote:
>
> I'd like to test that an object with the correct attributes is saved,
> something like:
>
>   def test_create_without_existing_suite
>     this = self
>     w = Annotation.any_instance.expects(:save).with do |x|
>       this.assert_equal 'fnord',
> some_way_get_the_name_of_the_receiver_of_save
>       true
>     end
>     w.returns true
>   end
>
> But the object is created inside the method being tested (in this case, a
> test of a Rails controller's 'create' method), so
> I don't think there's a way to just mock the method on the particular
> object.
>
> Is there a way to get the target of the mocked method from inside
> any_instance?
>
> Or am I going about this the wrong way?  Is there a way to be notified
> when
> new instances of a class are created, and then do something like
> automatically mock some of their methods?
>

You can stub the 'new' or 'create' methods of a class and return a mock
object.

So you'd have something along these lines in your test...

  annotation = mock('annotation')
  annotation.expects(:update_attributes).with(:name =>
'wibble').returns(true)
  Annotation.stubs(:new).returns(new_annotation)
  post :create, :name => 'wibble'

-- 
James.
http://blog.floehopper.org

From jamesthepiper at gmail.com  Wed Feb  7 15:31:34 2007
From: jamesthepiper at gmail.com (James Moore)
Date: Wed, 7 Feb 2007 12:31:34 -0800
Subject: [mocha-developer] Using any_instance with Rails to make sure
	the right thing is saved?
In-Reply-To: <1db558f00702061057x3869b27fh776d6eaa480410ef@mail.gmail.com>
References: <7cfed280702060945l72783c9bl9f723b9341f3f218@mail.gmail.com>
	<1db558f00702061057x3869b27fh776d6eaa480410ef@mail.gmail.com>
Message-ID: <7cfed280702071231x4436d04ej65fa6bda56368d64@mail.gmail.com>

On 2/6/07, James Mead <jamesmead44 at gmail.com> wrote:
>
> So you'd have something along these lines in your test...
>
>   annotation = mock('annotation')
>   annotation.expects(:update_attributes).with(:name =>
> 'wibble').returns(true)


Is there a standard way to get information from the 'with' bit to the
'return' bit?  It'd be useful to be able to build the return object based on

information from the original call to 'new'.  I did it by stashing away the
values in the 'with' block to be used later on in the Proc used by return():

    # Set up S2TestSuite so it creates the
    # mocks we've just defined
    newargs = nil
    mck = S2TestSuite.stubs(:new).with do |*args|
      newargs = HashWithIndifferentAccess.new.merge!(args.first)
      true
    end
    objs = [foosuite, barsuite]
    generator = lambda do
      result = objs.shift
      result.attributes = newargs

      # #new handles arguments differently; it'll
      # take an id and turn it into an object.
      # #attributes= doesn't do that.
      if i = newargs[:s2_test_path_id]
        result.s2_test_path = S2TestPath.find(i.to_i)
      end
      result
    end
    mck.returns generator

But that seems goofy.  Is there a) either a better way to pass around the
values from #with to #returns, or b) am I just misusing mocks, and
I should always specify all the values?

 - James Moore

From greg.hauptmann.ruby at gmail.com  Wed Feb  7 22:12:31 2007
From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann)
Date: Thu, 8 Feb 2007 13:12:31 +1000
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
	<57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
Message-ID: <d30068860702071912w2ec6c273p589c1f99958ba85a@mail.gmail.com>

Hi David - I've checked at the Mocha source code and starting having a
look.  I'm interested in understanding your comment on interface
discovery.   If you (or someone else) is across the Mocha codebase you could
provide a pointer to where this interface discovery takes please?

Tks
greg

On 2/5/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 2/4/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> > Hi guys,
> >
> > I've just been reading Martin Fowler's article re mock versus
> > stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
> > he compares traditional TDD testing techniques with mock based
> > testing. I'd be interested in comments from a ruby on rails perspective
> in
> > terms of this and Mocha?  For example:
> >
> > a) Do you see Mocha as a robust way to test Ruby on Rails based apps?
>
> Yes - though I think of mocking as one tool among many in a robust
> testing-toolkit.
>
> >
> > b) Why would one use Mocha over traditional non-mock object based
> testing
> > for Ruby on Rails?
>
> Interface Discovery!!!!!! Read http://jmock.org/oopsla2004.pdf for
> more info on that.
>
> >
> > c) Is Mocha a good choice for stubbing out other components that the
> rails
> > app may interact with, for the purpose of testing?
>
> Short version: Yes.
>
> Longer version: A guideline that I like to follow is to wrap 3rd party
> APIs with thin adapters that provide context-appropriate method names
> and only those that your app needs. Then you mock your own API, not
> the 3rd party API. You still need to test your adapter, but that test
> is isolated from the tests that are about your application and what it
> does.
>
> Cheers,
> David
>
> >
> > Tks
> > Greg
> > _______________________________________________
> > mocha-developer mailing list
> > mocha-developer at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mocha-developer
> >
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From dchelimsky at gmail.com  Wed Feb  7 23:05:50 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 7 Feb 2007 22:05:50 -0600
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <d30068860702071912w2ec6c273p589c1f99958ba85a@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
	<57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
	<d30068860702071912w2ec6c273p589c1f99958ba85a@mail.gmail.com>
Message-ID: <57c63afe0702072005n392c2c0dx38a28c377052d5c5@mail.gmail.com>

On 2/7/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> Hi David - I've checked at the Mocha source code and starting having a
> look.  I'm interested in understanding your comment on interface
> discovery.   If you (or someone else) is across the Mocha codebase you could
> provide a pointer to where this interface discovery takes please?

Hi Greg - did you read http://jmock.org/oopsla2004.pdf? It explains it
better than I could.

Read that first and if you have any questions about it feel free to ask.

Cheers,
David

>
> Tks
> greg
>
> On 2/5/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >
> > On 2/4/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> > > Hi guys,
> > >
> > > I've just been reading Martin Fowler's article re mock versus
> > > stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
> > > he compares traditional TDD testing techniques with mock based
> > > testing. I'd be interested in comments from a ruby on rails perspective
> > in
> > > terms of this and Mocha?  For example:
> > >
> > > a) Do you see Mocha as a robust way to test Ruby on Rails based apps?
> >
> > Yes - though I think of mocking as one tool among many in a robust
> > testing-toolkit.
> >
> > >
> > > b) Why would one use Mocha over traditional non-mock object based
> > testing
> > > for Ruby on Rails?
> >
> > Interface Discovery!!!!!! Read http://jmock.org/oopsla2004.pdf for
> > more info on that.
> >
> > >
> > > c) Is Mocha a good choice for stubbing out other components that the
> > rails
> > > app may interact with, for the purpose of testing?
> >
> > Short version: Yes.
> >
> > Longer version: A guideline that I like to follow is to wrap 3rd party
> > APIs with thin adapters that provide context-appropriate method names
> > and only those that your app needs. Then you mock your own API, not
> > the 3rd party API. You still need to test your adapter, but that test
> > is isolated from the tests that are about your application and what it
> > does.
> >
> > Cheers,
> > David
> >
> > >
> > > Tks
> > > Greg
> > > _______________________________________________
> > > mocha-developer mailing list
> > > mocha-developer at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/mocha-developer
> > >
> > _______________________________________________
> > mocha-developer mailing list
> > mocha-developer at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mocha-developer
> >
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From greg.hauptmann.ruby at gmail.com  Thu Feb  8 05:54:35 2007
From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann)
Date: Thu, 8 Feb 2007 21:54:35 +1100
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <57c63afe0702072005n392c2c0dx38a28c377052d5c5@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
	<57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
	<d30068860702071912w2ec6c273p589c1f99958ba85a@mail.gmail.com>
	<57c63afe0702072005n392c2c0dx38a28c377052d5c5@mail.gmail.com>
Message-ID: <d30068860702080254v2414fe4flb19434dc7f02f61c@mail.gmail.com>

Hi David, (all)

I did read this, but re-read briefly again.....arrr....by interface
discovery you were talking about the development concept behind the mock
object TDD concept.   I was on the lookout for some aspect of Mocha that was
going to do a "reflection" style dynamic interface discovery and then build
the mock object from this.  Got it now, so with the Mock object approach the
concept is that you haven't written the code for the collaborators yet.
Let me know if I'm wrong  :)

The only negative I see re potential use of Mocha to solve my "need to stub
out paypal for local testing" is that Mocha seems to extend test cases no?
i.e. this would allow me to unit test my components with paypal stubbed out
in the form of mock object, HOWEVER if I just wanted to do ad hoc
testing/use of my web application (i.e. not driven by a test case) then I'll
still need a separate "test paypal layer" (or stub out paypal in other
words).   If I've still missed something I'd be keen to know.


Tks
Greg



On 2/8/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 2/7/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> > Hi David - I've checked at the Mocha source code and starting having a
> > look.  I'm interested in understanding your comment on interface
> > discovery.   If you (or someone else) is across the Mocha codebase you
> could
> > provide a pointer to where this interface discovery takes please?
>
> Hi Greg - did you read http://jmock.org/oopsla2004.pdf? It explains it
> better than I could.
>
> Read that first and if you have any questions about it feel free to ask.
>
> Cheers,
> David
>
> >
> > Tks
> > greg
> >
> > On 2/5/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > >
> > > On 2/4/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> > > > Hi guys,
> > > >
> > > > I've just been reading Martin Fowler's article re mock versus
> > > > stubbing<http://martinfowler.com/articles/mocksArentStubs.html>where
> > > > he compares traditional TDD testing techniques with mock based
> > > > testing. I'd be interested in comments from a ruby on rails
> perspective
> > > in
> > > > terms of this and Mocha?  For example:
> > > >
> > > > a) Do you see Mocha as a robust way to test Ruby on Rails based
> apps?
> > >
> > > Yes - though I think of mocking as one tool among many in a robust
> > > testing-toolkit.
> > >
> > > >
> > > > b) Why would one use Mocha over traditional non-mock object based
> > > testing
> > > > for Ruby on Rails?
> > >
> > > Interface Discovery!!!!!! Read http://jmock.org/oopsla2004.pdf for
> > > more info on that.
> > >
> > > >
> > > > c) Is Mocha a good choice for stubbing out other components that the
> > > rails
> > > > app may interact with, for the purpose of testing?
> > >
> > > Short version: Yes.
> > >
> > > Longer version: A guideline that I like to follow is to wrap 3rd party
> > > APIs with thin adapters that provide context-appropriate method names
> > > and only those that your app needs. Then you mock your own API, not
> > > the 3rd party API. You still need to test your adapter, but that test
> > > is isolated from the tests that are about your application and what it
> > > does.
> > >
> > > Cheers,
> > > David
> > >
> > > >
> > > > Tks
> > > > Greg
> > > > _______________________________________________
> > > > mocha-developer mailing list
> > > > mocha-developer at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/mocha-developer
> > > >
> > > _______________________________________________
> > > mocha-developer mailing list
> > > mocha-developer at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/mocha-developer
> > >
> > _______________________________________________
> > mocha-developer mailing list
> > mocha-developer at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mocha-developer
> >
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From jamesmead44 at gmail.com  Thu Feb  8 06:11:16 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 8 Feb 2007 11:11:16 +0000
Subject: [mocha-developer] Using any_instance with Rails to make sure
	the right thing is saved?
In-Reply-To: <7cfed280702071231x4436d04ej65fa6bda56368d64@mail.gmail.com>
References: <7cfed280702060945l72783c9bl9f723b9341f3f218@mail.gmail.com>
	<1db558f00702061057x3869b27fh776d6eaa480410ef@mail.gmail.com>
	<7cfed280702071231x4436d04ej65fa6bda56368d64@mail.gmail.com>
Message-ID: <1db558f00702080311r493c1fceh7781f1768921fbbb@mail.gmail.com>

On 07/02/07, James Moore <jamesthepiper at gmail.com> wrote:
>
> Is there a standard way to get information from the 'with' bit to the
> 'return' bit?


No. Intentionally not.

It'd be useful to be able to build the return object based on
> information from the original call to 'new'.  I did it by stashing away
> the
> values in the 'with' block to be used later on in the Proc used by
> return():


If you really want to do that, you'd be better off with a traditional Rails
"mock" object i.e. an alternative class definition in the "test/mocks"
directory. These are what Martin Fowler terms Fake Objects (see
http://www.martinfowler.com/articles/mocksArentStubs.html#TheDifferenceBetweenMocksAndStubs
).

But that seems goofy.  Is there a) either a better way to pass around the
> values from #with to #returns, or b) am I just misusing mocks, and
> I should always specify all the values?
>

I think you get much clearer tests if you explicitly specify the return
values in each scenario.
-- 
James.
http://blog.floehopper.org

From jamesmead44 at gmail.com  Thu Feb  8 06:24:18 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 8 Feb 2007 11:24:18 +0000
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <d30068860702080254v2414fe4flb19434dc7f02f61c@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
	<57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
	<d30068860702071912w2ec6c273p589c1f99958ba85a@mail.gmail.com>
	<57c63afe0702072005n392c2c0dx38a28c377052d5c5@mail.gmail.com>
	<d30068860702080254v2414fe4flb19434dc7f02f61c@mail.gmail.com>
Message-ID: <1db558f00702080324t2ba749f4ga6825c7cc9f9bc83@mail.gmail.com>

On 08/02/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
>
> I did read this, but re-read briefly again.....arrr....by interface
> discovery you were talking about the development concept behind the mock
> object TDD concept.   I was on the lookout for some aspect of Mocha that
> was
> going to do a "reflection" style dynamic interface discovery and then
> build
> the mock object from this.  Got it now, so with the Mock object approach
> the
> concept is that you haven't written the code for the collaborators yet.
> Let me know if I'm wrong  :)


Yes. Using TDD with mock objects makes you think about what behaviour does
the object under test need from its collaborator(s). This drives out the
public method signatures for the collaborator(s) (i.e. interface discovery),
but allows you to focus on the object under test and not immediately worry
about how to implement the behaviour of the collaborators.

The only negative I see re potential use of Mocha to solve my "need to stub
> out paypal for local testing" is that Mocha seems to extend test cases no?
> i.e. this would allow me to unit test my components with paypal stubbed
> out
> in the form of mock object, HOWEVER if I just wanted to do ad hoc
> testing/use of my web application (i.e. not driven by a test case) then
> I'll
> still need a separate "test paypal layer" (or stub out paypal in other
> words).   If I've still missed something I'd be keen to know.
>

The latest version of Mocha is not tightly coupled to Test::Unit. In theory
you could use Mocha to stub out the PayPal service in your development
environment without needing a TestCase. However, I think you'd be better off
using something more like a standard Rails "mock" in the test/mocks
directory (what Martin Fowler calls a Fake Object - see
http://www.martinfowler.com/articles/mocksArentStubs.html#TheDifferenceBetweenMocksAndStubs).
i.e. have an alternative implementation of the PayPal service which replaces
the real implementation and returns canned results.

-- 
James.
http://blog.floehopper.org

From greg.hauptmann.ruby at gmail.com  Thu Feb  8 07:18:42 2007
From: greg.hauptmann.ruby at gmail.com (Greg Hauptmann)
Date: Thu, 8 Feb 2007 23:18:42 +1100
Subject: [mocha-developer] flex mock?
Message-ID: <d30068860702080418r2ec67d6o23764c2b3b65af50@mail.gmail.com>

Hi guys,

Would you mind if I ask how Flex Mock and Mocha sit together?  They compete
directly?

I read that Flex Mock was built into Rails 1.2.  Is there a reason to use
Mocha instead of Flex Mock?

Tks
Greg

From kevin.clark at gmail.com  Thu Feb  8 12:20:31 2007
From: kevin.clark at gmail.com (Kevin Clark)
Date: Thu, 8 Feb 2007 09:20:31 -0800
Subject: [mocha-developer] flex mock?
In-Reply-To: <d30068860702080418r2ec67d6o23764c2b3b65af50@mail.gmail.com>
References: <d30068860702080418r2ec67d6o23764c2b3b65af50@mail.gmail.com>
Message-ID: <f53e6950702080920l23e88fb4j316e6258f610122d@mail.gmail.com>

Hi Greg,
Flexmock was removed form Rails just before 1.2 was released. It had
been bundled for a while, but I think most people don't use mocks
unfortunately, and Mocha was gaining acceptance with the rails
internals developers. I started using it in rails-core a few months
ago and the usage has only grown since.

Initially, the reason to use mocha over flexmock was the stubbing
capability (Flexmock didn't get this until 0.4.0). Now I use it
because I prefer the syntax.

Kev

On 2/8/07, Greg Hauptmann <greg.hauptmann.ruby at gmail.com> wrote:
> Hi guys,
>
> Would you mind if I ask how Flex Mock and Mocha sit together?  They compete
> directly?
>
> I read that Flex Mock was built into Rails 1.2.  Is there a reason to use
> Mocha instead of Flex Mock?
>
> Tks
> Greg
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>


-- 
Kevin Clark
http://glu.ttono.us

From jamesmead44 at gmail.com  Tue Feb 13 20:16:35 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 14 Feb 2007 01:16:35 +0000
Subject: [mocha-developer] how does Mocha compare in terms of classical
	vs mock-based testing, and stubbing???
In-Reply-To: <1db558f00702080324t2ba749f4ga6825c7cc9f9bc83@mail.gmail.com>
References: <d30068860702042017s6af79eb0s71744d649af7972b@mail.gmail.com>
	<57c63afe0702050446o2f69ae0dvfd4ba13eaee8ad1c@mail.gmail.com>
	<d30068860702071912w2ec6c273p589c1f99958ba85a@mail.gmail.com>
	<57c63afe0702072005n392c2c0dx38a28c377052d5c5@mail.gmail.com>
	<d30068860702080254v2414fe4flb19434dc7f02f61c@mail.gmail.com>
	<1db558f00702080324t2ba749f4ga6825c7cc9f9bc83@mail.gmail.com>
Message-ID: <1db558f00702131716v520d534bk16ca88b2ee712836@mail.gmail.com>

This might be worth a look -
http://blog.tammersaleh.com/articles/2007/02/13/mocking-a-network-resource-with-camping

-- 
James.
http://blog.floehopper.org

From jamesmead44 at gmail.com  Fri Feb 16 17:43:19 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Fri, 16 Feb 2007 22:43:19 +0000
Subject: [mocha-developer] [#8687] Block's return value is dropped on
	stubbed yielding methods.
Message-ID: <1db558f00702161443m3db6d957gbe07b4b1056b7ea5@mail.gmail.com>

Erik Hetzner has submitted a bug with a suggested patch...

> Best explained with an example:
>
> test:
>
> foo = mock()
> bar = mock().stubs(:get_baz).returns(:baz)
> foo.stubs(:with_something).yields(bar)
>
> real code:
>
> baz = foo.with_something do |bar|
>   bar.get_baz.to_s
> end
>
> baz should now be "baz", but is nil because we have not specified a return value for the stub. Now, we could
> set add .returns("baz"), but that means that the block isn't really tested.
>
> I have attached a file patches on a yields_and_returns method to Mocha::Expecatation & Mocha::Stub which will return
> the block's return value.
>
> foo = Mocha::Mock.new
> bar = Mocha::Mock.new
> bar.stubs(:get_baz).returns(:baz)
> foo.stubs(:with_something).yields_and_returns(bar)
>
> baz = foo.with_something do |bar|
>   bar.get_baz.to_s
> end
>
>
My take on this is that if the #with_something method is stubbed, the only
behaviour you should be able to specify for the stubbed method is what
values it yields to a supplied block and what value it returns. I think what
Erik is trying to do is trying to link the result of the block to the return
value of the method. I think he would be better off with two tests - one
testing the result of calling the the block in isolation and one testing the
behaviour of #with_something passing in a simple block.

I'm a bit tired at the moment, so it's quite possible I've misread his code,
but I thought I'd get this out onto the list to see if anyone had any
thoughts. I'll try and put some illustrative examples together over the
weekend.

-- 
James.
http://blog.floehopper.org

From jamesmead44 at gmail.com  Sun Feb 18 15:17:04 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Sun, 18 Feb 2007 20:17:04 +0000
Subject: [mocha-developer] slow tests on an established project...
In-Reply-To: <fc113d400701220932l8e0644euc9f3e7c0f97b18de@mail.gmail.com>
References: <fc113d400701070214y32a20766g2184c9ebf277ea4@mail.gmail.com>
	<1db558f00701070307w1a70372boe8be1cdd67247589@mail.gmail.com>
	<fc113d400701220932l8e0644euc9f3e7c0f97b18de@mail.gmail.com>
Message-ID: <1db558f00702181217w1cb822c8i13f82a5dccb808de@mail.gmail.com>

I'm sorry I haven't had time to look at your examples in detail yet.

I just read this article which I thought might be of interest to you...

http://blog.caboo.se/articles/2007/2/13/what-about-those-bloated-tests

-- 
James.
http://blog.floehopper.org

From jamesmead44 at gmail.com  Fri Feb 23 03:40:38 2007
From: jamesmead44 at gmail.com (James Mead)
Date: Fri, 23 Feb 2007 08:40:38 +0000
Subject: [mocha-developer] Fwd: Mocha test retry to connect up to 10 times
In-Reply-To: <8df118361ba9059ef11da15f4a5dbf54@ruby-forum.com>
References: <de872f561c8dc41448abe9db88df2142@ruby-forum.com>
	<1172212266.19385.1.camel@localhost.localdomain>
	<8df118361ba9059ef11da15f4a5dbf54@ruby-forum.com>
Message-ID: <1db558f00702230040q1615ff94k768eeb1d5c3543b1@mail.gmail.com>

---------- Forwarded message ----------
From: Raymond O'connor <nappin713 at yahoo.com>
Date: 23-Feb-2007 08:20
Subject: Re: Mocha test retry to connect up to 10 times
To: ruby-talk ML <ruby-talk at ruby-lang.org>

Hemant Kumar wrote:
> On Fri, 2007-02-23 at 14:57 +0900, Raymond O'connor wrote:
>>
>> Any help would be greatly appreciated, thanks!
>>
>
> With latest version of Mocha, you can actually do something like this:
>
>
> TCPSocket.stubs(:open).returns(data1,data2,data3)
>
> where first call would return data1, second call data2 so on and so
> forth. I hope, you can use this to your advantage.

That worked perfectly!  Thanks a ton!

--
Posted via http://www.ruby-forum.com/.



-- 
James.
http://blog.floehopper.org