I've tracked down the code that causes this behavior and it's pretty deep in the system. ReplayDynamicMockState is the one making the decision to ignore the extra call and just return the default value but the problem is that it relies on MethodRecordBase.GetRecordedExpectationOrNull to return Null for this behavior.
The safest place to make a change would appear to be ReplayDynamicMockState but this doesn't work because it needs an expectation so it can tell it to return or throw. The problem being that we don't an expectation since the return of a null expectation is what triggers this behavior. There appears to be a lot of other code that all relies on GetRecordedExpectationOrNull so changing it's behavior seems like an unsafe idea but I don't see how the problem can be fixed without doing so. Look at the else statement in ReplayDynamicMockState.DoMethodCall to get a better idea of what I mean... Thoughts? On Feb 17, 1:07 pm, Shane Courtrille <[email protected]> wrote: > Haha I know I did.. I was just hoping someone else would have the time > so I can spend a little bit of my time with my family.. if not.. then > I shall follow the Ayende method of "Fix the things that bug you" > > On Tue, Feb 17, 2009 at 12:56 PM, Ayende Rahien <[email protected]> wrote: > > I think that you just vulanteered > > > On Tue, Feb 17, 2009 at 2:54 PM, Shane C <[email protected]> wrote: > > >> Agreed. This really does not seem like correct behavior. So who has > >> time to create & send Ayende a patch? :D > > >> On Feb 17, 12:41 am, ssteinegger <[email protected]> wrote: > >> > This also means, that Repeat.Times never makes sense on a dynamic > >> > mock, because it is the same as Repeat.AtLeast (but doesn't say this). > >> > Independent of the syntax, this is not so nice. Repeat.Times (or Once > >> > or Never) should always be kind of strict. > > >> > On 13 Feb., 15:28, Tim Barcz <[email protected]> wrote: > > >> > > I'll toss in my two cents.... > > >> > > If it's a strict mock, should throw an exception.... > >> > > If it's a dynamic mock this is expected. > > >> > > If we start treating the syntax different between strict and dynamic > >> > > mocks I > >> > > think the learning curve goes up. Right now the differences in > >> > > behavior lie > >> > > within which mock object you use and NOT the syntax you use on the > >> > > mock, > >> > > which is how I personally prefer it. > > >> > > Tim > > >> > > On Fri, Feb 13, 2009 at 8:23 AM, ssteinegger <[email protected]> > >> > > wrote: > > >> > > > You're right, I didn't say how it _should_ be, just how it probably > >> > > > _is_. > >> > > > But I could be wrong and it's actually a bug. > > >> > > > On 13 Feb., 14:30, andreister <[email protected]> wrote: > >> > > > > Yes, but VerifyAllExpectations should address that some method was > >> > > > > called *more* than expected. > > >> > > > > Otherwise Times(x) should have been called "AtLeast(x)" ! > > >> > > > > On Feb 13, 1:58 pm, ssteinegger <[email protected]> wrote: > > >> > > > > > MockRepository.GenerateMock creates a dynamic mock, which allows > >> > > > > > calls > >> > > > > > that weren't expected. To do this I think you'll need a strict > >> > > > > > mock > >> > > > > > which cannot be created with the static repository. > > >> > > > > > On 13 Feb., 10:43, andreister <[email protected]> wrote: > > >> > > > > > > The previous post "Assert # of times a method was called" > >> > > > > > > brings me > >> > > > to > >> > > > > > > the following scenario > > >> > > > > > > ================================================== > >> > > > > > > [Test] > >> > > > > > > public void Test() > >> > > > > > > { > >> > > > > > > var foo = MockRepository.GenerateMock<IFoo>(); > >> > > > > > > foo.Expect(x => x.Bar()).Repeat.Times(5); > > >> > > > > > > Boo.Run(foo, 4); > > >> > > > > > > foo.VerifyAllExpectations(); > > >> > > > > > > } > > >> > > > > > > public class Boo > >> > > > > > > { > >> > > > > > > public static void Run(IFoo foo, int total) > >> > > > > > > { > >> > > > > > > for (int i = 0; i < total; i++) { foo.Bar(); } > >> > > > > > > } > > >> > > > > > > } > > >> > > > > > > public interface IFoo > >> > > > > > > { > >> > > > > > > void Bar();} > > >> > > > > > > ================================================== > > >> > > > > > > Obviously, it fails with "Expected #5, Actual #4." > > >> > > > > > > However, if we change ".Repeat.Times(5);" to > >> > > > > > > ".Repeat.Times(2);" it > >> > > > > > > passes!!? (I would expect a failure with "Expected #2, Actual > >> > > > > > > #4.") > > >> > > > > > > It looks like "as designed" behavior, since > >> > > > > > > UnorderedMethodRecorder.DoGetRecordedExpectationOrNull ( > >> > > >https://rhino- > > >> > > > > > > tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-mocks/ > >> > > > > > > Rhino.Mocks/MethodRecorders/UnorderedMethodRecorder.cs) relies > >> > > > > > > on > >> > > > > > > "triplet.Expectation.CanAcceptCalls" that is NOT updated for > >> > > > > > > EVERY > >> > > > > > > call... But it's quite confusing. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino.Mocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/RhinoMocks?hl=en -~----------~----~----~----~------~----~------~--~---
