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 -~----------~----~----~----~------~----~------~--~---
