so the expectation can tell that it is in dynamic mock, and respond appropriately
On Sun, Feb 22, 2009 at 9:24 PM, Shane Courtrille <[email protected] > wrote: > Sorry I'm not sure what you mean "about that" ? > > On Sun, Feb 22, 2009 at 2:33 PM, Ayende Rahien <[email protected]> wrote: > >> You can change the expectation with dynamic mocks, so it would know about >> that. >> >> >> On Sun, Feb 22, 2009 at 3:26 PM, Shane Courtrille < >> [email protected]> wrote: >> >>> That assumes I only call a method once. As soon as I have code that >>> needs to loop over something and do something with each value it breaks >>> down. I can setup my test so that I only have one loop iteration and then >>> make sure that it only occurs once but this still doesn't change the fact >>> that .Times() can lie on DynamicMocks since it's always AtLeast() >>> >>> >>> On Sun, Feb 22, 2009 at 1:16 PM, Ayende Rahien <[email protected]>wrote: >>> >>>> You probably want to go the other way, and assert that it was only >>>> called once, that would be much easier. >>>> >>>> >>>> On Sun, Feb 22, 2009 at 3:14 PM, Shane Courtrille < >>>> [email protected]> wrote: >>>> >>>>> The problem I have with StrictMock is that it seriously breaks the >>>>> "Assert one thing per test" practice. I have to have an expectation for >>>>> every single call that occurs against that interface. As soon as I have >>>>> an >>>>> interface I make different calls on I am out of luck if I want to follow >>>>> this practice. I prefer to break things up by using a dynamic mock. The >>>>> problem is now that I can't also verify that the mock was called the >>>>> number >>>>> of times I expect. >>>>> >>>>> Another problem I have is with consistency of interface. DynamicMocks >>>>> should probably have a seperate interface that only has Repeat.AtLeast() >>>>> instead of Times since you can't actually trust the Times. >>>>> >>>>> >>>>> On Sun, Feb 22, 2009 at 12:27 PM, Ayende Rahien <[email protected]>wrote: >>>>> >>>>>> 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 -~----------~----~----~----~------~----~------~--~---
