Got the failing test, but I would say that this is not a bug, it is a by design feature.DynamicMock sole reason for being is that it accepts unexpected calls. If you want this to work, you need to use StrictMock
On Sun, Feb 22, 2009 at 12:34 PM, Ayende Rahien <[email protected]> wrote: > Can you create a failing test, I didn't follow this thread too closely > > > On Sun, Feb 22, 2009 at 12:01 PM, Shane C <[email protected]>wrote: > >> >> 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 -~----------~----~----~----~------~----~------~--~---
