[Nmock-general] RE: NMock

[Owen R. <OR...@th...>]

hi paul,
i'm still not sure i understand why you are concerned about repeatedly 
verifying the results of previously called methods.  if the methods were 
either called too many times or not called enough or were called with the 
wrong parameters, then the call to verify would have thrown an exception. 
so you should be able to safely assume that if you make it past the verify 
statement, then everything is a-ok.
but anyway, rather than continue to debate this, i thought i would write 
some code to see if that helped clear things up.  here's what i came up 
with:

        public class ResetableDynamicMock : DynamicMock 
        { 
                public ResetableDynamicMock(Type type) : base(type) {}

                public ResetableDynamicMock(Type type, string name) : base
(type, name) {}

                public ResetableDynamicMock(Type type, string name, Type 
superclassIfTypeIsInterface) : base(type, name, 
superclassIfTypeIsInterface) { }

                public override void Verify()
                {
                        base.Verify();
                        methods.Clear();
                }
        }

NB.  i had to make the "methods" member protected in the Mock base class. 
does this kind of do what you are looking for?  if so, could you try it 
out and let us know if it produces the results that you expect?  if other 
people think that having something like this would be a useful addition to 
nmock, we can always add it.

cheers,
owen.

---
R. Owen Rogers
ThoughtWorks Technologies (India) Pvt Ltd.

ThoughtWorks - Deliver with passion!

ThoughtWorks is always looking for talented people who are passionate 
about technology.  To find out more about a career at ThoughtWorks go to 
http://www.thoughtworks.com/career/.




"Paul Brousseau" <Pau...@vi...>
06/07/2004 21:37
 
        To:     "Owen Rogers" <OR...@th...>
        cc:     <nmo...@li...>
        Subject:        RE: NMock


It's not so much a problem as a possible inconvinience at times.  I think 
my sample below didn't properly set up the situation.  Let's say that I 
have method X that I want to test, but to get to the right state, I have 
to call methods A, B, C, D, and E, each of which result in calls to the 
Mock object.  It would be easier for me to not have to worry about 
counting the various method calls in that setup stage.  If I could wipe 
out my expectations, then I would only have to check the stuff that goes 
along with method X.  So there's nothing wrong with calling Verify 
multiple times, but I'd like not to have to think about verifying the 
results of methods A-E (say, because I've already verified that they work 
elsewhere). 
 
It's ultimately just a matter of convinience.
 
Thanks!
 
 
-----Original Message-----
From: Owen Rogers [mailto:OR...@th...]
Sent: Saturday, July 03, 2004 3:37 AM
To: Paul Brousseau
Cc: nmo...@li...
Subject: Re: NMock


hi paul, 
what sort of problem do you receive from nmock when you try to do this? 
AFAIK, there is nothing stopping you from calling Verify as many times as 
you like.  why is it important to reset the expectations?  is there any 
problem with just accumulating them until the end of the test? 
cheers, 
owen. 


---
R. Owen Rogers
ThoughtWorks Technologies (India) Pvt Ltd.

ThoughtWorks - Deliver with passion!

ThoughtWorks is always looking for talented people who are passionate 
about technology.  To find out more about a career at ThoughtWorks go to 
http://www.thoughtworks.com/career/. 



"Paul Brousseau" <Pau...@vi...> 
03/07/2004 00:03 
        
        To:        <jo...@th...>, <cst...@th...>, 
<or...@th...> 
        cc:         
        Subject:        NMock



Hello!  I'm using NMock for a project, and I need it to do something that 
it doesn't appear to do at the moment.

I would like to be able to set up a dynamic mock and do several tests with 
it in a row, resetting the expectactions each time.  A stripped down 
example:

mockPageView.Expect("ZoomToFullPage");
controller.UndoZoom();
// Do assertions of zoom depth.
mockPageView.Verify();

mockPageView.Expect("ZoomToRectangle");
controller.ZoomToRectangle(new RectangleF(0, 0, 5f, 5f));
// Do assertions of zoom depth.
mockPageView.Verify();

mockPageView.Expect("ZoomToFullPage");
controller.UndoZoom();
// Do assertions of zoom depth.
mockPageView.Verify();

mockPageView.Expect("ZoomToRectangle");
mockPageView.Expect("ZoomToFullPage");
controller.ZoomToRectangle(new RectangleF(0, 0, 5f, 5f));
controller.ZoomToFullPage();
// Do assertions of zoom depth.
mockPageView.Verify();

This would all be in one logical unit test, as I'm interested in verifying 
a certain sequence of events (and related properties), but I want to make 
sure everything is going as planned along the way.  I would like Verify to 
clear the expectactions, OR make an explicit call to clear them.

I didn't see anything like this on the roadmap.  Are there plans?  If not, 
does this seem like the kind of thing that a reasonably clever engineer 
(myself) could hack up in day, without having previous expirience with the 
source?  And if so, would you accept a contribution back?

Thanks!