RE: [Nmock-general] RE: NMock

[Jim A. <JA...@th...>]

I'm just jumping in without reading the history of this, but why did you 
have to use expectations for setup code - couldn't you use SetupResult 
instead?

Jim





"Thorne Nigel, Melbourne" <Nig...@an...>
Sent by: nmo...@li...
07/07/2004 06:18
 
        To:     "Owen Rogers" <OR...@th...>
        cc:     <nmo...@li...>
        Subject:        RE: [Nmock-general] RE: NMock


Hi Owen, 
 
I was in a similar state. 
 
I was writing a simple Wiki. 
To test a method on the wiki object I needed the wiki object to be in a 
specific state (ie have a certain page loaded)
The Wiki was talking to a mock PageRepository. 
To initalise the wiki ready for the test I had to tell the wiki to load a 
page, and provide the mock PageRepository with the page to pass back. This 
required me to set up an expectation. 
 
Notice, none of this was actually the focus of the test.
 
In the test I then wanted to perform some action and then call verify to 
see if the PageRepository etc was used correctly. 
 
It would have been nice, once I had the Wiki in the state I required, to 
be able to clear all expectations so that the only expectations being 
tested by the verify method were the ones related to the method under 
test, not the setup code. 
 
I think this is the situation Paul is talking about too. 
Cheers
Nigel

From: nmo...@li... 
[mailto:nmo...@li...] On Behalf Of Owen 
Rogers
Sent: Wednesday, 7 July 2004 1:51 PM
To: Pau...@vi...
Cc: nmo...@li...
Subject: [Nmock-general] RE: NMock
 

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!




Scanned for viruses by MessageLabs


Scanned for viruses by MessageLabs. The integrity and security of this 
message cannot be guaranteed. This email is intended for the named 
recipient only, and may contain confidential information and proprietary 
material. Any unauthorised use or disclosure is prohibited.