From jamesmead44 at gmail.com  Wed Jan  2 09:50:30 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 2 Jan 2008 14:50:30 +0000
Subject: [mocha-developer] Returning the mock associated with an
	expectation.
In-Reply-To: <6a2b4fd00711042143o187c3f57sea8ab809af54d7b8@mail.gmail.com>
References: <6a2b4fd00711040828x23fa8193n612285bb51a8de7e@mail.gmail.com>
	<1db558f00711041219y3adbf323o5324607b53cba6c9@mail.gmail.com>
	<6a2b4fd00711042143o187c3f57sea8ab809af54d7b8@mail.gmail.com>
Message-ID: <1db558f00801020650j734c8f91qca08e74f3031490e@mail.gmail.com>

On 05/11/2007, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> The block syntax looks excellent, and reads very nicely.  I especially
> like the idea of not having to pass in the mock to the block to stick
> the expectations onto, and instead just continue fluently adding
> expectations.
>
> This block syntax also feels like the right direction to go if there
> were to be some kind of expectations on the ordering of method calls.
> I haven't run into a testing situation where I've needed to test the
> ordering of calls on a mock explicitly, but flex mock provides a
> grouping mechanism.
>
> For the corollary in FlexMock, check out #ordered
> http://onestepback.org/software/flexmock/classes/FlexMock/Expectation.html#M000082
>
> Don't take me too seriously, but I think mocha could trump flexmock's
> with something like:
>
> mock_user = mock('User') do
>   initially.expects(:first_name).returns('Duncan')
>   then.expects(:last_name).returns('Beevers')
>
>   later.expects(:birthday).returns('a gentleman never asks')
>   then.expects(:astrological_sign).returns('Virgo')
>
>   stubs(:favorite_color).returns('silver')
>
>   finally.expects(:goodnight!).returns('same to you')
> end
>
> Where the temporal prefixes initially, finally, then and later
> indicate method call ordering, and expectations without a temporal
> prefix can be called freely.
>
> Am I pulling this out of my ass?  Yes.
>
> On Nov 4, 2007 3:19 PM, James Mead <jamesmead44 at gmail.com> wrote:
> >
> > On 04/11/2007, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> > >
> > > I was reading through the FlexMock docs and noticed the expectation
> > > method .mock, which returns the original mock associated with an
> > > expectation.
> > >
> > > It looks really handy for writing nice all-in-one mocks like:
> > >
> > > mock_user = mock('User').expects(:first_name).returns('Jonah').mock
> > >
> > > So I started playing around with mocha and found I could actually
> > > already do this!
> > > But I'm not sure how.  There's no attr_reader on @mock, and I couldn't
> > > find out where this method is defined.
> > >
> > > So, perhaps we could add this an explicit method on Expectation and
> > > include a little rdoc on it?
> > > I think a lot of people would get benefit from making this explicit.
> > >
> > > Opinions?
> > >
> >
> > Hmm. I think this may have disappeared in some recent refactoring in trunk.
> > Rather than exposing too much of the internals, I keep meaning to add a
> > syntax like this...
> >
> >   mock_user = mock('User') {
> >     expects(:first_name).returns('James')
> >     stubs(:last_name).returns('Mead')
> >   }
> >
> > Would that help you do what you want to do...?
> >
> > Alternatively did you know you could already do...
> >
> >   mock_user = mock('User', :first_name => 'James', :last_name => 'Mead')
> >
> > However there are a couple of limitations with this - you can't mix expects
> > & stubs and you can't specify anything other than a returns() e.g. no
> > with(), no raises(), etc.
> >
> >
> > What do you think?
> > --
> > James.
> > http://blog.floehopper.org
> > http://tumble.floehopper.org
> > _______________________________________________
> > 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
>

Sorry for taking ages to respond to this. I just wanted to let you
know that since revision 193 (which is included in gem 0.5.6), the
initializer block syntax has been available. Unfortunately the rdoc
didn't get updated until revision 221 (which hasn't yet been
released).

Since your email, I've added support for JMock2 style sequences [1]
and states [2] which allow you to constrain the order of invocation. I
haven't yet sorted out the error reporting and there may be some
teething problems, but feel free to give it a try. All the rdoc has
been updated in trunk. See AutoVerify#sequence and AutoVerify#states
for details.

In the meantime - thanks for you interest and your suggestions.
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

[1] http://jmock.org/sequences.html
[2] http://jmock.org/states.html

From jamesmead44 at gmail.com  Wed Jan  2 10:15:37 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 2 Jan 2008 15:15:37 +0000
Subject: [mocha-developer] Stubbing yielding methods
In-Reply-To: <6a2b4fd00709211330p49acf6dcia55c9557497dc6aa@mail.gmail.com>
References: <1db558f00709210813k8079b1dn278181f971576e8d@mail.gmail.com>
	<6a2b4fd00709211330p49acf6dcia55c9557497dc6aa@mail.gmail.com>
Message-ID: <1db558f00801020715t2bcbb66fm4f3331b9a38fa7ec@mail.gmail.com>

On 21/09/2007, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> It's certainly necessary to test the code tucked away into these
> blocks, but I feel like yielding is testing in the wrong direction.
>
> Instead of yielding values or mocks into the block, perhaps we can
> check metadata about the provided block (arity, required params) and
> then test the functionality of the block explicitly.
>
> class Test::Unit::TestCase
>   def test_up_them_all
>     upcasing_block = lambda { |e| e.upcase }
>
>     list_of_words = [ 'socks', 'mittens', 'flashlight' ]
>     list_of_words.expects(:map).with_block(upcasing_block)
>
>     u = Upperizer.new
>     u.up_them_all(list_of_words)
>
>     assert_equal 'HONK', upcasing_block('honk')
>   end
> end
>
>
> On 9/21/07, James Mead <jamesmead44 at gmail.com> wrote:
> > I've just been tying my brain in knots looking at bug #8687 (
> > http://rubyforge.org/tracker/index.php?func=detail&aid=8687&group_id=1917&atid=7477
> > ).
> >
> > I've been (1) trying to work out whether there is anything logically wrong
> > with Mocha's existing behaviour and (2) whether Mocha should support the
> > requested functionality.
> >
> > It all centres around the use of the Expectation#yields method. I've put a
> > couple of examples together to try and help me think about it. The first one
> > (http://pastie.caboo.se/99412) is a simplified version of the example in the
> > bug report using a block and stubbing a method that yields to that block.
> >
> > In the second example (http://pastie.caboo.se/99413) I tried to think about
> > how it would work if I converted the block to a method on an object. I
> > slightly ran out of steam on this one when I realised that in this case when
> > I realised Executor#execute wouldn't be called because the implementation of
> > Collaborator#yielding_method is stubbed.
> >
> > This made me wonder if the Expectation#yields method should exist at all! In
> > particular, in the block example, it feels odd because you are going from
> > real code (ClassUnderTest) into mock code (mocked version of Collaborator)
> > and back into real code (the block itself). I wonder if this is really
> > sensible and/or useful.
> >
> > Has anybody got any thoughts?
> >
> > Thanks.
> > --
> > James.
> > http://blog.floehopper.org
> > http://tumble.floehopper.org
> > _______________________________________________
> > 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
>

This is certainly the direction I was starting to think about. I think
the thing that is not clear from your example is where the Upperizer
gets its *real* upcasing_block from. Also is this upcasing_block the
same instance as the one in the local variable in the test?

Do you think it's sufficient to only check the arity of the block? In
which case you wouldn't actually need to supply the upcasing_block in
the with_block clause, you could just specify the block's arity.
Something along the lines of with_block_having_arity(1).

What do you think?
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From jamesmead44 at gmail.com  Wed Jan  2 10:19:15 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 2 Jan 2008 15:19:15 +0000
Subject: [mocha-developer] Stubbing yielding methods
In-Reply-To: <46F4513F.7070703@calpoly.edu>
References: <1db558f00709210813k8079b1dn278181f971576e8d@mail.gmail.com>
	<46F4513F.7070703@calpoly.edu>
Message-ID: <1db558f00801020719k49d9d3abmdb2c0189ed548e97@mail.gmail.com>

On 21/09/2007, John Pywtorak <jpywtora at calpoly.edu> wrote:
> I would weigh in that something like yields is needed and possibly the
> suggested patches as well.  I do agree that it seems to work the wrong
> way.  I went and looked at how I had used yields and found what I think
> validates my assertion above.
>
> Take for example: IO.open, IO.popen, etc.
>
> puts IO.popen("ls", "r") { |pipe| pipe.read }
>
> OK, so this example is contrived; However, I do think it points out some
> important things.  It is desirable to have expectations of both the call
> to popen, or the block, or both; However, rather than yield as a
> modifier to the methods expectations, separate the block's expectations,
> and return values out.  Basically rather than one statement combining
> the two, require two statements.

Thanks for your interest, although I'm not sure I follow your
reasoning. Could you give examples of actual tests and code under test
and explain either how you use the existing features of Mocha or how
you'd like it to work?

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

From jamesmead44 at gmail.com  Wed Jan  2 11:03:25 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 2 Jan 2008 16:03:25 +0000
Subject: [mocha-developer] how to ensure signature compliance while
	mocking in ruby
In-Reply-To: <e0c3802edaa38a6e1d6466fbf48c0f65@ruby-forum.com>
References: <a4a7ff445fc3c964193b60ed07b1798f@ruby-forum.com>
	<1db558f00711130518y554d2238u9eab30d302808b59@mail.gmail.com>
	<e0c3802edaa38a6e1d6466fbf48c0f65@ruby-forum.com>
Message-ID: <1db558f00801020803y545acdc6ic6c6527a359dc0b3@mail.gmail.com>

On 26/11/2007, Pradeep Gatram <pradeep.gatram at gmail.com> wrote:
> Sorry for vanishing for a couple of weeks. I have been using ur
> suggested approach of 'responds_like'. Although its a good start, it
> still does not give me complete confidence. All it tells me is whether
> the method is present or not. It does not guarantee signature
> compliance. For e.g., referring back to my example...
>
> class Bar
>   def method2 param1
>   end
> end
>
> The above implementation of method2 in Bar will cause FooTest to pass
> even with responds_like. But the 2 parameter signature is clearly not
> supported.
>
> I agree, an integration test should and will catch this scenario and
> will fail. But its not possible to write integration tests for every
> scenario. After all, the expected method call could happen under a
> convoluted condition. A classic case where, I believe, the unit tests
> should be able to give me complete guarantee of the state of code.

I don't think you have to write an integration test for *every*
scenario. I would aim to write just enough to give decent coverage of
the integration points between classes, probably focussing on common
or important business scenarios.

> So there does appear to be a need for stricter checking. Leaving the
> default behaviour as is, maybe introduce a new method like
> mocked_object.strictly_expects(:blah)...

I have considered something along these lines. I'll give it some more
thought. I've added a feature request on rubyforge [1].

> That leads me to another aspect? How about validating the return types
> :D. Java/C# again gave me that additional safety net of knowing that the
> return types were correct while I was mocking (at least thats what I
> remember).

Hmm. I'm not sure how you are suggesting this could be achieved. Ruby
methods do not declare their return type in the method declaration. I
think the best way of obtaining the safety net you describe is to use
integration tests. Alternatively you could go back to a statically
typed language ;-)

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

[1] http://rubyforge.org/tracker/index.php?func=detail&aid=16769&group_id=1917&atid=7480

From duncanbeevers at gmail.com  Wed Jan  2 15:55:31 2008
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Wed, 2 Jan 2008 12:55:31 -0800
Subject: [mocha-developer] Proxies
Message-ID: <6a2b4fd00801021255t3c1e792v9c8cfece685e78c9@mail.gmail.com>

I really like the idea of Mock Proxies as explained in Brian Takita's post here:
http://pivots.pivotallabs.com/users/brian/blog/articles/352-introducing-rr

I posted to this list eariler with an incomplete implementation of
.stops_mocking in the thread "Mocking Time, delegating to original
object."  The Mock Proxy pattern would make this simpler.

Proxy(User).expects(:find).with(99) # Sets expectation, forwards
method invocation to original class
User.expects(:find).with(99).returns(nil).then.proxies # Canned
response, then forwards successive invocations to original class.

Most of this is just my desire to be lazy and not actually have to
unit-test *trivial* methods explicitly.  I also like the idea of using
the Mock Proxy to exercise the behavior of simple private instance
methods of my class which are kind of a pain to test currently, which
leads to my not making anything private.

On Jan 2, 2008 6:50 AM, James Mead <jamesmead44 at gmail.com> wrote:
>
> On 05/11/2007, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> > The block syntax looks excellent, and reads very nicely.  I especially
> > like the idea of not having to pass in the mock to the block to stick
> > the expectations onto, and instead just continue fluently adding
> > expectations.
> >
> > This block syntax also feels like the right direction to go if there
> > were to be some kind of expectations on the ordering of method calls.
> > I haven't run into a testing situation where I've needed to test the
> > ordering of calls on a mock explicitly, but flex mock provides a
> > grouping mechanism.
> >
> > For the corollary in FlexMock, check out #ordered
> > http://onestepback.org/software/flexmock/classes/FlexMock/Expectation.html#M000082
> >
> > Don't take me too seriously, but I think mocha could trump flexmock's
> > with something like:
> >
> > mock_user = mock('User') do
> >   initially.expects(:first_name).returns('Duncan')
> >   then.expects(:last_name).returns('Beevers')
> >
> >   later.expects(:birthday).returns('a gentleman never asks')
> >   then.expects(:astrological_sign).returns('Virgo')
> >
> >   stubs(:favorite_color).returns('silver')
> >
> >   finally.expects(:goodnight!).returns('same to you')
> > end
> >
> > Where the temporal prefixes initially, finally, then and later
> > indicate method call ordering, and expectations without a temporal
> > prefix can be called freely.
> >
> > Am I pulling this out of my ass?  Yes.
> >
> > On Nov 4, 2007 3:19 PM, James Mead <jamesmead44 at gmail.com> wrote:
> > >
> > > On 04/11/2007, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> > > >
> > > > I was reading through the FlexMock docs and noticed the expectation
> > > > method .mock, which returns the original mock associated with an
> > > > expectation.
> > > >
> > > > It looks really handy for writing nice all-in-one mocks like:
> > > >
> > > > mock_user = mock('User').expects(:first_name).returns('Jonah').mock
> > > >
> > > > So I started playing around with mocha and found I could actually
> > > > already do this!
> > > > But I'm not sure how.  There's no attr_reader on @mock, and I couldn't
> > > > find out where this method is defined.
> > > >
> > > > So, perhaps we could add this an explicit method on Expectation and
> > > > include a little rdoc on it?
> > > > I think a lot of people would get benefit from making this explicit.
> > > >
> > > > Opinions?
> > > >
> > >
> > > Hmm. I think this may have disappeared in some recent refactoring in trunk.
> > > Rather than exposing too much of the internals, I keep meaning to add a
> > > syntax like this...
> > >
> > >   mock_user = mock('User') {
> > >     expects(:first_name).returns('James')
> > >     stubs(:last_name).returns('Mead')
> > >   }
> > >
> > > Would that help you do what you want to do...?
> > >
> > > Alternatively did you know you could already do...
> > >
> > >   mock_user = mock('User', :first_name => 'James', :last_name => 'Mead')
> > >
> > > However there are a couple of limitations with this - you can't mix expects
> > > & stubs and you can't specify anything other than a returns() e.g. no
> > > with(), no raises(), etc.
> > >
> > >
> > > What do you think?
> > > --
> > > James.
> > > http://blog.floehopper.org
> > > http://tumble.floehopper.org
> > > _______________________________________________
> > > 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
> >
>
> Sorry for taking ages to respond to this. I just wanted to let you
> know that since revision 193 (which is included in gem 0.5.6), the
> initializer block syntax has been available. Unfortunately the rdoc
> didn't get updated until revision 221 (which hasn't yet been
> released).
>
> Since your email, I've added support for JMock2 style sequences [1]
> and states [2] which allow you to constrain the order of invocation. I
> haven't yet sorted out the error reporting and there may be some
> teething problems, but feel free to give it a try. All the rdoc has
> been updated in trunk. See AutoVerify#sequence and AutoVerify#states
> for details.
>
> In the meantime - thanks for you interest and your suggestions.
> --
> James.
> http://blog.floehopper.org
> http://tumble.floehopper.org
>
> [1] http://jmock.org/sequences.html
> [2] http://jmock.org/states.html
>
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From duncanbeevers at gmail.com  Wed Jan  2 16:08:58 2008
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Wed, 2 Jan 2008 13:08:58 -0800
Subject: [mocha-developer] Stubbing yielding methods
In-Reply-To: <1db558f00801020715t2bcbb66fm4f3331b9a38fa7ec@mail.gmail.com>
References: <1db558f00709210813k8079b1dn278181f971576e8d@mail.gmail.com>
	<6a2b4fd00709211330p49acf6dcia55c9557497dc6aa@mail.gmail.com>
	<1db558f00801020715t2bcbb66fm4f3331b9a38fa7ec@mail.gmail.com>
Message-ID: <6a2b4fd00801021308v35cdc52fude586b521620a874@mail.gmail.com>

Yeah, the upcasing_block example should be two tests; one testing the
behavior of the block and the other testing that up_them_all applies a
block to list in a certain fashion.

The upcasing_block created in the test is not the same as the one
(speculatively) declared in the Upperizer.  Checking arity is a great
start, but perhaps we could capture the block in Upperizer and then do
some checks on it?

def test_up_them_all
  list_of_words = [ 'socks', 'mittens', 'flashlight' ]
  upcasing_block = mock_block('Upcasing Block').arity(1)
  list_of_words.expects(:map).with_block(upperizing_block)

  u = Upperizer.new
  u.up_them_all(list_of_words) # Invoking up_them_all captures upcasing_block

  assert_equal 'HONK', upcasing_block('honk') # Let's test it in isolation
end

Still feels kind of weird to pull data out of a class this way, but
anonymous lambdas are slippery and you gotta grab when you can!


On Jan 2, 2008 7:15 AM, James Mead <jamesmead44 at gmail.com> wrote:
>
> On 21/09/2007, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> > It's certainly necessary to test the code tucked away into these
> > blocks, but I feel like yielding is testing in the wrong direction.
> >
> > Instead of yielding values or mocks into the block, perhaps we can
> > check metadata about the provided block (arity, required params) and
> > then test the functionality of the block explicitly.
> >
> > class Test::Unit::TestCase
> >   def test_up_them_all
> >     upcasing_block = lambda { |e| e.upcase }
> >
> >     list_of_words = [ 'socks', 'mittens', 'flashlight' ]
> >     list_of_words.expects(:map).with_block(upcasing_block)
> >
> >     u = Upperizer.new
> >     u.up_them_all(list_of_words)
> >
> >     assert_equal 'HONK', upcasing_block('honk')
> >   end
> > end
> >
> >
> > On 9/21/07, James Mead <jamesmead44 at gmail.com> wrote:
> > > I've just been tying my brain in knots looking at bug #8687 (
> > > http://rubyforge.org/tracker/index.php?func=detail&aid=8687&group_id=1917&atid=7477
> > > ).
> > >
> > > I've been (1) trying to work out whether there is anything logically wrong
> > > with Mocha's existing behaviour and (2) whether Mocha should support the
> > > requested functionality.
> > >
> > > It all centres around the use of the Expectation#yields method. I've put a
> > > couple of examples together to try and help me think about it. The first one
> > > (http://pastie.caboo.se/99412) is a simplified version of the example in the
> > > bug report using a block and stubbing a method that yields to that block.
> > >
> > > In the second example (http://pastie.caboo.se/99413) I tried to think about
> > > how it would work if I converted the block to a method on an object. I
> > > slightly ran out of steam on this one when I realised that in this case when
> > > I realised Executor#execute wouldn't be called because the implementation of
> > > Collaborator#yielding_method is stubbed.
> > >
> > > This made me wonder if the Expectation#yields method should exist at all! In
> > > particular, in the block example, it feels odd because you are going from
> > > real code (ClassUnderTest) into mock code (mocked version of Collaborator)
> > > and back into real code (the block itself). I wonder if this is really
> > > sensible and/or useful.
> > >
> > > Has anybody got any thoughts?
> > >
> > > Thanks.
> > > --
> > > James.
> > > http://blog.floehopper.org
> > > http://tumble.floehopper.org
> > > _______________________________________________
> > > 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
> >
>
> This is certainly the direction I was starting to think about. I think
> the thing that is not clear from your example is where the Upperizer
> gets its *real* upcasing_block from. Also is this upcasing_block the
> same instance as the one in the local variable in the test?
>
> Do you think it's sufficient to only check the arity of the block? In
> which case you wouldn't actually need to supply the upcasing_block in
> the with_block clause, you could just specify the block's arity.
> Something along the lines of with_block_having_arity(1).
>
> What do you think?
> --
>
> James.
> http://blog.floehopper.org
> http://tumble.floehopper.org
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>

From jamesmead44 at gmail.com  Sun Jan 20 12:11:04 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Sun, 20 Jan 2008 17:11:04 +0000
Subject: [mocha-developer] Bug #17118 - expectations should take precedence
	over stubs
Message-ID: <1db558f00801200911y2579894fj16268afb8b6537a1@mail.gmail.com>

I wanted to draw attention to this bug report [A] which highlights a change
that was made between Mocha 0.4 and 0.5.

It may have lead to tests which pass unexpectedly. Does my explanation
(below) make sense to people?

It feels like we should at least add some warnings to the documentation.

You are correct that this behaviour did change between Mocha v0.4.0 and
> v0.5.0 (in revision 115).
>
> The idea of this change was to bring Mocha into line with jMock v1 [1] so
> that it stops matching expectations when the maximum number of expected
> invocations is reached. You are suffering from "gotcha" number 2 in that
> jMock reference: "if you create a stub and then an expectation for the same
> method, the expectation will match, and when it stops matching the stub will
> be used instead, possibly masking test failures". In your example, the
> "never" expectation will never match because it has already reached its
> maximum number of expected invocations, but Mocha will then find the stub
> which does match.
>
> Personally I prefer not to use setup methods, I prefer to make tests as
> self-contained as possible [2]. I find this makes tests more maintainable
> (albeit at the expense of some duplication). So in this case I would prefer
> to *explicitly* put the stub expectation in every test that needed it. If
> setting up the stub expectation was complex or multiple stub expectations
> were needed I would extract that into a descriptive method and call it
> explicitly from each test that needed it.
>
> If you don't like this approach, you do have another alternative. Using
> "edge" Mocha (i.e. revision 233 or later), you should be able to use the
> state-machine feature to achieve your goal [2]. This should be released as a
> gem soon.
>
> Thanks, James.
> http://blog.floehopper.org
>
> [1] "Stubs, Expectations and the Dispatch of Mocked Methods"
> http://www.jmock.org/jmock1-dispatch.html
> [2] "Testing: Inline Setup"
> http://blog.jayfields.com/2007/06/testing-inline-setup.html
> [3] OverrideExpectationsFromSetUpAcceptanceTest
> http://pastie.caboo.se/141188
>

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

[A] http://tinyurl.com/29ba6d

From jamesmead44 at gmail.com  Mon Jan 21 10:21:38 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 21 Jan 2008 15:21:38 +0000
Subject: [mocha-developer] Bug #17118 - expectations should take
	precedence over stubs
In-Reply-To: <1db558f00801200911y2579894fj16268afb8b6537a1@mail.gmail.com>
References: <1db558f00801200911y2579894fj16268afb8b6537a1@mail.gmail.com>
Message-ID: <1db558f00801210721t9035db9p3e6e83b1f55483a7@mail.gmail.com>

FYI - a new documentation page has been added for jMock2 "Overriding
Expectations Defined in the Test Set-Up" [1].

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

[1] http://www.jmock.org/override.html

From jamesmead44 at gmail.com  Mon Jan 21 12:34:54 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 21 Jan 2008 17:34:54 +0000
Subject: [mocha-developer] Bug #17118 - expectations should take
	precedence over stubs
In-Reply-To: <1db558f00801210721t9035db9p3e6e83b1f55483a7@mail.gmail.com>
References: <1db558f00801200911y2579894fj16268afb8b6537a1@mail.gmail.com>
	<1db558f00801210721t9035db9p3e6e83b1f55483a7@mail.gmail.com>
Message-ID: <1db558f00801210934t5dcbd054q42346aa3455d9921@mail.gmail.com>

Sorry Dan - for some reason MailMan's content filtering didn't like your
signature attachment or something...

---------- Forwarded message ----------
From: Dan North <dan at tastapod.com>
To: mocha-developer at rubyforge.org
Date: Sun, 20 Jan 2008 21:22:00 +0000
Subject: Re: [mocha-developer] Bug #17118 - expectations should take
precedence over stubs

Hi James.

I agree in principle but disagree in this specific case (the never()
expectation).

For my two penn'orth, never() should both match and fail fast if an
invocation matches. It shouldn't matter whether or not you have a stub (so
stubbing in a setup method would be irrelevant in this case, but it's still
icky).

Cheers,
Dan

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

From jay at jayfields.com  Mon Jan 21 13:42:33 2008
From: jay at jayfields.com (Jay Fields)
Date: Mon, 21 Jan 2008 10:42:33 -0800
Subject: [mocha-developer] stubs! method
Message-ID: <FE3B7307-DEFF-45AE-9129-F63DF7BA846B@jayfields.com>

Hello James et al.

I try to set only one expectation per test, but I also dislike having  
extra stub declarations that are no longer used, thus I often find  
myself wanting Object.expects(:foo).at_least_once. That works, but I  
don't actually "expect" foo to be called, in fact, I don't care, I  
only want to know when it isn't called so I can remember to clean up  
the test. Since I don't "expect" foo, it's also quite verbose for my  
purpose.

Given the above, I'd really like a .stubs! method. The .stubs! method  
would convey that this is a stub and is unimportant for the test;  
however, if you don't call the method at least once, it will remind  
you to remove the stub.

I also think that stubs! is appropriate given that the intended use  
of ! methods is "the dangerous version of a method". I'd say a stub  
that raises an exception if it's never called is definitely the  
dangerous version of the method.

Thoughts?

Cheers, Jay

From jamesmead44 at gmail.com  Mon Jan 21 15:52:01 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 21 Jan 2008 20:52:01 +0000
Subject: [mocha-developer] stubs! method
In-Reply-To: <FE3B7307-DEFF-45AE-9129-F63DF7BA846B@jayfields.com>
References: <FE3B7307-DEFF-45AE-9129-F63DF7BA846B@jayfields.com>
Message-ID: <1db558f00801211252i50306219n1031e432c82eff5e@mail.gmail.com>

On 21/01/2008, Jay Fields <jay at jayfields.com> wrote:
>
> I try to set only one expectation per test, but I also dislike having
> extra stub declarations that are no longer used, thus I often find
> myself wanting Object.expects(:foo).at_least_once. That works, but I
> don't actually "expect" foo to be called, in fact, I don't care, I
> only want to know when it isn't called so I can remember to clean up
> the test. Since I don't "expect" foo, it's also quite verbose for my
> purpose.
>
> Given the above, I'd really like a .stubs! method. The .stubs! method
> would convey that this is a stub and is unimportant for the test;
> however, if you don't call the method at least once, it will remind
> you to remove the stub.
>
> I also think that stubs! is appropriate given that the intended use
> of ! methods is "the dangerous version of a method". I'd say a stub
> that raises an exception if it's never called is definitely the
> dangerous version of the method.
>
> Thoughts?
>

On 21/01/2008, Jay Fields <jay at jayfields.com> wrote:
>
> I try to set only one expectation per test, but I also dislike having
> extra stub declarations that are no longer used, thus I often find
> myself wanting Object.expects(:foo).at_least_once. That works, but I
> don't actually "expect" foo to be called, in fact, I don't care, I
> only want to know when it isn't called so I can remember to clean up
> the test. Since I don't "expect" foo, it's also quite verbose for my
> purpose.
>
> Given the above, I'd really like a .stubs! method. The .stubs! method
> would convey that this is a stub and is unimportant for the test;
> however, if you don't call the method at least once, it will remind
> you to remove the stub.
>
> I also think that stubs! is appropriate given that the intended use
> of ! methods is "the dangerous version of a method". I'd say a stub
> that raises an exception if it's never called is definitely the
> dangerous version of the method.
>
> Thoughts?
>

Coincidentally, I've been playing with generating a warning in this
scenario. My initial reaction to your suggestion is that I'd rather not add
more clutter to the main API if the warning solution is good enough, but I'd
be interested to hear what others think. If a warning isn't sufficient,
perhaps we could have different levels of behaviour - relaxed, warning,
paranoid - which do nothing, print a warning, or raise an exception
respectively.

Incidentally, I was thinking of doing something similar for when setting an
expectation on a non-mock object which doesn't implement that method (or its
not public). I'd be interested in your thoughts on that too.

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

From jay at jayfields.com  Mon Jan 21 15:57:08 2008
From: jay at jayfields.com (Jay Fields)
Date: Mon, 21 Jan 2008 12:57:08 -0800
Subject: [mocha-developer] stubs! method
In-Reply-To: <1db558f00801211252i50306219n1031e432c82eff5e@mail.gmail.com>
References: <FE3B7307-DEFF-45AE-9129-F63DF7BA846B@jayfields.com>
	<1db558f00801211252i50306219n1031e432c82eff5e@mail.gmail.com>
Message-ID: <F8BA551C-B47A-4951-BF69-972CBEAF404B@jayfields.com>

> Coincidentally, I've been playing with generating a warning in this
> scenario.

I think a warning is perfect for me on both scenarios.

Cheers, Jay

From jamesmead44 at gmail.com  Tue Jan 22 04:21:06 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 22 Jan 2008 09:21:06 +0000
Subject: [mocha-developer] stubs! method
In-Reply-To: <F8BA551C-B47A-4951-BF69-972CBEAF404B@jayfields.com>
References: <FE3B7307-DEFF-45AE-9129-F63DF7BA846B@jayfields.com>
	<1db558f00801211252i50306219n1031e432c82eff5e@mail.gmail.com>
	<F8BA551C-B47A-4951-BF69-972CBEAF404B@jayfields.com>
Message-ID: <1db558f00801220121s55a6da6bs3e1dcbad69f816d6@mail.gmail.com>

On 21/01/2008, Jay Fields <jay at jayfields.com> wrote:
>
> I think a warning is perfect for me on both scenarios.
>

Cool.

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

From duncanbeevers at gmail.com  Mon Jan 28 14:36:50 2008
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Mon, 28 Jan 2008 11:36:50 -0800
Subject: [mocha-developer] Nested matchers
Message-ID: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>

We're encountering a failure with Mocha 0.5.6.

We had this expectation:

game_version.expects(:attributes=).with(:game_file =>
kind_of(GameFile), :game_id => @game.id)

This expectation was passing with 0.5.5, but fails with 0.5.6.

I added this test to parameter_matcher_acceptance_test.rb, which
passes in 0.5.5 and fails in 0.5.6

  def test_should_match_nested_parameters
    test_result = run_test do
      mock = mock()
      mock.expects(:method).with(:literal_key => kind_of(Integer))
      mock.method(:literal_key => 1)
    end
    assert_passed(test_result)
  end

Any insight?

From ned.wolpert at gmail.com  Mon Jan 28 15:02:28 2008
From: ned.wolpert at gmail.com (Ned Wolpert)
Date: Mon, 28 Jan 2008 13:02:28 -0700
Subject: [mocha-developer] Nested matchers
In-Reply-To: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
Message-ID: <33cb339b0801281202n7c75d789x90d3965a9a09c7f5@mail.gmail.com>

I'm also seeing a problem.  I haven't researched it enough, but here's
what's going on in a nutshell...

I have this line:

  outfile.stubs(:each_line).times(2).returns('1234512123\n','abcdefgxyz\n')

and then the object 'outfile' is passed in to another method that
called 'each_line' in a loop with result from the called being
'yield'ed... In a nutshell, like this

    fwr.process_file(outfile) do |array|
      validate_data(array)
    end

I'm not sure exactly where the error is, but this code hasn't changed
in a long time, but with the latest mocha, broke. I'm still
researching what is actually broken, but I kinda hope that this bit of
debug is helpful...

On Jan 28, 2008 12:36 PM, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> We're encountering a failure with Mocha 0.5.6.
>
> We had this expectation:
>
> game_version.expects(:attributes=).with(:game_file =>
> kind_of(GameFile), :game_id => @game.id)
>
> This expectation was passing with 0.5.5, but fails with 0.5.6.
>
> I added this test to parameter_matcher_acceptance_test.rb, which
> passes in 0.5.5 and fails in 0.5.6
>
>   def test_should_match_nested_parameters
>     test_result = run_test do
>       mock = mock()
>       mock.expects(:method).with(:literal_key => kind_of(Integer))
>       mock.method(:literal_key => 1)
>     end
>     assert_passed(test_result)
>   end
>
> Any insight?
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>



-- 
Virtually, Ned Wolpert
http://www.codeheadsystems.com/blog/

"Settle thy studies, Faustus, and begin..."   --Marlowe

From duncanbeevers at gmail.com  Mon Jan 28 16:54:38 2008
From: duncanbeevers at gmail.com (Duncan Beevers)
Date: Mon, 28 Jan 2008 13:54:38 -0800
Subject: [mocha-developer] Nested matchers
In-Reply-To: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
Message-ID: <6a2b4fd00801281354p6b4dc063xf538c0f9f196f28b@mail.gmail.com>

So we cleared this up by making the kind_of matcher to return true
when tested for equality with an instance of the class it is supposed
to match on.

Diff is attached, the important bit is here in kind_of.rb:

       def matches?(available_parameters)
         parameter = available_parameters.shift
-        parameter.kind_of?(@klass)
+        self == parameter
       end
+
+      def ==(to_compare)
+        to_compare.kind_of?(@klass)
+      end

Feelings?

On Jan 28, 2008 11:36 AM, Duncan Beevers <duncanbeevers at gmail.com> wrote:
> We're encountering a failure with Mocha 0.5.6.
>
> We had this expectation:
>
> game_version.expects(:attributes=).with(:game_file =>
> kind_of(GameFile), :game_id => @game.id)
>
> This expectation was passing with 0.5.5, but fails with 0.5.6.
>
> I added this test to parameter_matcher_acceptance_test.rb, which
> passes in 0.5.5 and fails in 0.5.6
>
>   def test_should_match_nested_parameters
>     test_result = run_test do
>       mock = mock()
>       mock.expects(:method).with(:literal_key => kind_of(Integer))
>       mock.method(:literal_key => 1)
>     end
>     assert_passed(test_result)
>   end
>
> Any insight?
>

From jamesmead44 at gmail.com  Mon Jan 28 18:59:02 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Mon, 28 Jan 2008 23:59:02 +0000
Subject: [mocha-developer] Nested matchers
In-Reply-To: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
Message-ID: <1db558f00801281559y535782b9ge9ecb4cf6ed88b31@mail.gmail.com>

On 28/01/2008, Duncan Beevers <duncanbeevers at gmail.com> wrote:
>
> We're encountering a failure with Mocha 0.5.6.
>
> We had this expectation:
>
> game_version.expects(:attributes=).with(:game_file =>
> kind_of(GameFile), :game_id => @game.id)
>
> This expectation was passing with 0.5.5, but fails with 0.5.6.
>
> I added this test to parameter_matcher_acceptance_test.rb, which
> passes in 0.5.5 and fails in 0.5.6
>
>   def test_should_match_nested_parameters
>     test_result = run_test do
>       mock = mock()
>       mock.expects(:method).with(:literal_key => kind_of(Integer))
>       mock.method(:literal_key => 1)
>     end
>     assert_passed(test_result)
>   end
>
> Any insight?
>

Sorry. I previously explained this change when it was made in trunk [1]. I
had intended to warn people again when the change was released, but I
released v0.5.6 in a bit of a hurry to provide Ruby v1.9 compatibility and
the change slipped out.

I hadn't realised people were using the matchers in this way. I think a
better solution is to make the HasEntry parameter matcher (and friends)
convert its key & value to parameter matchers using #to_matcher and to
compare these using #matches? In this way you would be able to do something
like...

  def test_should_match_nested_parameters
   test_result = run_test do
     mock = mock()
     mock.expects(:method).with(has_entry(:literal_key => kind_of(Integer)))
     mock.method(:literal_key => 1)
   end
   assert_passed(test_result)
  end

I've checked in some changes in revision 245 of trunk if you want to try
them out. Let me know if I've misunderstood or made a mistake.
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

[1] http://rubyforge.org/pipermail/mocha-developer/2007-November/000482.html

From jamesmead44 at gmail.com  Mon Jan 28 19:03:40 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 29 Jan 2008 00:03:40 +0000
Subject: [mocha-developer] Nested matchers
In-Reply-To: <33cb339b0801281202n7c75d789x90d3965a9a09c7f5@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
	<33cb339b0801281202n7c75d789x90d3965a9a09c7f5@mail.gmail.com>
Message-ID: <1db558f00801281603n6387dccco158cb13228e9dbe7@mail.gmail.com>

On 28/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote:
>
> I'm also seeing a problem.  I haven't researched it enough, but here's
> what's going on in a nutshell...
>
> I have this line:
>
>   outfile.stubs
> (:each_line).times(2).returns('1234512123\n','abcdefgxyz\n')
>
> and then the object 'outfile' is passed in to another method that
> called 'each_line' in a loop with result from the called being
> 'yield'ed... In a nutshell, like this
>
>     fwr.process_file(outfile) do |array|
>       validate_data(array)
>     end
>
> I'm not sure exactly where the error is, but this code hasn't changed
> in a long time, but with the latest mocha, broke. I'm still
> researching what is actually broken, but I kinda hope that this bit of
> debug is helpful...
>

It's not obvious that this is the same error or bug.

Can you give more details i.e. the simplest self-contained failing test (and
code under test) you can write or (ideally) a failing acceptance test like
Duncan did.

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

From jamesmead44 at gmail.com  Mon Jan 28 19:16:48 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 29 Jan 2008 00:16:48 +0000
Subject: [mocha-developer] Nested matchers
In-Reply-To: <6a2b4fd00801281354p6b4dc063xf538c0f9f196f28b@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
	<6a2b4fd00801281354p6b4dc063xf538c0f9f196f28b@mail.gmail.com>
Message-ID: <1db558f00801281616i6f57c18dgf8d9c5afcf538395@mail.gmail.com>

On 28/01/2008, Duncan Beevers <duncanbeevers at gmail.com> wrote:
>
> So we cleared this up by making the kind_of matcher to return true
> when tested for equality with an instance of the class it is supposed
> to match on.
>
> Diff is attached, the important bit is here in kind_of.rb:
>
>        def matches?(available_parameters)
>          parameter = available_parameters.shift
> -        parameter.kind_of?(@klass)
> +        self == parameter
>        end
> +
> +      def ==(to_compare)
> +        to_compare.kind_of?(@klass)
> +      end
>
> Feelings?


Well done for finding a fix :-)

The idea of the change to the parameter matchers interface that I mentioned
above [1] is that a matcher can now match against an arbitrary number of
parameters. In particular this is used to allow for constraints on optional
parameters as seen in OptionalParameterMatcherAcceptanceTest, for example:

  def
test_should_pass_if_all_required_and_optional_parameters_match_and_some_optional_parameters_are_supplied
    test_result = run_test do
      mock = mock()
      mock.expects(:method).with(1, 2, optionally(3, 4))
      mock.method(1, 2, 3)
    end
    assert_passed(test_result)
  end

The #==(object) method wasn't really suitable for this, hence the change to
use the #matches?(available_parameters) method.

I hope this makes sense and I hope my previous suggestion of using the new
improved has_entry matcher is satisfactory. The reference [1] is still worth
a read as are the code examples it references.

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

[1] http://rubyforge.org/pipermail/mocha-developer/2007-November/000482.html

From ned.wolpert at gmail.com  Tue Jan 29 10:22:31 2008
From: ned.wolpert at gmail.com (Ned Wolpert)
Date: Tue, 29 Jan 2008 08:22:31 -0700
Subject: [mocha-developer] Nested matchers
In-Reply-To: <1db558f00801281603n6387dccco158cb13228e9dbe7@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
	<33cb339b0801281202n7c75d789x90d3965a9a09c7f5@mail.gmail.com>
	<1db558f00801281603n6387dccco158cb13228e9dbe7@mail.gmail.com>
Message-ID: <33cb339b0801290722q1156c1f1xb190cde222678ac3@mail.gmail.com>

I wasn't sure that this was the same thing... but I did notice that it
broke (or I should stay, stopped working as expected) in the last
mocha release... I'm going to investigate this today and if I think
there is a problem with Mocha, I'll post a test-case.

On Jan 28, 2008 5:03 PM, James Mead <jamesmead44 at gmail.com> wrote:
> On 28/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote:
> >
> > I'm also seeing a problem.  I haven't researched it enough, but here's
> > what's going on in a nutshell...
> >
> > I have this line:
> >
> >   outfile.stubs
> > (:each_line).times(2).returns('1234512123\n','abcdefgxyz\n')
> >
> > and then the object 'outfile' is passed in to another method that
> > called 'each_line' in a loop with result from the called being
> > 'yield'ed... In a nutshell, like this
> >
> >     fwr.process_file(outfile) do |array|
> >       validate_data(array)
> >     end
> >
> > I'm not sure exactly where the error is, but this code hasn't changed
> > in a long time, but with the latest mocha, broke. I'm still
> > researching what is actually broken, but I kinda hope that this bit of
> > debug is helpful...
> >
>
> It's not obvious that this is the same error or bug.
>
> Can you give more details i.e. the simplest self-contained failing test (and
> code under test) you can write or (ideally) a failing acceptance test like
> Duncan did.
>
> Thanks.
> --
> James.
> http://blog.floehopper.org
> http://tumble.floehopper.org
>
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>



-- 
Virtually, Ned Wolpert
http://www.codeheadsystems.com/blog/

"Settle thy studies, Faustus, and begin..."   --Marlowe

From ned.wolpert at gmail.com  Tue Jan 29 11:24:51 2008
From: ned.wolpert at gmail.com (Ned Wolpert)
Date: Tue, 29 Jan 2008 09:24:51 -0700
Subject: [mocha-developer] Nested matchers
In-Reply-To: <33cb339b0801290722q1156c1f1xb190cde222678ac3@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
	<33cb339b0801281202n7c75d789x90d3965a9a09c7f5@mail.gmail.com>
	<1db558f00801281603n6387dccco158cb13228e9dbe7@mail.gmail.com>
	<33cb339b0801290722q1156c1f1xb190cde222678ac3@mail.gmail.com>
Message-ID: <33cb339b0801290824o7257abfbp325e7933a9675585@mail.gmail.com>

Ignore my 'claim of a bug'. :-) Turns out the test case was misusing
mocha... and just needed to fix the test case.

On Jan 29, 2008 8:22 AM, Ned Wolpert <ned.wolpert at gmail.com> wrote:
> I wasn't sure that this was the same thing... but I did notice that it
> broke (or I should stay, stopped working as expected) in the last
> mocha release... I'm going to investigate this today and if I think
> there is a problem with Mocha, I'll post a test-case.
>
>
> On Jan 28, 2008 5:03 PM, James Mead <jamesmead44 at gmail.com> wrote:
> > On 28/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote:
> > >
> > > I'm also seeing a problem.  I haven't researched it enough, but here's
> > > what's going on in a nutshell...
> > >
> > > I have this line:
> > >
> > >   outfile.stubs
> > > (:each_line).times(2).returns('1234512123\n','abcdefgxyz\n')
> > >
> > > and then the object 'outfile' is passed in to another method that
> > > called 'each_line' in a loop with result from the called being
> > > 'yield'ed... In a nutshell, like this
> > >
> > >     fwr.process_file(outfile) do |array|
> > >       validate_data(array)
> > >     end
> > >
> > > I'm not sure exactly where the error is, but this code hasn't changed
> > > in a long time, but with the latest mocha, broke. I'm still
> > > researching what is actually broken, but I kinda hope that this bit of
> > > debug is helpful...
> > >
> >
> > It's not obvious that this is the same error or bug.
> >
> > Can you give more details i.e. the simplest self-contained failing test (and
> > code under test) you can write or (ideally) a failing acceptance test like
> > Duncan did.
> >
> > Thanks.
> > --
> > James.
> > http://blog.floehopper.org
> > http://tumble.floehopper.org
> >
> > _______________________________________________
> > mocha-developer mailing list
> > mocha-developer at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mocha-developer
> >
>
>
>
>
> --
> Virtually, Ned Wolpert
> http://www.codeheadsystems.com/blog/
>
> "Settle thy studies, Faustus, and begin..."   --Marlowe
>



-- 
Virtually, Ned Wolpert
http://www.codeheadsystems.com/blog/

"Settle thy studies, Faustus, and begin..."   --Marlowe

From jamesmead44 at gmail.com  Tue Jan 29 12:08:33 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 29 Jan 2008 17:08:33 +0000
Subject: [mocha-developer] Nested matchers
In-Reply-To: <33cb339b0801290722q1156c1f1xb190cde222678ac3@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
	<33cb339b0801281202n7c75d789x90d3965a9a09c7f5@mail.gmail.com>
	<1db558f00801281603n6387dccco158cb13228e9dbe7@mail.gmail.com>
	<33cb339b0801290722q1156c1f1xb190cde222678ac3@mail.gmail.com>
Message-ID: <1db558f00801290908u4f759a50oef4627c18e83c33@mail.gmail.com>

On 29/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote:
>
> I wasn't sure that this was the same thing... but I did notice that it
> broke (or I should stay, stopped working as expected) in the last
> mocha release... I'm going to investigate this today and if I think
> there is a problem with Mocha, I'll post a test-case.
>

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

From jamesmead44 at gmail.com  Wed Jan 30 03:14:11 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Wed, 30 Jan 2008 08:14:11 +0000
Subject: [mocha-developer] Nested matchers
In-Reply-To: <33cb339b0801290824o7257abfbp325e7933a9675585@mail.gmail.com>
References: <6a2b4fd00801281136n7464dd15j50cf44f6efc0b9b1@mail.gmail.com>
	<33cb339b0801281202n7c75d789x90d3965a9a09c7f5@mail.gmail.com>
	<1db558f00801281603n6387dccco158cb13228e9dbe7@mail.gmail.com>
	<33cb339b0801290722q1156c1f1xb190cde222678ac3@mail.gmail.com>
	<33cb339b0801290824o7257abfbp325e7933a9675585@mail.gmail.com>
Message-ID: <1db558f00801300014w318ce158p6f7caa96db56befc@mail.gmail.com>

On 29/01/2008, Ned Wolpert <ned.wolpert at gmail.com> wrote:
>
> Ignore my 'claim of a bug'. :-) Turns out the test case was misusing
> mocha... and just needed to fix the test case.
>

Cool. Thanks for letting us know.
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

From timocratic at gmail.com  Wed Jan 30 18:08:24 2008
From: timocratic at gmail.com (Tim Connor)
Date: Wed, 30 Jan 2008 15:08:24 -0800
Subject: [mocha-developer] Testing a call to super
In-Reply-To: <5906dd440801301458n42e8a770ob0f8991c63c4844f@mail.gmail.com>
References: <5906dd440801301458n42e8a770ob0f8991c63c4844f@mail.gmail.com>
Message-ID: <5906dd440801301508s54c4be0du67a31861520881a7@mail.gmail.com>

Did any further discussion ever come of this?  I take it is officially
not supported currently?  I just get an odd error when I try it (it
throws a "0 expected 1 received", no matter what stubbing/expectation
combo I use), so came looking around on google, and finally the
mailinglist.

Here's my stripped down example: http://pastie.caboo.se/145603 (it
fails with expects too)

Use case is the parent class has some complex functionality and you
just want to isolate and test something in the subclass.

Tim

From jamesmead44 at gmail.com  Thu Jan 31 15:05:44 2008
From: jamesmead44 at gmail.com (James Mead)
Date: Thu, 31 Jan 2008 20:05:44 +0000
Subject: [mocha-developer] Testing a call to super
In-Reply-To: <5906dd440801301508s54c4be0du67a31861520881a7@mail.gmail.com>
References: <5906dd440801301458n42e8a770ob0f8991c63c4844f@mail.gmail.com>
	<5906dd440801301508s54c4be0du67a31861520881a7@mail.gmail.com>
Message-ID: <1db558f00801311205p141e3e8ag2fc8e9511339503f@mail.gmail.com>

On 30/01/2008, Tim Connor <timocratic at gmail.com> wrote:
>
> Did any further discussion ever come of this?  I take it is officially
> not supported currently?  I just get an odd error when I try it (it
> throws a "0 expected 1 received", no matter what stubbing/expectation
> combo I use), so came looking around on google, and finally the
> mailinglist.
>
> Here's my stripped down example: http://pastie.caboo.se/145603 (it
> fails with expects too)
>
> Use case is the parent class has some complex functionality and you
> just want to isolate and test something in the subclass.


Hi Tim,

I'm afraid you're right - this behaviour isn't currently supported. Using a
version from trunk (after revision 233 when I added position information to
all evals as suggested by Ola Bini [1]), you'll get a slightly more useful
error message. Basically both the Parent & Child classes have their own
"any_instance" mock object. When you call Parent.any_instance.stubs(:say),
the expectation is added to the Parent's "any_instance" mock object. However
when the instance of Child calls super, this is intercepted by the Child's
"any_instance" mock object which has no expectations.

I'm sorry to say, making this work isn't going to be a priority for me, but
I'd be more than happy to consider a patch ;-)

Thanks for your interest.
-- 
James.
http://blog.floehopper.org
http://tumble.floehopper.org

[1]
http://ola-bini.blogspot.com/2008/01/ruby-antipattern-using-eval-without.html

From timocratic at gmail.com  Thu Jan 31 15:15:20 2008
From: timocratic at gmail.com (Tim Connor)
Date: Thu, 31 Jan 2008 12:15:20 -0800
Subject: [mocha-developer] Testing a call to super
In-Reply-To: <1db558f00801311205p141e3e8ag2fc8e9511339503f@mail.gmail.com>
References: <5906dd440801301458n42e8a770ob0f8991c63c4844f@mail.gmail.com>
	<5906dd440801301508s54c4be0du67a31861520881a7@mail.gmail.com>
	<1db558f00801311205p141e3e8ag2fc8e9511339503f@mail.gmail.com>
Message-ID: <5906dd440801311215j2fb1177dmf0ba02a75aa3b5cd@mail.gmail.com>

heh, yeah, I figured it would be painful to do.  I just manually
aliased, redefed, and then aliased back after the test.  Ugly, but it
worked.  My primary concern/confusion was the weird error.  Glad to
here it throws something more explicit, now.

Maybe I'll play with it when I really need to work on my ruby-fu some
more.  I bet it's the sort of problem that would really sharpen ones
ax. ;)

Tim

On Jan 31, 2008 12:05 PM, James Mead <jamesmead44 at gmail.com> wrote:
>
> On 30/01/2008, Tim Connor <timocratic at gmail.com> wrote:
> >
> > Did any further discussion ever come of this?  I take it is officially
> > not supported currently?  I just get an odd error when I try it (it
> > throws a "0 expected 1 received", no matter what stubbing/expectation
> > combo I use), so came looking around on google, and finally the
> > mailinglist.
> >
> > Here's my stripped down example: http://pastie.caboo.se/145603 (it
> > fails with expects too)
> >
> > Use case is the parent class has some complex functionality and you
> > just want to isolate and test something in the subclass.
>
>
> Hi Tim,
>
> I'm afraid you're right - this behaviour isn't currently supported. Using a
> version from trunk (after revision 233 when I added position information to
> all evals as suggested by Ola Bini [1]), you'll get a slightly more useful
> error message. Basically both the Parent & Child classes have their own
> "any_instance" mock object. When you call Parent.any_instance.stubs(:say),
> the expectation is added to the Parent's "any_instance" mock object. However
> when the instance of Child calls super, this is intercepted by the Child's
> "any_instance" mock object which has no expectations.
>
> I'm sorry to say, making this work isn't going to be a priority for me, but
> I'd be more than happy to consider a patch ;-)
>
> Thanks for your interest.
> --
> James.
> http://blog.floehopper.org
> http://tumble.floehopper.org
>
> [1]
> http://ola-bini.blogspot.com/2008/01/ruby-antipattern-using-eval-without.html
> _______________________________________________
> mocha-developer mailing list
> mocha-developer at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mocha-developer
>