nmock-general

Re: [Nmock-general] ExpectAndReturn too strict

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

hi nick,
this is where constraints come in.  constraints allow you to set up fuzzy 
validation on the parameters that are passed into and verified by the 
mock. 

for example, if you really don't card about what gets passed to 
DoSomething, you could use:
- interfaceMock.ExpectAndReturn("DoSomething", true, new IsAnything());

if you want to verify it is at least instantiated, you could use:
- interfaceMock.ExpectAndReturn("DoSomething", true, new NotNull());

or you could verify the type of someObject with:
- interfaceMock.ExpectAndReturn("DoSomething", true, new IsTypeOf());

if you really want to verify that SomeObject is passed and instantiated 
correctly, you could override the Equals() method on someObject and then 
write something like this:
Test
{
        SomeObject expectedSomeObject = new SomeObject(the same params 
that are used in the object under test);
        interfaceMock.ExpectAndReturn("DoSomething", true, 
expectedSomeObject);
}

if you want to be explicit using constraints, you could use this instead:
        interfaceMock.ExpectAndReturn("DoSomething", true, 
IsEqual(expectedSomeObject));

check out the other constraints in the constraints namespace for more 
examples.
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/.




"Nick Robinson" <nic...@fr...>
Sent by: nmo...@li...
27/07/2004 03:39
 
        To:     <nmo...@li...>
        cc:     (bcc: Owen Rogers/Canada/ThoughtWorks)
        Subject:        [Nmock-general] ExpectAndReturn too strict


I have a situation, where I want to return a value from a method call of 
an
interface, but between the outer object and the interface, a creation 
occurs
which I am not aware of which is passed into the interface:

outer object.Dosomething(some params)
{
                 SomeObject someObject = new SomeObject(some of the 
params);
                 if(_interface.DoSomething(someObject))
                 {
                                 ...
                 }
}

I want _interface to return false, but I obviously dont have access to the
someObject instance in my test:

Test
{
                 interfaceMock.ExpectAndReturn("DoSomething", true, ???);
}

I seem to have the option of introducing an interfaced factory or a stub
that replaces the mock.  Do people just ignore this by creating one of 
these
items and moving on, or do you have a different technique to get around 
this
situation?

Cheers,

nick.robinson
site  : www.fromconcept.co.uk
blog  : www.fromconcept.co.uk/weblog.aspx
draco : www.sourceforge.net/projects/draconet





-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Nmock-general mailing list
Nmo...@li...
https://lists.sourceforge.net/lists/listinfo/nmock-general

[Nmock-general] ExpectAndReturn too strict

[Nick R. <nic...@fr...>]

I have a situation, where I want to return a value from a method call of an
interface, but between the outer object and the interface, a creation occurs
which I am not aware of which is passed into the interface:

outer object.Dosomething(some params)
{
	SomeObject someObject = new SomeObject(some of the params);
	if(_interface.DoSomething(someObject))
	{
		...
	}
}

I want _interface to return false, but I obviously dont have access to the
someObject instance in my test:

Test
{
	interfaceMock.ExpectAndReturn("DoSomething", true, ???);
}

I seem to have the option of introducing an interfaced factory or a stub
that replaces the mock.  Do people just ignore this by creating one of these
items and moving on, or do you have a different technique to get around this
situation?

Cheers,

nick.robinson
site  : www.fromconcept.co.uk
blog  : www.fromconcept.co.uk/weblog.aspx
draco : www.sourceforge.net/projects/draconet

RE: [Nmock-general] Value Types

[Nick R. <nic...@fr...>]

Ignore this question.  Either I have a machine problem, or SourceForge is
playng up, but only version 1.0 was being shown to me.  Now I can see 1.1,
but still cannot download due to timeouts.

nick.robinson
site  : www.fromconcept.co.uk
blog  : www.fromconcept.co.uk/weblog.aspx
draco : www.sourceforge.net/projects/draconet

> -----Original Message-----
> From: nmo...@li...
> [mailto:nmo...@li...]On Behalf Of Nick
> Robinson
> Sent: 22 July 2004 18:55
> To: nmo...@li...
> Subject: [Nmock-general] Value Types
> 
> 
> Hi,
> 
> Could someone confirm Value Types have been fixed, and if so, where I can
> get the fix? I have the version available for download from sourcforge
> (Jan/2004) and value types arent working.
> 
> Thanks.
> 
> nick.robinson
> site  : www.fromconcept.co.uk
> blog  : www.fromconcept.co.uk/weblog.aspx
> draco : www.sourceforge.net/projects/draconet
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Nmock-general mailing list
> Nmo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-general

[Nmock-general] Value Types

[Nick R. <nic...@fr...>]

Hi,

Could someone confirm Value Types have been fixed, and if so, where I can
get the fix? I have the version available for download from sourcforge
(Jan/2004) and value types arent working.

Thanks.

nick.robinson
site  : www.fromconcept.co.uk
blog  : www.fromconcept.co.uk/weblog.aspx
draco : www.sourceforge.net/projects/draconet

Re: [Nmock-general] RE: NMock

[Steve F. <st...@m3...>]

There already is a mechanism to support this. Mocks as implemented have 
two functions, to check expectations and to stub return behaviour. What 
you're describing here is a stub which, if I remember correctly, is set 
up with SetupAndReturn() -- or something like that. The Setup methods 
will respond if asked, but are not included in the Verify().

There was a bug on the implementation for a while, but I hope that's 
fixed by now.

S

Thorne Nigel, Melbourne wrote:
> 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. 

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.

RE: [Nmock-general] RE: NMock

[Thorne N. M. <Nig...@an...>]

Hi=20Owen,=20

=20

I=20was=20in=20a=20similar=20state.=20

=20

I=20was=20writing=20a=20simple=20Wiki.=20

To=20test=20a=20method=20on=20the=20wiki=20object=20I=20needed=20the=20wik=
i=20object=20to=20be=20in=20a
specific=20state=20(ie=20have=20a=20certain=20page=20loaded)

The=20Wiki=20was=20talking=20to=20a=20mock=20PageRepository.=20

To=20initalise=20the=20wiki=20ready=20for=20the=20test=20I=20had=20to=20te=
ll=20the=20wiki=20to=20load
a=20page,=20and=20provide=20the=20mock=20PageRepository=20with=20the=20pag=
e=20to=20pass=20back.
This=20required=20me=20to=20set=20up=20an=20expectation.=20

=20

Notice,=20none=20of=20this=20was=20actually=20the=20focus=20of=20the=20tes=
t.

=20

In=20the=20test=20I=20then=20wanted=20to=20perform=20some=20action=20and=20=
then=20call=20verify=20to
see=20if=20the=20PageRepository=20etc=20was=20used=20correctly.=20

=20

It=20would=20have=20been=20nice,=20once=20I=20had=20the=20Wiki=20in=20the=20=
state=20I=20required,=20to
be=20able=20to=20clear=20all=20expectations=20so=20that=20the=20only=20exp=
ectations=20being
tested=20by=20the=20verify=20method=20were=20the=20ones=20related=20to=20t=
he=20method=20under
test,=20not=20the=20setup=20code.=20

=20

I=20think=20this=20is=20the=20situation=20Paul=20is=20talking=20about=20to=
o.=20

Cheers

Nigel

________________________________

From:=20n...@li...
[mailto:nmo...@li...]=20On=20Behalf=20Of=20Ow=
en
Rogers
Sent:=20Wednesday,=207=20July=202004=201:51=20PM
To:=20P...@vi...
Cc:=20n...@li...
Subject:=20[Nmock-general]=20RE:=20NMock

=20


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

=20=20=20=20=20=20=20=20public=20class=20ResetableDynamicMock=20:=20Dynami=
cMock=20
=20=20=20=20=20=20=20=20{=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=

=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20public=20ResetableDynamicM=
ock(Type=20type)=20:=20base(type)=20{}=20

=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20public=20ResetableDynamicM=
ock(Type=20type,=20string=20name)=20:
base(type,=20name)=20{}=20

=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20public=20ResetableDynamicM=
ock(Type=20type,=20string=20name,=20Type
superclassIfTypeIsInterface)=20:=20base(type,=20name,
superclassIfTypeIsInterface)=20{=20}=20

=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20public=20override=20void=20=
Verify()=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20{=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20ba=
se.Verify();=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20me=
thods.Clear();=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20}=20
=20=20=20=20=20=20=20=20}=20

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

cheers,=20
owen.

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

ThoughtWorks=20-=20Deliver=20with=20passion!

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



=20

"Paul=20Brousseau"=20<Pau...@vi...>=20

06/07/2004=2021:37=20

=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20To:=20=20=20=20=20=20=20=20"Owen=20Rogers"=20<ORog=
er...@th...>=20
=20=20=20=20=20=20=20=20cc:=20=20=20=20=20=20=20=20<nmo...@li...=
urceforge.net>=20
=20=20=20=20=20=20=20=20Subject:=20=20=20=20=20=20=20=20RE:=20NMock




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


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


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

ThoughtWorks=20-=20Deliver=20with=20passion!

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

=20

"Paul=20Brousseau"=20<Pau...@vi...>=20

03/07/2004=2000:03=20

=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20To:=20=20=20=20=20=20=20=20<jo...@th...>,
<cst...@th...>,=20<or...@th...>=20
=20=20=20=20=20=20=20cc:=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20Subject:=20=20=20=20=20=20=20=20NMock





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

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

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

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

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

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

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

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

Thanks!




Scanned=20for=20viruses=20by=20MessageLabs



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

[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!

RE: [Nmock-general] RE: NMock

[Paul B. <Pau...@vi...>]

Not entirely sure what you mean, but methods A-E are on the object I =
want to test, so I can't replace them.  And it's not that I want to set =
expectations for methods A-E, it's that they generate calls to my Mock =
object, which I have to account for when I verify method X later.

Example:

DynamicMock m =3D new DynamicMock(typeof(IMyInterface));
IMyInterface itf =3D (IMyInterface)m.MockInstance;

MyInterestingObject foo =3D new MyInterestingObject(itf);

// Set up for the real test.
foo.A();  // calls itf.helper();
foo.B();  // calls itf.helper();
foo.C();  // calls itf.helper();
foo.D();  // calls itf.helper();
foo.E();  // calls itf.helper();

// I'd like to clear all the expectation counters built up on itf at =
this point.

m.Expect("xHelper");
foo.X();  // calls itf.helper();
m.Verify();

If the helper counter isn't cleared, I'm expecting 1 call, and the mock =
knows of 6, which results in a test failure.  Obviously, in this case, =
it would be easy to handle this sample case, but as my tests get more =
and more complicated, it gets harder and harder.  As I mentioned, what =
I'm looking for is more of a convinence than anything else.  Thanks!  :)



-----Original Message-----
From: Steve Freeman [mailto:st...@m3...]
Sent: Tuesday, July 06, 2004 2:53 PM
To: Paul Brousseau
Cc: Owen Rogers; nmo...@li...
Subject: Re: [Nmock-general] RE: NMock


Could you stub methods A..E, rather than setting expectations on them?

S

Paul Brousseau wrote:
> 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).
>=20

Re: [Nmock-general] RE: NMock

[Steve F. <st...@m3...>]

Could you stub methods A..E, rather than setting expectations on them?

S

Paul Brousseau wrote:
> 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).
> 

[Nmock-general] RE: NMock

[Paul B. <Pau...@vi...>]

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). =20
=20
It's ultimately just a matter of convinience.
=20
Thanks!
=20
=20

-----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,=20
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?=20
cheers,=20
owen.=20


---
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/.=20



	"Paul Brousseau" <Pau...@vi...>=20


03/07/2004 00:03=20

       =20
        To:        <jo...@th...>, =
<cst...@th...>, <or...@th...>=20
        cc:        =20
        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!

Re: [Nmock-general] What shall we do for the next version

[David A. <dta...@co...>]

On further thought, it is possible to construct an adapter class to use this
imaginary NMock2 in the NMock1 style.

Just get on with the new version and not care about the consequences.

----- Original Message ----- 
From: "David Andersen" <dta...@co...>
To: <nmo...@li...>
Sent: Monday, July 05, 2004 10:50 AM
Subject: Re: [Nmock-general] What shall we do for the next version


> I REALLY like the mockObject.ExpectAndReturn("Method", value, "arg")
syntax.
> I hope that isn't going to be replaced with
>
mockObject.Expects(once()).Method("Method").With(eq("arg")).Will(returnValue
> (value)).  In my opinion jMock should change to be like NMock!
>
> ----- Original Message ----- 
> From: "Steve Freeman" <st...@m3...>
> To: <nmo...@li...>
> Sent: Friday, July 02, 2004 2:42 PM
> Subject: [Nmock-general] What shall we do for the next version
>
>
> > Here in NMock Castle, we're thinking about the next major version of
> > NMock. We intend to release a version based on our experience with jMock
> >   (http://www.jmock.org), which is a much cleaner structure but is a
> > significant change of API.
> >
> > The main issue at this point is how to manage the transition, in
> > particular the choice of namespace since NMock is taken with the current
> > library. There are some possibilities:
> >
> > - Package the current version in a strongly named assembly. Then the
> > version of NMock could be changed with each VS project, but all of a
> > project would have to be converted at once.
> >
> > - Call the new one NMock2. Personally I have problems with this because:
> >   I can't stand the cruft on the name especially when I believe the new
> > version represents the long-term approach; and, every time we up the
> > counter on the API, people will have to fix their tests even if there's
> > no other change.
> >
> > - Move the old one to NMock0, and have the current version as NMock. Old
> > code could be retrofitted with a 'using NMock0 as NMock' clause. In
> > theory, this could be extended indefinately using numbered versions for
> > deprecation.
> >
> > - Just get on with the new version and not care about the consequences.
> >
> > What's best for people. My only caveat is that I'd like to avoid the old
> > 'make' problem, where the confusion between tab and space was
> > perpetuated because they didn't want to annoy their (12) users at the
> > time...
> >
> > S.
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Nmock-general mailing list
> > Nmo...@li...
> > https://lists.sourceforge.net/lists/listinfo/nmock-general
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Nmock-general mailing list
> Nmo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-general
>

Re: [Nmock-general] What shall we do for the next version

[David A. <dta...@co...>]

I REALLY like the mockObject.ExpectAndReturn("Method", value, "arg") syntax.
I hope that isn't going to be replaced with
mockObject.Expects(once()).Method("Method").With(eq("arg")).Will(returnValue
(value)).  In my opinion jMock should change to be like NMock!

----- Original Message ----- 
From: "Steve Freeman" <st...@m3...>
To: <nmo...@li...>
Sent: Friday, July 02, 2004 2:42 PM
Subject: [Nmock-general] What shall we do for the next version


> Here in NMock Castle, we're thinking about the next major version of
> NMock. We intend to release a version based on our experience with jMock
>   (http://www.jmock.org), which is a much cleaner structure but is a
> significant change of API.
>
> The main issue at this point is how to manage the transition, in
> particular the choice of namespace since NMock is taken with the current
> library. There are some possibilities:
>
> - Package the current version in a strongly named assembly. Then the
> version of NMock could be changed with each VS project, but all of a
> project would have to be converted at once.
>
> - Call the new one NMock2. Personally I have problems with this because:
>   I can't stand the cruft on the name especially when I believe the new
> version represents the long-term approach; and, every time we up the
> counter on the API, people will have to fix their tests even if there's
> no other change.
>
> - Move the old one to NMock0, and have the current version as NMock. Old
> code could be retrofitted with a 'using NMock0 as NMock' clause. In
> theory, this could be extended indefinately using numbered versions for
> deprecation.
>
> - Just get on with the new version and not care about the consequences.
>
> What's best for people. My only caveat is that I'd like to avoid the old
> 'make' problem, where the confusion between tab and space was
> perpetuated because they didn't want to annoy their (12) users at the
> time...
>
> S.
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Nmock-general mailing list
> Nmo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-general
>

Re: [Nmock-general] What shall we do for the next version

[Jeff C S. <JSa...@th...>]

If one wishes to use an existing namespace isn't there an obligation to
maintain compatibility with the current namespace API at least long enough
to give users a migration path?

If the goal of the app is to server the users then it seems the options are
to maintain compatibility for at least awhile to give users an easy
migration path, or use a different namespace (which could be something more
original than NMock2).

Jeff



                                                                           
             Steve Freeman                                                 
             <st...@m3...>                                             
             Sent by:                                                   To 
             nmock-general-adm                                             
             in...@li...         nmo...@li... 
             rge.net                                                    cc 
                                                                           
                                                                           
             02/07/2004 22:42                                              
                                                                           
                                                                           
                                                                   Subject 
                                       [Nmock-general] What shall we do    
                                       for the next version                
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Here in NMock Castle, we're thinking about the next major version of
NMock. We intend to release a version based on our experience with jMock
  (http://www.jmock.org), which is a much cleaner structure but is a
significant change of API.

The main issue at this point is how to manage the transition, in
particular the choice of namespace since NMock is taken with the current
library. There are some possibilities:

- Package the current version in a strongly named assembly. Then the
version of NMock could be changed with each VS project, but all of a
project would have to be converted at once.

- Call the new one NMock2. Personally I have problems with this because:
  I can't stand the cruft on the name especially when I believe the new
version represents the long-term approach; and, every time we up the
counter on the API, people will have to fix their tests even if there's
no other change.

- Move the old one to NMock0, and have the current version as NMock. Old
code could be retrofitted with a 'using NMock0 as NMock' clause. In
theory, this could be extended indefinately using numbered versions for
deprecation.

- Just get on with the new version and not care about the consequences.

What's best for people. My only caveat is that I'd like to avoid the old
'make' problem, where the confusion between tab and space was
perpetuated because they didn't want to annoy their (12) users at the
time...

S.


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Nmock-general mailing list
Nmo...@li...
https://lists.sourceforge.net/lists/listinfo/nmock-general

Re: [Nmock-general] What shall we do for the next version

[Joe W. <jo...@tr...>]

I'm okay with breaking backwards compatability, *so long* as we do it in 
a way that allows the old api and new api to be used in parallel. This 
means allowing one test at a time to be migrated and for users to 'test 
the water' with the new API, before committing to changing their 
existing code.

This rules options 1, 3 and 4 out totally for me, leaving the only 
option as calling the new package NMock2 (or something else new), which 
I have no issue with.

Another option to add:

5) We add some methods to the new Mock class that give the API the same 
methods as those in the original library, which merely act as adaptors 
to the new API and are marked as obsolete. This allows the new library 
to be dropped in as a replacement to the old one, providing new 
capabilities to the Mock class, whilst allowing old code to still work.

Not sure how feasible this is and it would definetely require more effort.

class NMock.Mock:

    [Obsolete("Use Expects() instead")]
    public void Expect(string methodname, param object[] args)
    {
         Expects(Once()).Method(methodname).With(args);
    }


My vote is definetely for option 2. I think just calling the new library 
NMock2 and allowing users to use whichever they want (or both) will make 
life simpler for all.

-joe

Steve Freeman wrote:

> Here in NMock Castle, we're thinking about the next major version of 
> NMock. We intend to release a version based on our experience with 
> jMock  (http://www.jmock.org), which is a much cleaner structure but 
> is a significant change of API.
>
> The main issue at this point is how to manage the transition, in 
> particular the choice of namespace since NMock is taken with the 
> current library. There are some possibilities:
>
> 1) Package the current version in a strongly named assembly. Then the 
> version of NMock could be changed with each VS project, but all of a 
> project would have to be converted at once.
>
> 2) Call the new one NMock2. Personally I have problems with this 
> because:  I can't stand the cruft on the name especially when I 
> believe the new version represents the long-term approach; and, every 
> time we up the counter on the API, people will have to fix their tests 
> even if there's no other change.
>
> 3) Move the old one to NMock0, and have the current version as NMock. 
> Old code could be retrofitted with a 'using NMock0 as NMock' clause. 
> In theory, this could be extended indefinately using numbered versions 
> for deprecation.
>
> 4) Just get on with the new version and not care about the consequences.
>
> What's best for people. My only caveat is that I'd like to avoid the 
> old 'make' problem, where the confusion between tab and space was 
> perpetuated because they didn't want to annoy their (12) users at the 
> time...
>
> S.
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Nmock-general mailing list
> Nmo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-general
>

[Nmock-general] Re: NMock

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

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!

Re: [Nmock-general] What shall we do for the next version

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

hi steve,
contrary to what i said before, i agree that using a NMock2 
namespace/assembly is not such a great idea.  that said, my main 
considerations are:
1) i would like to be able to migrate to the new apis gradually
2) i would like to be able to continue to support and enhance the existing 
api

of the four options, i prefer option number 4.  maybe we are worrying 
unnecessarily about the scope of the changes required by introducing the 
jMock-style apis.  presumably, we will still continue to use the majority 
of the IL generation code.  it is only the Method/Constraint classes that 
will be affected??  are there any strenuous objects to the jMock-style api 
classes and the original NMock classes living side-by-side in the same 
folder?

however, if this is too hard, we could do a complete branch and set up a 
new CVS module and build the new code into a separate assembly.  the new 
code could live in the NMock namespace -- namespace conflicts are only a 
problem if the new code uses classes that have the same name as the ones 
in the old assembly, and as the new jmock-style classes don't have a 
DynamicMock class (AFAIK) then conflicts should be minimised -- it will 
probably only be with the Constraint classes.

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/.




Steve Freeman <st...@m3...>
Sent by: nmo...@li...
03/07/2004 03:12
 
        To:     nmo...@li...
        cc: 
        Subject:        [Nmock-general] What shall we do for the next 
version


Here in NMock Castle, we're thinking about the next major version of 
NMock. We intend to release a version based on our experience with jMock 
  (http://www.jmock.org), which is a much cleaner structure but is a 
significant change of API.

The main issue at this point is how to manage the transition, in 
particular the choice of namespace since NMock is taken with the current 
library. There are some possibilities:

- Package the current version in a strongly named assembly. Then the 
version of NMock could be changed with each VS project, but all of a 
project would have to be converted at once.

- Call the new one NMock2. Personally I have problems with this because: 
  I can't stand the cruft on the name especially when I believe the new 
version represents the long-term approach; and, every time we up the 
counter on the API, people will have to fix their tests even if there's 
no other change.

- Move the old one to NMock0, and have the current version as NMock. Old 
code could be retrofitted with a 'using NMock0 as NMock' clause. In 
theory, this could be extended indefinately using numbered versions for 
deprecation.

- Just get on with the new version and not care about the consequences.

What's best for people. My only caveat is that I'd like to avoid the old 
'make' problem, where the confusion between tab and space was 
perpetuated because they didn't want to annoy their (12) users at the 
time...

S.


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Nmock-general mailing list
Nmo...@li...
https://lists.sourceforge.net/lists/listinfo/nmock-general

[Nmock-general] What shall we do for the next version

[Steve F. <st...@m3...>]

Here in NMock Castle, we're thinking about the next major version of 
NMock. We intend to release a version based on our experience with jMock 
  (http://www.jmock.org), which is a much cleaner structure but is a 
significant change of API.

The main issue at this point is how to manage the transition, in 
particular the choice of namespace since NMock is taken with the current 
library. There are some possibilities:

- Package the current version in a strongly named assembly. Then the 
version of NMock could be changed with each VS project, but all of a 
project would have to be converted at once.

- Call the new one NMock2. Personally I have problems with this because: 
  I can't stand the cruft on the name especially when I believe the new 
version represents the long-term approach; and, every time we up the 
counter on the API, people will have to fix their tests even if there's 
no other change.

- Move the old one to NMock0, and have the current version as NMock. Old 
code could be retrofitted with a 'using NMock0 as NMock' clause. In 
theory, this could be extended indefinately using numbered versions for 
deprecation.

- Just get on with the new version and not care about the consequences.

What's best for people. My only caveat is that I'd like to avoid the old 
'make' problem, where the confusion between tab and space was 
perpetuated because they didn't want to annoy their (12) users at the 
time...

S.

[Nmock-general] website index.html,1.4,1.5

[Colin K. <col...@us...>]

Update of /cvsroot/nmock/website
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv5355

Modified Files:
	index.html 
Log Message:
- Minor formatting of the code sample (indentation).

Index: index.html
===================================================================
RCS file: /cvsroot/nmock/website/index.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** index.html	24 Jun 2004 06:36:38 -0000	1.4
--- index.html	24 Jun 2004 06:50:22 -0000	1.5
***************
*** 48,1280 ****
  </style>
  
! <p>NMock is a dynamic mock-object library for .NET. Its purpose is to provide a clean API for rapidly creating mock
! implementations of custom objects and verifying that objects interact with them correctly from unit tests.</p>
  
! <p>A mock:</p>
  
! <ul>
! <li>takes on the interface of another object, allowing it to be substituted for a real one for testing
! purposes.</li>
[...2171 lines suppressed...]
!     <p>The power of constraints is that you can flexibly specify your expectations <i>before</i> your code under test runs, allowing fail fast.</p>
  
!     <p>You can easily create custom constraints by implementing the IConstraint interface, or passing a delegate into the Constraint class.</p>
  
!     <h1>Tips</h1>
  
!     <p><span style="font-weight: bold;">Syntactic sugar</span>: Because 90% of the time, the two constraints you use are IsEqual() and IsAnything(), these can be replaced with object and null arguments respectively. The above example can be shortened to mock.Expect("Eat", "cheese", null, null).</p>
  
!     <p><span style="font-weight: bold;">Test layout</span>: Tests that use mocks are easier to read if they follow a standard layout. We break the test into four parts: "Setup" initializes any objects/mocks and puts them into the correct state before a test. "Expectations" specifies what you expect to happen - this is the actual 'test' bit. "Execute" runs the code under test - this is where you'd typically get a failure. "Verify" performs any post-execution checks including verifying all the mocks expectations have been met and any additional assertions.</p>
  
!     <p><span style="font-weight: bold;">Externalize dependencies</span>: Inversion of Control (AKA Dependency Inversion Principle, Dependency Injector Pattern). Passing dependencies in from the outside decouples class under test from a particular implementation of the dependency (a good practice in general), making it easier to mock.</p>
  
!     <p><span style="font-weight: bold;">Return values</span>: If the method being mocked returns a value or throws an exception, you can use ExpectAndReturn() or ExpectAndThrow() to specify what the mock should return. You can also use SetupResult() which does not associate an expectation and doesn't care how many times the method is called.</p>
  
!     <p><span style="font-weight: bold;">Mocking classes</span>: NMock supports mocking of classes with virtual methods as well as interfaces. The merits of when to mock classes and interfaces is a religious debate. However, use of interfaces is highly recommended.</p>
  
!     <p><span style="font-weight: bold;">Don't mock things you don't own</span>: It's awkward and painful trying to mock someone else's API (such as ADO.NET), leading to hard to read tests and assumptions about how the API works. On the other hand, mocking your own APIs leads you down the path of creating cleaner interfaces, which can never hurt. If dealing with external APIs, create your own clean abstraction suited for your purposes, which you can mock easily. For testing the abstraction itself, don't use mocks, use the real thing. This is the opposite of the usage commonly associated with using mocks, which usually leads to brittle and cumbersome tests.</p>
! 
!     <p><span style="font-weight: bold;">PropertyConstraint</span>: Allows you to setup constraints on properties of objects.</p>
  

[Nmock-general] website index.html,1.3,1.4

[Colin K. <col...@us...>]

Update of /cvsroot/nmock/website
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2994

Modified Files:
	index.html 
Log Message:
- Modfied to include a formatted version of Joe's email docs for NMock.

Index: index.html
===================================================================
RCS file: /cvsroot/nmock/website/index.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** index.html	24 Jun 2004 05:03:29 -0000	1.3
--- index.html	24 Jun 2004 06:36:38 -0000	1.4
***************
*** 1,4 ****
! <p>NMock is a dynamic mock-object library for .NET. Its purpose is to
! provide a clean API for rapidly creating mock implementations of custom
! objects and verifying that objects interact with them correctly from
! unit tests.</p>
\ No newline at end of file
--- 1,1280 ----
! <style type="text/css">
! <!--
! .syntax0 {
! color: #000000;
[...1256 lines suppressed...]
! Principle, Dependency Injector Pattern). Passing dependencies in from the outside decouples class under test from a
! particular implementation of the dependency (a good practice in general), making it easier to mock.</p>
! 
! <p><span style="font-weight: bold;">Return values</span>: If the method being mocked returns a value or throws an
! exception, you can use ExpectAndReturn() or ExpectAndThrow() to specify what the mock should return. You can also
! use SetupResult() which does not associate an expectation and doesn't care how many times the method is called.</p>
! 
! <p><span style="font-weight: bold;">Mocking classes</span>: NMock supports mocking of classes with virtual methods
! as well as interfaces. The merits of when to mock classes and interfaces is a religious debate. However, use of
! interfaces is highly recommended.</p>
! 
! <p><span style="font-weight: bold;">Don't mock things you don't own</span>: It's awkward and painful trying to mock
! someone else's API (such as ADO.NET), leading to hard to read tests and assumptions about how the API works. On the
! other hand, mocking your own APIs leads you down the path of creating cleaner interfaces, which can never hurt. If
! dealing with external APIs, create your own clean abstraction suited for your purposes, which you can mock easily.
! For testing the abstraction itself, don't use mocks, use the real thing. This is the opposite of the usage commonly
! associated with using mocks, which usually leads to brittle and cumbersome tests.</p>
! 
! <p><span style="font-weight: bold;">PropertyConstraint</span>: Allows you to setup constraints on properties of
! objects.</p>

[Nmock-general] website index.html,1.2,1.3

[Colin K. <col...@us...>]

Update of /cvsroot/nmock/website
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20519

Modified Files:
	index.html 
Log Message:
- Modified text to include more of a description of what NMock is.

Index: index.html
===================================================================
RCS file: /cvsroot/nmock/website/index.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** index.html	10 Nov 2002 14:07:28 -0000	1.2
--- index.html	24 Jun 2004 05:03:29 -0000	1.3
***************
*** 1 ****
! <p>NMock is a dynamic mock-object library for .NET</p>
--- 1,4 ----
! <p>NMock is a dynamic mock-object library for .NET. Its purpose is to
! provide a clean API for rapidly creating mock implementations of custom
! objects and verifying that objects interact with them correctly from
! unit tests.</p>
\ No newline at end of file

[Nmock-general] nmock/test test.csproj,1.9,1.10

[Owen R. <exo...@us...>]

Update of /cvsroot/nmock/nmock/test
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3533/test

Modified Files:
	test.csproj 
Log Message:
committing jim's new fixes for increasing performance and reducing memory requirements

Index: test.csproj
===================================================================
RCS file: /cvsroot/nmock/nmock/test/test.csproj,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** test.csproj	17 Jun 2004 05:13:38 -0000	1.9
--- test.csproj	23 Jun 2004 04:44:53 -0000	1.10
***************
*** 140,143 ****
--- 140,153 ----
                  />
                  <File
+                     RelPath = "NMock\Dynamic\InterfaceListerTest.cs"
+                     SubType = "Code"
+                     BuildAction = "Compile"
+                 />
+                 <File
+                     RelPath = "NMock\Dynamic\MockTypeIdentifierTest.cs"
+                     SubType = "Code"
+                     BuildAction = "Compile"
+                 />
+                 <File
                      RelPath = "NMock\Remoting\MockServerTest.cs"
                      SubType = "Code"

[Nmock-general] nmock/test/NMock/Dynamic MockTypeIdentifierTest.cs,NONE,1.1 ClassGeneratorTest.cs,1.16,1.17

[Owen R. <exo...@us...>]

Update of /cvsroot/nmock/nmock/test/NMock/Dynamic
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3533/test/NMock/Dynamic

Modified Files:
	ClassGeneratorTest.cs 
Added Files:
	MockTypeIdentifierTest.cs 
Log Message:
committing jim's new fixes for increasing performance and reducing memory requirements

Index: ClassGeneratorTest.cs
===================================================================
RCS file: /cvsroot/nmock/nmock/test/NMock/Dynamic/ClassGeneratorTest.cs,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** ClassGeneratorTest.cs	21 Aug 2003 00:26:16 -0000	1.16
--- ClassGeneratorTest.cs	23 Jun 2004 04:44:53 -0000	1.17
***************
*** 1,4 ****
--- 1,5 ----
  using System;
  using System.Collections;
+ using System.Reflection;
  using System.Reflection.Emit;
  
***************
*** 404,407 ****
--- 405,446 ----
  			Assertion.Assert("Should include InternalMethod", methodsToIgnore.Contains("InternalMethod"));
  		}
+ 				
+ 		[Test] public void OnlyOneAssemblyIsCreated()
+ 		{
+ 			cg = new ClassGenerator(typeof(IThingy), mock);
+ 			cg.Generate();
+ 
+ 			int originalAssemblyCount = AppDomain.CurrentDomain.GetAssemblies().Length;
+ 
+ 			cg = new ClassGenerator(typeof(ConcreteThing), mock);
+ 			cg.Generate();
+ 
+ 			Assert.AreEqual(originalAssemblyCount, AppDomain.CurrentDomain.GetAssemblies().Length);
+ 		}
+ 
+ 		[Test] public void MockTypesAreReused()
+ 		{
+ 			cg = new ClassGenerator(typeof(Exception), mock);
+ 			cg.Generate();
+ 
+ 			Assembly mockAssembly = null;
+ 
+ 			foreach(Assembly ass in AppDomain.CurrentDomain.GetAssemblies())
+ 			{
+ 				if(ass.GetName().Name == "DynamicProxyAssembly")
+ 				{
+ 					mockAssembly = ass;
+ 				}
+ 			}
+ 
+ 			Assert.IsNotNull(mockAssembly);
+ 
+ 			int originalTypeCount = mockAssembly.GetTypes().Length;
+ 
+ 			cg = new ClassGenerator(typeof(Exception), mock);
+ 			cg.Generate();
+ 
+ 			Assert.AreEqual(originalTypeCount, mockAssembly.GetTypes().Length);
+ 		}
  	}
  }

--- NEW FILE: MockTypeIdentifierTest.cs ---
using System;
using System.Collections;
using NMock.Dynamic;
using NUnit.Framework;

namespace NMock.NMock.Dynamic
{
	[TestFixture]
	public class MockTypeIdentifierTest
	{
		IList someMethodsToIgnore;
		IList someOtherMethodsToIgnore;
		Type typeToMock;
		Type anotherTypeToMock;

		[SetUp]
		public void SetUp()
		{
			typeToMock = typeof(ConcreteThing);
			anotherTypeToMock = typeof(AbstractThingy);

			someMethodsToIgnore = new ArrayList();
			someMethodsToIgnore.Add("Eat");
			someMethodsToIgnore.Add("Drink");

			someOtherMethodsToIgnore = new ArrayList();
			someOtherMethodsToIgnore.Add("Barf");
		}

		[Test]
		public void TwoEqualMockTypesWithSameIgnoredMethodsAreEqual()
		{
			MockTypeIdentifier id1 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);
			MockTypeIdentifier id2 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);

			Assert.IsTrue(id1.Equals(id2));
		}

		[Test]
		public void TwoEqualMockTypesWithDifferentIgnoredMethodsAreNotEqual()
		{
			MockTypeIdentifier id1 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);
			MockTypeIdentifier id2 = new MockTypeIdentifier(typeToMock, someOtherMethodsToIgnore);

			Assert.IsFalse(id1.Equals(id2));
		}

		[Test]
		public void TwoUnequalMockTypesAreNotEqual()
		{
			MockTypeIdentifier id1 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);
			MockTypeIdentifier id2 = new MockTypeIdentifier(anotherTypeToMock, someMethodsToIgnore);

			Assert.IsFalse(id1.Equals(id2));
		}

		[Test]
		public void ComparisonsToSelfIndicateEqualityOhMyGodISoundLikePaulHammant()
		{
			MockTypeIdentifier id1 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);
	
			Assert.IsTrue(id1.Equals(id1));
		}

		[Test]
		public void ImplementsGetHashCodeProperly()
		{
			MockTypeIdentifier id1 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);
			MockTypeIdentifier id2 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);

			Assert.AreEqual(id1.GetHashCode(), id2.GetHashCode());
		}

		[Test]
		public void IgnoredMethodsAreCopied()
		{
			MockTypeIdentifier id1 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);

			someMethodsToIgnore.Add("SomeOtherMethod");

			MockTypeIdentifier id2 = new MockTypeIdentifier(typeToMock, someMethodsToIgnore);

			Assert.IsFalse(id1.Equals(id2));
		}
	}
}

[Nmock-general] nmock/src/NMock/Dynamic BoxingOpCodes.cs,NONE,1.1 MockTypeIdentifier.cs,NONE,1.1 ClassGenerator.cs,1.21,1.22

[Owen R. <exo...@us...>]

Update of /cvsroot/nmock/nmock/src/NMock/Dynamic
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3533/src/NMock/Dynamic

Modified Files:
	ClassGenerator.cs 
Added Files:
	BoxingOpCodes.cs MockTypeIdentifier.cs 
Log Message:
committing jim's new fixes for increasing performance and reducing memory requirements

--- NEW FILE: MockTypeIdentifier.cs ---
using System;
using System.Collections;

namespace NMock.Dynamic
{
	public class MockTypeIdentifier
	{
		Type typeToMock;
		IList methodsToIgnore;

		public MockTypeIdentifier(Type typeToMock, IList methodsToIgnore)
		{
			this.typeToMock = typeToMock;
			this.methodsToIgnore = new ArrayList();

			for(int i = 0; i < methodsToIgnore.Count; i++)
			{
				this.methodsToIgnore.Add(methodsToIgnore[i]);
			}
		}

		public override bool Equals(object obj)
		{
			MockTypeIdentifier other = obj as MockTypeIdentifier;

			if(other == null)
			{
				return false;
			}

			if(other.typeToMock == this.typeToMock && ListEquals(this.methodsToIgnore, other.methodsToIgnore))
			{
				return true;
			}

			return false;
		}

		public override int GetHashCode()
		{
			return typeToMock.GetHashCode() ^ methodsToIgnore.Count;  //Lame, but simple
		}

		private bool ListEquals(IList listA, IList listB)
		{
			if(listA.Count != listB.Count)
			{
				return false;
			}

			for(int i = 0; i < listA.Count; i++)
			{
				if(listA[i] != listB[i])
				{
					return false;
				}
			}

			return true;
		}
	}
}
Index: ClassGenerator.cs
===================================================================
RCS file: /cvsroot/nmock/nmock/src/NMock/Dynamic/ClassGenerator.cs,v
retrieving revision 1.21
retrieving revision 1.22
diff -C2 -d -r1.21 -r1.22
*** ClassGenerator.cs	17 Jun 2004 05:13:38 -0000	1.21
--- ClassGenerator.cs	23 Jun 2004 04:44:53 -0000	1.22
***************
*** 6,16 ****
  namespace NMock.Dynamic
  {
! 	
! 	public class ClassGenerator 
  	{
  		public const string INVOCATION_HANDLER_FIELD_NAME = "_invocationHandler";
  
! 		internal const System.Reflection.BindingFlags ALL_INSTANCE_METHODS 
! 			= BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic;
  
  		readonly protected Type type;
--- 6,14 ----
  namespace NMock.Dynamic
  {
! 	public class ClassGenerator
  	{
  		public const string INVOCATION_HANDLER_FIELD_NAME = "_invocationHandler";
  
! 		internal const System.Reflection.BindingFlags ALL_INSTANCE_METHODS = BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic;
  
  		readonly protected Type type;
***************
*** 19,27 ****
  		readonly protected Type superclassIfTypeIsInterface;
  
! 		public ClassGenerator(Type type, IInvocationHandler handler)
! 			: this(type, handler, new ArrayList()) {}
  
! 		public ClassGenerator(Type type, IInvocationHandler handler, IList methodsToIgnore)
! 			: this(type, handler, methodsToIgnore, null) {}
  
  		public ClassGenerator(Type type, IInvocationHandler handler, IList methodsToIgnore, Type superclassIfTypeIsInterface)
--- 17,27 ----
  		readonly protected Type superclassIfTypeIsInterface;
  
! 		static ModuleBuilder moduleBuilder;
! 		static Hashtable mockCache = new Hashtable();
! 		static int typeCounter = 0;
  
! 		public ClassGenerator(Type type, IInvocationHandler handler) : this(type, handler, new ArrayList()) {}
! 
! 		public ClassGenerator(Type type, IInvocationHandler handler, IList methodsToIgnore) : this(type, handler, methodsToIgnore, null) {}
  
  		public ClassGenerator(Type type, IInvocationHandler handler, IList methodsToIgnore, Type superclassIfTypeIsInterface)
***************
*** 35,72 ****
  		public virtual object Generate()
  		{
! 			methodsToIgnore.Add("Equals");
! 			methodsToIgnore.Add("ToString");
! 			methodsToIgnore.Add("Finalize");
  
! 			TypeBuilder typeBuilder = CreateTypeBuilder();
! 			MethodImplementor methodImplementor = 
! 				new MethodImplementor(typeBuilder, DefineInvocationHandlerField(typeBuilder));
  
! 			ImplementMethods(methodImplementor);
! 			return CreateProxyInstance(typeBuilder.CreateType());
  		}
  
! 		TypeBuilder CreateTypeBuilder() 
  		{
! 			AppDomain appDomain = AppDomain.CurrentDomain;
! 			AssemblyName assemblyName = new AssemblyName();
! 			assemblyName.Name = "DynamicProxyAssembly";
! 			AssemblyBuilder assemblyBuilder = appDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);
! 			ModuleBuilder moduleBuilder = assemblyBuilder.DefineDynamicModule("MockModule");
! 			return moduleBuilder.DefineType(ProxyClassName, TypeAttributes.Public, ProxySuperClass, ProxyInterfaces);
  		}
  
  		private FieldBuilder DefineInvocationHandlerField(TypeBuilder typeBuilder)
  		{
! 			return typeBuilder.DefineField(
! 				ClassGenerator.INVOCATION_HANDLER_FIELD_NAME, 
! 				typeof(IInvocationHandler), FieldAttributes.Public);
  		}
  
! 		private void ImplementMethods(MethodImplementor methodImplementor)
  		{
  			foreach (Type currentType in new InterfaceLister().List(type))
  			{
! 				foreach ( MethodInfo methodInfo in currentType.GetMethods(ALL_INSTANCE_METHODS) ) 
  				{
  					if (ShouldImplement(methodInfo))
--- 35,112 ----
  		public virtual object Generate()
  		{
! 			IgnoreMethod("Equals");
! 			IgnoreMethod("ToString");
! 			IgnoreMethod("Finalize");
  
! 			return CreateProxyInstance(GetMockType());
! 		}
  
! 		private void IgnoreMethod(string method)
! 		{
! 			if(!methodsToIgnore.Contains(method))
! 			{
! 				methodsToIgnore.Add(method);
! 			}
  		}
  
! 		private Type GetMockType()
  		{
! 			MockTypeIdentifier typeIdentifier = new MockTypeIdentifier(this.type, this.methodsToIgnore);
! 			
! 			Type mockType = (Type)mockCache[typeIdentifier];
! 
! 			if(mockType == null)
! 			{
! 				TypeBuilder typeBuilder = CreateTypeBuilder();
! 
! 				ImplementMethods(typeBuilder);
! 				
! 				mockType = typeBuilder.CreateType();
! 
! 				mockCache[typeIdentifier] = mockType;
! 			}
! 
! 			return mockType;
! 		}
! 
! 		private TypeBuilder CreateTypeBuilder()
! 		{
! 			if(moduleBuilder == null)
! 			{
! 				AppDomain appDomain = AppDomain.CurrentDomain;
! 				AssemblyName assemblyName = new AssemblyName();
! 				assemblyName.Name = "DynamicProxyAssembly";
! 				AssemblyBuilder assemblyBuilder = appDomain.DefineDynamicAssembly(assemblyName, AssemblyBuilderAccess.Run);
! 				moduleBuilder = assemblyBuilder.DefineDynamicModule("MockModule");
! 			}
! 			
! 			TypeBuilder builder = moduleBuilder.DefineType(ProxyClassName, TypeAttributes.Public, ProxySuperClass, ProxyInterfaces);
! 
! 			return builder;
! 		}
! 
! 		private object CreateProxyInstance(Type proxyType)
! 		{
! 			object result = Activator.CreateInstance(proxyType);
! 
! 			FieldInfo handlerField = proxyType.GetField(INVOCATION_HANDLER_FIELD_NAME);
! 			handlerField.SetValue(result, handler);
! 
! 			return result;
  		}
  
  		private FieldBuilder DefineInvocationHandlerField(TypeBuilder typeBuilder)
  		{
! 			return typeBuilder.DefineField(INVOCATION_HANDLER_FIELD_NAME, typeof(IInvocationHandler), FieldAttributes.Public);
  		}
  
! 		private void ImplementMethods(TypeBuilder typeBuilder)
  		{
+ 			FieldBuilder handlerFieldBuilder = DefineInvocationHandlerField(typeBuilder);
+ 			MethodImplementor methodImplementor = new MethodImplementor(typeBuilder, handlerFieldBuilder);
+ 			
  			foreach (Type currentType in new InterfaceLister().List(type))
  			{
! 				foreach ( MethodInfo methodInfo in currentType.GetMethods(ALL_INSTANCE_METHODS) )
  				{
  					if (ShouldImplement(methodInfo))
***************
*** 80,144 ****
  		private bool ShouldImplement(MethodInfo methodInfo)
  		{
! 			if ( (! methodInfo.IsVirtual) || methodInfo.IsFinal || methodInfo.IsAssembly)
  			{
! 				methodsToIgnore.Add(methodInfo.Name);
  			}
  			return ! methodsToIgnore.Contains(methodInfo.Name);
  		}
  
! 		private object CreateProxyInstance(Type proxyType) 
  		{
! 			object result = Activator.CreateInstance(proxyType);
! 
! 			FieldInfo handlerField = proxyType.GetField(INVOCATION_HANDLER_FIELD_NAME);
! 			handlerField.SetValue(result, handler);
! 
! 			return result;
  		}
- 	
- 		public string ProxyClassName { get { return "Proxy" + type.Name; } }
- 		public Type ProxySuperClass { get { return type.IsInterface ? superclassIfTypeIsInterface : type; } }
- 		public Type[] ProxyInterfaces { get { return type.IsInterface ? new Type[] { type } : new Type[0]; } }		
- 	}
- 	
- 	public class BoxingOpCodes
- 	{
- 		private static IDictionary boxingOpCodes;
  
! 		public OpCode this[Type aType] 
  		{
! 			get
! 			{
! 				return GetOpCode(aType);
! 			}
  		}
! 
! 		private static OpCode GetOpCode( Type aType ) 
  		{
! 			if (boxingOpCodes == null) 
! 			{
! 				boxingOpCodes = new Hashtable();
! 				boxingOpCodes[typeof(sbyte)]  = OpCodes.Ldind_I1;
! 				boxingOpCodes[typeof(short)]  = OpCodes.Ldind_I2;
! 				boxingOpCodes[typeof(int)]    = OpCodes.Ldind_I4;
! 				boxingOpCodes[typeof(long)]   = OpCodes.Ldind_I8;
! 				boxingOpCodes[typeof(byte)]   = OpCodes.Ldind_U1;
! 				boxingOpCodes[typeof(ushort)] = OpCodes.Ldind_U2;
! 				boxingOpCodes[typeof(uint)]   = OpCodes.Ldind_U4;
! 				boxingOpCodes[typeof(ulong)]  = OpCodes.Ldind_I8;
! 				boxingOpCodes[typeof(float)]  = OpCodes.Ldind_R4;
! 				boxingOpCodes[typeof(double)] = OpCodes.Ldind_R8;
! 				boxingOpCodes[typeof(char)]   = OpCodes.Ldind_U2;
! 				boxingOpCodes[typeof(bool)]   = OpCodes.Ldind_I1;
! 			}
! 			if (boxingOpCodes.Contains(aType)) 
! 			{
! 				return (OpCode)boxingOpCodes[aType];
! 			}
! 			else 
! 			{
! 				return OpCodes.Ldind_I1;
! 			}
  		}
  	}
! }
--- 120,143 ----
  		private bool ShouldImplement(MethodInfo methodInfo)
  		{
! 			if ((!methodInfo.IsVirtual) || methodInfo.IsFinal || methodInfo.IsAssembly)
  			{
! 				IgnoreMethod(methodInfo.Name);
  			}
  			return ! methodsToIgnore.Contains(methodInfo.Name);
  		}
  
! 		public string ProxyClassName
  		{
! 			get { return "Proxy" + type.Name + "_" + typeCounter++; } 
  		}
  
! 		public Type ProxySuperClass
  		{
! 			get { return type.IsInterface ? superclassIfTypeIsInterface : type; } 
  		}
! 		public Type[] ProxyInterfaces 
  		{
! 			get { return type.IsInterface ? new Type[] { type } : new Type[0]; } 
  		}
  	}
! }
\ No newline at end of file

--- NEW FILE: BoxingOpCodes.cs ---
using System;
using System.Collections;
using System.Reflection.Emit;

namespace NMock.Dynamic
{
	public class BoxingOpCodes
	{
		private static IDictionary boxingOpCodes;

		public OpCode this[Type aType] 
		{
			get
			{
				return GetOpCode(aType);
			}
		}

		private static OpCode GetOpCode( Type aType ) 
		{
			if (boxingOpCodes == null) 
			{
				boxingOpCodes = new Hashtable();
				boxingOpCodes[typeof(sbyte)]  = OpCodes.Ldind_I1;
				boxingOpCodes[typeof(short)]  = OpCodes.Ldind_I2;
				boxingOpCodes[typeof(int)]    = OpCodes.Ldind_I4;
				boxingOpCodes[typeof(long)]   = OpCodes.Ldind_I8;
				boxingOpCodes[typeof(byte)]   = OpCodes.Ldind_U1;
				boxingOpCodes[typeof(ushort)] = OpCodes.Ldind_U2;
				boxingOpCodes[typeof(uint)]   = OpCodes.Ldind_U4;
				boxingOpCodes[typeof(ulong)]  = OpCodes.Ldind_I8;
				boxingOpCodes[typeof(float)]  = OpCodes.Ldind_R4;
				boxingOpCodes[typeof(double)] = OpCodes.Ldind_R8;
				boxingOpCodes[typeof(char)]   = OpCodes.Ldind_U2;
				boxingOpCodes[typeof(bool)]   = OpCodes.Ldind_I1;
			}
			if (boxingOpCodes.Contains(aType)) 
			{
				return (OpCode)boxingOpCodes[aType];
			}
			else 
			{
				return OpCodes.Ldind_I1;
			}
		}
	}
}

[Nmock-general] nmock/src src.csproj,1.10,1.11

[Owen R. <exo...@us...>]

Update of /cvsroot/nmock/nmock/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3533/src

Modified Files:
	src.csproj 
Log Message:
committing jim's new fixes for increasing performance and reducing memory requirements

Index: src.csproj
===================================================================
RCS file: /cvsroot/nmock/nmock/src/src.csproj,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** src.csproj	17 Jun 2004 05:13:38 -0000	1.10
--- src.csproj	23 Jun 2004 04:44:53 -0000	1.11
***************
*** 175,178 ****
--- 175,183 ----
                  />
                  <File
+                     RelPath = "NMock\Dynamic\BoxingOpCodes.cs"
+                     SubType = "Code"
+                     BuildAction = "Compile"
+                 />
+                 <File
                      RelPath = "NMock\Dynamic\ClassGenerator.cs"
                      SubType = "Code"
***************
*** 190,193 ****
--- 195,203 ----
                  />
                  <File
+                     RelPath = "NMock\Dynamic\MockTypeIdentifier.cs"
+                     SubType = "Code"
+                     BuildAction = "Compile"
+                 />
+                 <File
                      RelPath = "NMock\Dynamic\MSILStack.cs"
                      SubType = "Code"