Re: [MO-java-users] Re: [MO-java-dev] Cretion of the dynamic mocks for classes vs. interfaces

[eu <eu...@md...>]

Nat Pryce wrote:

>>  I faced that issue too. But my understanding was that I can and should 
>>use "match" for such calls. So all "expect"-like calls will be in order 
>>and all "match"-like calls can appear anywhere. Otherwise it will be just 
>>not possible to handle different returns for the sequential calls 
>>without or with the same parameters.
>>    
>>
>The issue with an ordered InvocationDispatcher is that it makes tests
>too brittle.  In general, one needs to specify that some calls are
>stubbed (matched in the 0.09 parlance), some are expected after others
>and some are expected but not in any order.  Requiring that *all* calls
>are expected in a fixed order makes tests easy to break when code is
>changed over time.  It is also quite a rare case -- I've only needed it
>when testing some quite baroque event announcement code. And even then
>it broke tests later!
>
>Our new approach is to provide an API that is used to specify that one
>invocation is expected to occur after another.  This has the benefits
>that it highlights the ordering in the test and allows *partial*
>ordering, which gives much needed flexibility to the test code.
>  
>
 I see. That is sounds reasonable. In other words you are going to add 
chaining of expectations but not through invocation handler. Basically 
expectation on to be called after some other expectation. I can imagine 
something like that.

  exp1 = mock.expect( "method1", C.args(...));
  exp2 = mock.expect( "method1", C.after( exp1, C.args(...)));
  exp2 = mock.expect( "method1", C.after( exp2, C.args(...)));
  ...

  This should be great.

  regards,
  Eugene

PS: what about the 1.0 release? Is anybody know the answer yet?