Had another idea.
Times still makes sense even with a dynamic mock. You aren't only
defining expectation, you also define behaviour. What you actuall say
with "Times(5)" is "the first 5 times it is called". After that, it is
not defined (meaning "return null" for a dynamic mock or "throw and
exception" for a strict mock).
You could do this:
var foo = MockRepository.GenerateMock<IFoo>();
foo.Stub(x => x.Bar()).Repeat.Times(5);
foo.Stub(x => x.Bar()).Throw(new InvalidOperationException
("Gotcha!"));
Boo.Run(foo, 6);
PS: didn't try it, just a guess.
On Feb 23, 4:56 am, Ayende Rahien <[email protected]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
