Menu
▾
▴
nmock-two-dev — Discussion of development of NMock 2
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(17) |
Aug
(6) |
Sep
(13) |
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(99) |
Mar
(42) |
Apr
(8) |
May
(17) |
Jun
(1) |
Jul
(1) |
Aug
(6) |
Sep
|
Oct
|
Nov
(26) |
Dec
|
| 2007 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(21) |
Jun
|
Jul
(2) |
Aug
(21) |
Sep
(20) |
Oct
(33) |
Nov
(26) |
Dec
|
| 2008 |
Jan
(45) |
Feb
(8) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2009 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(1) |
Dec
|
|
From: Steve M. <Ste...@ty...> - 2008-02-01 16:59:02
|
This is a failure in your test code and not the coverage of the NMock code? =20 If that is the case, can you post any information about the failures, and what parts of NMock are being used for those particular tests? =20 I haven't seen any failures in my production code. =20 From: nmo...@li... [mailto:nmo...@li...] On Behalf Of Mike Mason Sent: Thursday, January 31, 2008 5:30 PM To: nmock-dev Subject: [NMock2-Dev] Problems with ncover and nmock 2.0 rc2 =20 Hi all, I just attempted to upgrade from rc1 to rc2. Everything looked good (no compile errors or anything) and my unit tests all still passed. Great news. But when I tried to run ncover to get my build coverage numbers, I got two test failures. The tests definitely work ok within plain NUnit, it seems to just be a problem with ncover. Has anyone seen something similar? If not I'll go dig a little deeper and see if there's anything funny about those two tests. Cheers, Mike. |
|
From: Mike M. <mg...@es...> - 2008-02-01 16:38:52
|
On Feb 1, 2008 7:16 AM, Steve Mitcham <Ste...@ty...> wrote: > Which version of NCover? > > 1.5.8, the final non-commercial version. |
|
From: Steve M. <Ste...@ty...> - 2008-02-01 14:28:59
|
Which version of NCover? =20 From: nmo...@li... [mailto:nmo...@li...] On Behalf Of Mike Mason Sent: Thursday, January 31, 2008 5:30 PM To: nmock-dev Subject: [NMock2-Dev] Problems with ncover and nmock 2.0 rc2 =20 Hi all, I just attempted to upgrade from rc1 to rc2. Everything looked good (no compile errors or anything) and my unit tests all still passed. Great news. But when I tried to run ncover to get my build coverage numbers, I got two test failures. The tests definitely work ok within plain NUnit, it seems to just be a problem with ncover. Has anyone seen something similar? If not I'll go dig a little deeper and see if there's anything funny about those two tests. Cheers, Mike. |
|
From: Mike M. <mg...@es...> - 2008-01-31 23:29:59
|
Hi all, I just attempted to upgrade from rc1 to rc2. Everything looked good (no compile errors or anything) and my unit tests all still passed. Great news. But when I tried to run ncover to get my build coverage numbers, I got two test failures. The tests definitely work ok within plain NUnit, it seems to just be a problem with ncover. Has anyone seen something similar? If not I'll go dig a little deeper and see if there's anything funny about those two tests. Cheers, Mike. |
|
From: Nat P. <nat...@gm...> - 2008-01-31 17:38:27
|
On 31/01/2008, Richard Holden <aci...@ac...> wrote: > I've started to work up some code to get this done, but so far I can still > go either way on the syntax. Please let me know what you think, or if you > have any suggestions for alternate syntax. Can I reccommend that you *don't* implement clearing expectations. It created so much confusion in JMock 1. You'll increase your support load if you implement it in NMock2. The idea of JMock and NMock (c.f. EasyMock, RhinoMock) is that expectations are declarative, but the test is imperative. If you can change the expectations half-way through a test, you break that model. In JMock 2 we've solved this issue with states (http://www.jmock.org/states.html, http://www.jmock.org/override.html). You can define expectations/stubs that only apply when a state machine is (or is not) in a particular state. The test can use a state machine to explicitly move between states thereby defining which expectations apply. --Nat |
|
From: Richard H. <aci...@ac...> - 2008-01-31 16:39:39
|
On Thu, January 31, 2008 9:09 am, Steve Mitcham wrote: > Did you deal with the issues that were related to nmock1, if so then we > can go through the feature request list and decide what to include. > I handled all the Bugs from nmock1. I still have to sort through the feature list. I'll try to get to that by Monday. I plan to integrate FxCop and NCover in our builds, we should come up with metrics from these tools that are acceptable for release. (Just thought of this). I guess this would also be a call to all users to get feature requests on to the tracker. -Richard Holden |
|
From: Steve M. <Ste...@ty...> - 2008-01-31 16:33:19
|
I'm not sure I like the idea of extending the 'language' for this
feature.
I think the three primary complaints are:
1. You can't set a stub that is overridden by an expectation.
2. You can't override an existing expectation with matching parameters
(or can you?) to return a different value.
I think that if we are going to add support, doing the rework is needed.
I would propose a layered approach:
Expect...With() <-- Top of stack, checked first for a match.
Expect...WithAnyParameters <-- called if none of the specific
expectations match. If this is present and not called the verification
will fail, having this and Stub is redundant, stub would never get
called.
Stub. <-- Default value at the base of the expectation stack, doesn't
care about being called or not called.
In this event I don't think you really need a 'clear' method if we
combine the implementation with another feature request (delayed
processing).
We allow '.Will.Return(delegate { return localVar; });' syntax to allow
a delayed result.
We also allow '.Will.ReturnMultiple(delegate { for (int i=3D0; i< 10; =
i++)
yield return i;})'
That will return multiple values in successive calls. The options here
are to cause an error if the entire set doesn't get called or if it runs
out.
The delayed evaluation would allow the user to change the variable being
returned from the mock during the execution of the test.
-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of
Richard Holden
Sent: Thursday, January 31, 2008 10:15 AM
To: nmo...@li...
Subject: [NMock2-Dev] Clear Syntax or "Fixing the Stub Lifetime Problem"
Without doing the kind of rework that I believe is needed to handle
stubs
more correctly/more easily, I am trying to solve the problem of setting
a
stub first, then needing an expectation of the same method later. Per
some
suggestions on this list I thought we might define a syntax for Clear
where devs could explicitly clear a stub or expectation.
I have two different syntaxes I am considering:
First would be to have 2 types of explicit calls:
Clear.On(foo).All() would remove all expectations/stubs for the foo mock
object.
Clear.On(foo).Method("bar") would remove all expectations/stubs for the
method bar on the foo mock object.
This syntax is fairly clear but it is somewhat limited in potential
uses.
Second proposal:
Have the Clear syntax create a function object that can be used with
more
of the IMatcher/IAction syntax, i.e.
Clear.On(foo)(); //Clear all expectations/stubs on foo mock object.
Clear.On(foo).Method("bar")(); //Clear all expectations for the bar
method
on the foo mock object.
Clear.On(foo).Method("bar").With(3)(); //Clear all expectations for the
bar method where the expected call parameter is 3 on the foo mock
object.
The problem I see with this syntax is the ability to leave off the
ending
() to actually make the function call.
One of the benefits of this syntax though is more fine grained control
over what expectations/stubs get cleared.
I've started to work up some code to get this done, but so far I can
still
go either way on the syntax. Please let me know what you think, or if
you
have any suggestions for alternate syntax.
-Richard Holden
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NMock-two-dev mailing list
NMo...@li...
https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
|
|
From: Steve F. <st...@m3...> - 2008-01-31 16:29:18
|
Can I strongly recommend against fine-grained clearing, we tried to
be less clever than this with jMock1 and people already got confused.
In fact I'd recommend against clear altogether. If you're calling the
same method with the same parameters, then I can't see how one case
would be a stub and one an expectation.
The point is /not/ to make it too easy, let the tests guide the code.
S.
On 31 Jan 2008, at 16:14, Richard Holden wrote:
> Without doing the kind of rework that I believe is needed to handle
> stubs
> more correctly/more easily, I am trying to solve the problem of
> setting a
> stub first, then needing an expectation of the same method later.
> Per some
> suggestions on this list I thought we might define a syntax for Clear
> where devs could explicitly clear a stub or expectation.
>
> I have two different syntaxes I am considering:
>
> First would be to have 2 types of explicit calls:
>
> Clear.On(foo).All() would remove all expectations/stubs for the foo
> mock
> object.
>
> Clear.On(foo).Method("bar") would remove all expectations/stubs for
> the
> method bar on the foo mock object.
>
> This syntax is fairly clear but it is somewhat limited in potential
> uses.
>
> Second proposal:
>
> Have the Clear syntax create a function object that can be used
> with more
> of the IMatcher/IAction syntax, i.e.
>
> Clear.On(foo)(); //Clear all expectations/stubs on foo mock object.
> Clear.On(foo).Method("bar")(); //Clear all expectations for the bar
> method
> on the foo mock object.
>
> Clear.On(foo).Method("bar").With(3)(); //Clear all expectations for
> the
> bar method where the expected call parameter is 3 on the foo mock
> object.
>
> The problem I see with this syntax is the ability to leave off the
> ending
> () to actually make the function call.
>
> One of the benefits of this syntax though is more fine grained control
> over what expectations/stubs get cleared.
>
> I've started to work up some code to get this done, but so far I
> can still
> go either way on the syntax. Please let me know what you think, or
> if you
> have any suggestions for alternate syntax.
>
> -Richard Holden
>
>
> ----------------------------------------------------------------------
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> NMock-two-dev mailing list
> NMo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
>
Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006
http://www.m3p.co.uk
M3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627
|
|
From: Steve M. <Ste...@ty...> - 2008-01-31 16:28:24
|
Did you deal with the issues that were related to nmock1, if so then we can go through the feature request list and decide what to include. -----Original Message----- From: nmo...@li... [mailto:nmo...@li...] On Behalf Of Richard Holden Sent: Thursday, January 31, 2008 10:06 AM To: nmo...@li... Subject: [NMock2-Dev] Defining 2.0 Release Goals/Requirements I'm concerned that we don't have a set criteria for doing a full NMock2 release. We have 2 bugs and 12 open feature requests currently, but I would like some help in deciding when to call it the official 2.0 release. For those of you working with NMock2 in your day to day jobs is there anything that you would consider critical? Anything your bosses/team leads have said "we shouldn't be using this because it doesn't have feature X"? I would like to get some defined criteria so we can put ourselves back on track to have consistent releases, and make it easier for new developers to get started. -Richard Holden ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ NMock-two-dev mailing list NMo...@li... https://lists.sourceforge.net/lists/listinfo/nmock-two-dev |
|
From: Richard H. <aci...@ac...> - 2008-01-31 16:15:13
|
Without doing the kind of rework that I believe is needed to handle stubs
more correctly/more easily, I am trying to solve the problem of setting a
stub first, then needing an expectation of the same method later. Per some
suggestions on this list I thought we might define a syntax for Clear
where devs could explicitly clear a stub or expectation.
I have two different syntaxes I am considering:
First would be to have 2 types of explicit calls:
Clear.On(foo).All() would remove all expectations/stubs for the foo mock
object.
Clear.On(foo).Method("bar") would remove all expectations/stubs for the
method bar on the foo mock object.
This syntax is fairly clear but it is somewhat limited in potential uses.
Second proposal:
Have the Clear syntax create a function object that can be used with more
of the IMatcher/IAction syntax, i.e.
Clear.On(foo)(); //Clear all expectations/stubs on foo mock object.
Clear.On(foo).Method("bar")(); //Clear all expectations for the bar method
on the foo mock object.
Clear.On(foo).Method("bar").With(3)(); //Clear all expectations for the
bar method where the expected call parameter is 3 on the foo mock object.
The problem I see with this syntax is the ability to leave off the ending
() to actually make the function call.
One of the benefits of this syntax though is more fine grained control
over what expectations/stubs get cleared.
I've started to work up some code to get this done, but so far I can still
go either way on the syntax. Please let me know what you think, or if you
have any suggestions for alternate syntax.
-Richard Holden
|
|
From: Richard H. <aci...@ac...> - 2008-01-31 16:06:54
|
I'm concerned that we don't have a set criteria for doing a full NMock2 release. We have 2 bugs and 12 open feature requests currently, but I would like some help in deciding when to call it the official 2.0 release. For those of you working with NMock2 in your day to day jobs is there anything that you would consider critical? Anything your bosses/team leads have said "we shouldn't be using this because it doesn't have feature X"? I would like to get some defined criteria so we can put ourselves back on track to have consistent releases, and make it easier for new developers to get started. -Richard Holden |
|
From: Steve F. <st...@m3...> - 2008-01-31 00:52:48
|
Thanks for picking this up. S. On 31 Jan 2008, at 00:31, Richard Holden wrote: > I'm pleased to announce the latest release of NMock2 2.0.0RC2 is now > available . This release introduces quite a few changes, too > numerous to > list here. Please see the release notes and change log at > http://sourceforge.net/project/shownotes.php? > group_id=66591&release_id=572749 > > Thanks go out to all those who participated in getting this release > out. > > -Richard Holden > > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Nmock-general mailing list > Nmo...@li... > https://lists.sourceforge.net/lists/listinfo/nmock-general > Steve Freeman Winner of the Agile Alliance Gordon Pask award 2006 http://www.m3p.co.uk M3P Limited. Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ. Company registered in England & Wales. Number 03689627 |
|
From: Richard H. <aci...@ac...> - 2008-01-31 00:30:58
|
I'm pleased to announce the latest release of NMock2 2.0.0RC2 is now available . This release introduces quite a few changes, too numerous to list here. Please see the release notes and change log at http://sourceforge.net/project/shownotes.php?group_id=66591&release_id=572749 Thanks go out to all those who participated in getting this release out. -Richard Holden |
|
From: Owen R. <exo...@gm...> - 2008-01-30 21:38:08
|
On 29/01/2008, aci...@ac... <aci...@ac...> wrote: > Thanks for getting it updated. I just noticed that the ccnetlive server > seems to be hung up checking for modifications on our NMock2 project. Is > there someone I should contact to get this fixed. Also I was wondering if > there is any type of greater access some of us could get to the ccnetlive > server to better handle configuration changes. i restarted the service which seemed to fix the problem. i can't give you direct access to the box, but if you are interested in making changes to the ccnet.config file it is monitored from the ccnet svn repository: http://ccnet.svn.sourceforge.net/viewvc/ccnet/environments/ccnetlive/ccnet.config?view=markup we can talk about giving commit access to ccnet, but you need to be careful making changes to this file as it will affect all projects monitored by ccnet. this would be easier if we set up ccnet to use different config files for each project that it is monitoring. cheers, owen. -- Owen Rogers | http://exortech.com/blog | CruiseControl.NET - http://ccnet.thoughtworks.com |
|
From: <aci...@ac...> - 2008-01-29 21:55:07
|
On Sun, January 20, 2008 10:44 pm, Owen Rogers wrote: > sorry for the delay. i've updated the ccnet.config file and the nmock > build is now passing. > i forgot to mention: the nmock2 binaries are now published at: > http://ccnetlive.thoughtworks.com/NMock2%2Dbuilds/ > cheers, > owen. > Thanks for getting it updated. I just noticed that the ccnetlive server seems to be hung up checking for modifications on our NMock2 project. Is there someone I should contact to get this fixed. Also I was wondering if there is any type of greater access some of us could get to the ccnetlive server to better handle configuration changes. Thanks -Richard Holden |
|
From: Steve M. <Ste...@ty...> - 2008-01-25 19:01:18
|
SeKAmW0gc3RpbGwgbm90IGZvbGxvd2luZyB5b3VyIGxvZ2ljLiAgSeKAmW0gZ29pbmcgdG8gZ28g dGhyb3VnaCBzdGVwIGJ5IHN0ZXAgYW5kIHRyeSB0byBleHBsYWluIHdoYXQgSSBzZWUgYW5kIHlv dSBjYW4gcG9pbnQgb3V0IHdoYXQgSeKAmW0gbWlzc2luZw0KDQogDQoNCkV4cGVjdC4gIC8vIGlu aXRpYWxpemF0aW9uIG9mIGNhbGwsIG5vIGNvbnRleHR1YWwgaW5mb3JtYXRpb24NCg0KIA0KDQpP bmNlLiAgLy8gQWNjb3JkaW5nIHRvIHlvdXIgbGFzdCBlLW1haWwgcGxhY2VzIHRocmVhZCBpbnRv IOKAmHJlY29yZOKAmSBtb2RlLiAgKG1vcmUgb24gdGhpcyBiZWxvdykNCg0KIA0KDQpPblByb3Bl cnR5KGZvby5Qcm9wKS4gIC8vIFN1cHBvc2VkIHRvIGFzc2lnbiBwcm9wZXJ0eSBpbmZvcm1hdGlv biwgZXhjZXB0IHRoYXQgZm9vLlByb3Agd2lsbCBiZSBldmFsdWF0ZWQgYW5kIHRoZXJlZm9yZSBz dGlsbCBubyBjb250ZXh0DQoNCiANCg0KV2l0aCgxMjMpOyAgLy8gRm9sbG93IHVwIGluZm9ybWF0 aW9uIGZvciBjYWxsLCBleGNlcHQgdGhlcmUgaXMgbm8gcmVjb3JkIG9mIHdoYXQgcHJvcGVydHkg dG8gYXNzb2NpYXRlLg0KDQogDQoNCiANCg0KIA0KDQpUaGVyZSBpcyBubyDigJhyZWNvcmTigJkv 4oCZcGxheWJhY2vigJkgd2l0aCBOTW9jay4gIFRoZSBFeHBlY3QgY2FsbCBjcmVhdGVzIGFuIGlu c3RhbmNlIG9mIGFuIG9iamVjdCB0aGF0IGlzIGJ1aWx0IHVwIGZyb20gdGhlIHJlbWFpbmluZyBj YWxscyB0byBkZWZpbmUgdGhlIGV4cGVjdGF0aW9uLiAgVGhlcmUgaXMgbm8gc3RhdGljIHN0YXRl IHRoYXQgY2FuIGJlIG1hbmlwdWxhdGVkIGluIHRoZSB3YXkgeW91IGFyZSBzdWdnZXN0aW5nLg0K DQogDQoNCkZyb206IG5tb2NrLXR3by1kZXYtYm91bmNlc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQg W21haWx0bzpubW9jay10d28tZGV2LWJvdW5jZXNAbGlzdHMuc291cmNlZm9yZ2UubmV0XSBPbiBC ZWhhbGYgT2YgRHJldyBOb2FrZXMNClNlbnQ6IEZyaWRheSwgSmFudWFyeSAyNSwgMjAwOCAxMjox MiBQTQ0KVG86IE5Nb2NrMiBEZXZlbG9wbWVudCBEaXNjdXNzaW9uDQpTdWJqZWN0OiBSZTogW05N b2NrMi1EZXZdIEZXOiBSZWZhY3RvcmFibGUgY2FsbHMNCg0KIA0KDQo+WW91ciBzaWduYXR1cmUg aXMgT25Qcm9wZXJ0eShUIHByb3BlcnR5KSBmb3Igd2hpY2ggSSBhc3N1bWUgeW91IG1lYW4gT25Q cm9wZXJ0eTxUPihUIHByb3BlcnR5KSBzaW5jZSB0aGUgT25jZSBpdGVtIGRvZXNu4oCZdCBoYXZl IGEgZ2VuZXJpYyB0eXBlIGFscmVhZHkgYXNzb2NpYXRlZCB3aXRoIGl0Lg0KDQpZb3UncmUgcmln aHQuICBJIG1lYW50IE9uUHJvcGVydHk8VD4oVCBwcm9wZXJ0eSkNCiANCj5XaGVyZSwgaW4geW91 ciBwYXR0ZXJuLCBkb2VzIHRoZSBpbmZvcm1hdGlvbiBhYm91dCB3aGljaCBwcm9wZXJ0eSBpcyBj YWxsZWQgZ2V0cyBwYXNzZWQgaW50byB0aGUgc3lzdGVtPyAgVGhlIGNhbGwgc3RhY2sgd2lsbCBu b3QgaGF2ZSB0aGUgaW5mb3JtYXRpb24geW91IGNhbiBzZWFyY2ggZm9yLg0KDQpJIHRyaWVkIHRv IGV4cGxhaW4gdGhpcyBpbiBteSBvcmlnaW5hbCBlbWFpbCBhbmQgbXkgZm9sbG93IHVwLiAgVGhl ICdPbmNlJyBtZW1iZXIgc2V0cyB0aGUgdGhyZWFkIGludG8gcmVjb3JkIG1vZGUuICBUaGUgbmV4 dCB1c2FnZSBvZiBhIG1vY2sncyBtZW1iZXIgb24gdGhhdCB0aHJlYWQgaXMgY29uc2lkZXJlZCBh biBleHBlY3RhdGlvbi4gIEkgaGF2ZW4ndCBzcGVudCBtdWNoIHRpbWUgd29ya2luZyBvdXQgd2hl dGhlciB0aGlzIGltcGxpY2l0IG1vY2sgc3RhdGUgdHJhbnNpdGlvbmluZyBhY3R1YWxseSB3b3Jr cyBpbiBhIHZhcmlldHkgb2Ygc2NlbmFyaW9zLiAgRm9yIGV4YW1wbGUgaWYgeW91IGhhZCBjb2Rl ICJFeHBlY3QuT25jZS5Ub1N0cmluZygpIiB0aGVuIHlvdSdkIGxlYXZlIHRoZSB0aHJlYWQgaGFu Z2luZyBpbiByZWNvcmQgbW9kZSwgYnV0IHRoYXQncyBub3QgYSB2ZXJ5IGxpa2VseSBzY2VuYXJp by4NCg0KPk9uUHJvcGVydHkoKCk9PmZvby5Qcm9wKQ0KPldoZXJlIHRoZSBwYXJhbWV0ZXIgaXMg YSBsYW1iZGEgZXhwcmVzc2lvbiB0aGF0IHlvdSBjYW4gcXVlcnkgdG8gZGlzY292ZXIgdGhlIGlk ZW50aXR5IG9mIOKAmFByb3DigJksIGJ1dCBJ4oCZbSB0cnlpbmcgdG8gc3RheSB3aXRoIC5ORVQg Mi4wIGZvciBub3cuDQoNCkknbSBwZXJzb25hbGx5IHF1aXRlIGV4Y2l0ZWQgdG8gc2VlIHdoYXQg bW9ja2luZyBvcHBvcnR1bml0aWVzIGFyaXNlIGZyb20gdGhpcyBsYW1iZGEgZXhwcmVzc2lvbiB0 cmVlIGFwcHJvYWNoLg0KDQpEcmV3Lg0KDQogDQoNCkZyb206IERyZXcgTm9ha2VzIFttYWlsdG86 ZHJld25vYWtlc0B5YWhvby5jb20uYXVdIA0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDI1LCAyMDA4 IDM6MzUgQU0NClRvOiBTdGV2ZSBNaXRjaGFtDQpTdWJqZWN0OiBSZTogW05Nb2NrMi1EZXZdIFJl ZmFjdG9yYWJsZSBjYWxscw0KDQogDQoNCj4gRHJldzogDQoNCj4gWW91ciBPblByb3BlcnR5IG1l dGhvZCB3aWxsIGV2YWx1YXRlIHRvIHRoZSB2YWx1ZSBvZiB0aGUgcHJvcGVydHksIG5vdCB0aGUg cHJvcGVydHkgaXRzZWxmIGFuZCBzaW5jZSB0aGUgcHJvcGVydHkgY29tZXMgZnJvbSBhIE1vY2sg eW91IHdpbGwgYWNjZXNzIGl0IGJlZm9yZSBpdCBpcyBkZWZpbmVkLg0KDQogDQoNCk9uUHJvcGVy dHkgZG9lcyB3b3VsZCBub3QgY2FyZSBhYm91dCB0aGUgcHJvcGVydHkncyByZXR1cm4gdmFsdWUu ICBBcyBJIHNhaWQsIHRoYXQgd291bGQganVzdCBiZSBkZWZhdWx0KFQpLiAgSG93ZXZlciwgYXQg dGhlIHRpbWUgdGhhdCB0aGUgbW9jaydzIHByb3BlcnR5IGdldHRlciBpcyBjYWxsZWQsIHRoZSBm cmFtZXdvcmsgd291bGQgdHJlYXQgdGhlIGNhbGwgYXMgYSByZWNvcmQsIG5vdCBhIHBsYXliYWNr LiAgVGhlIHJlY29yZCBzdGF0ZSBpcyBlc3RhYmxpc2hlZCBkdXJpbmcgdGhlIEV4cGVjdC5PbmNl IGdldHRlci4gIEkgdGhpbmsgaXQncyBxdWl0ZSBsaWtlbHkgdGhhdCB0aGlzIHBhdHRlcm4gd291 bGQgd29yaywgYXQgbGVhc3QgaW4gbW9zdCBjYXNlcy4NCg0KIA0KDQpGcm9tOiBubW9jay10d28t ZGV2LWJvdW5jZXNAbGlzdHMuc291cmNlZm9yZ2UubmV0IFttYWlsdG86bm1vY2stdHdvLWRldi1i b3VuY2VzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gT24gQmVoYWxmIE9mIERyZXcgTm9ha2VzDQpT ZW50OiBUaHVyc2RheSwgSmFudWFyeSAyNCwgMjAwOCAxMTo0MyBBTQ0KVG86IE5Nb2NrMiBEZXZl bG9wbWVudCBEaXNjdXNzaW9uDQpTdWJqZWN0OiBSZTogW05Nb2NrMi1EZXZdIFJlZmFjdG9yYWJs ZSBjYWxscw0KDQogDQoNCj5FeHBlY3QuT25jZS5Pbihmb28pLlNldHRlci5QbG9uay5XaXRoKDEy Myk7DQo+RXhwZWN0Lk9uY2UuT24oZm9vKS5HZXR0ZXIuU3F1ZWUuV2lsbCguLi4pOw0KPg0KPndo ZXJlIE1ldGhvZCwgU2V0dGVyIGFuZCBHZXR0ZXIgYWxsIHJldHVybiB5b3VyIGdlbmVyYXRlZCBJ Rm9vPw0KDQoNCklmIFNldHRlciAmIEdldHRlciByZXR1cm4gSUZvbywgaG93IGNhbiB0aGV5IGhh dmUgdGhlIFdpdGggYW5kIFdpbGwgbWVtYmVycz8NCg0KUHJvcGVydGllcyBhbHdheXMgaGF2ZSBh IHJldHVybiB0eXBlIHNvIGhvdyBhYm91dDoNCg0KICAgIEV4cGVjdC5PbmNlLk9uUHJvcGVydHko Zm9vLlByb3ApLldpdGgoMTIzKTsNCiAgICBFeHBlY3QuT25jZS5PblByb3BlcnR5KGZvby5Qcm9w KS5XaWxsKFJldHVybi5WYWx1ZSgxMjMpKTsNCg0KVGhlIE9uUHJvcGVydHkgbWV0aG9kIHdvdWxk IGhhdmUgYSBzaWduYXR1cmUgbGlrZSB0aGlzOg0KDQogICAgcHVibGljIElQcm9wZXJ0eU9wdGlv bnM8VD4gT25Qcm9wZXJ0eShUIHByb3BlcnR5KTsNCg0KQW5kIGludGVyZmFjZSBJUHJvcGVydHlP cHRpb25zPFQ+IHdvdWxkIGhhdmUgbWVtYmVyczoNCg0KICAgIHZvaWQgV2l0aChUIGV4cGVjdGVk VmFsdWUpOw0KICAgIHZvaWQgV2lsbChBY3Rpb248VD4gYWN0aW9uKTsNCg0KLi4uYXMgd2VsbCBh cyBzb21lIGV4dHJhIG92ZXJsb2FkcyB0byBzdXBwb3J0IG1hdGNoZXJzLg0KDQpVbmZvcnR1bmF0 ZWx5IHRoaXMgcmVxdWlyZXMgc29tZSB3YXkgdG8gdHJhcCB0aGUgdXNhZ2Ugb2YgdGhlIG1vY2sg ZHVyaW5nIHNldHRpbmcgdXAgb2YgZXhwZWN0YXRpb25zLiAgSSBiZWxpZXZlIHRoaXMgbWlnaHQg YmUgcG9zc2libGUgd2l0aG91dCBhbiBleHBsaWNpdCByZWNvcmQvcmVwbGF5IHNlY3Rpb246DQoN CiAgIEV4cGVjdC5PbmNlLk9uUHJvcGVydHkoZm9vLlByb3ApLldpdGgoMTIzKTsNCg0KVW5sZXNz IEknbSBtaXN0YWtlbiwgdGhlIG9yZGVyIG9mIGV4ZWN1dGlvbiBoZXJlIGlzOg0KDQoxKSBFeHBl Y3QuT25jZQ0KMikgZm9vLlByb3ANCjMpIE9uUHJvcGVydHkoLi4uKQ0KDQpEdXJpbmcgc3RlcCAx IGEgZmxhZyBjb3VsZCBiZSBzZXQgaW50ZXJuYWxseSBzdWNoIHRoYXQgdGhlIG5leHQgdXNhZ2Ug b2YgYSBtb2NrIGlzIGNvbnNpZGVyZWQgYSByZWNvcmRpbmcuICBJbiBzdGVwIDIgdGhlIGR5bmFt aWMgcHJvcGVydHkga25vd3MgaXQncyBpbiByZWNvcmQgbW9kZSwgc28gcmV0dXJucyBkZWZhdWx0 KFQpLCBhbmQgdGhlIHJlY29yZGluZyBmbGFnIGlzIGNsZWFyZWQuICBGaW5hbGx5LCB0aGUgcHJv cGVydHkncyBpZGVudGl0eSBpcyB1c2VkIGluIHN0ZXAgMy4gIEF0IHRoaXMgcG9pbnQsIGFsbCBy ZW1lbWJlcmVkIHN0YXRlIGFyZSBjbGVhcmVkLiAgQXMgdGhlIHN0YXRlIGlzIG5vdCBleHBsaWNp dGx5IHBhc3NlZCBiZXR3ZWVuIHRoZXNlIHBpZWNlcyBvZiBjb2RlIGl0IHdvdWxkIGhhdmUgdG8g YmUgZGlzY292ZXJhYmxlLCB0aG91Z2ggZ2xvYmFsIHN0YXRlIHdvdWxkIG1lYW4gbm8gcnVubmlu ZyB0ZXN0cyBjb25jdXJyZW50bHkuICBUaGVyZWZvcmUsIGl0IG1ha2VzIHNlbnNlIHRvIGFzc29j aWF0ZSBhbnkgZmxhZ3MvbWVtb3J5IHRvIGV4ZWN1dGluZyB0aHJlYWQuICBUaGlzIHN0YXRlIHdv dWxkIG5lZWQgdG8gYmUgY2FyZWZ1bGx5IGNvbnNpZGVyZWQgYW5kIHRlc3RlZCBpbiBvdGhlciB1 c2FnZSBzY2VuYXJpb3MgdG9vLg0KDQpUaGlzIGlzIHByZXR0eSBzaW1pbGFyIHRvIHdoYXQgUmhp bm8uTW9ja3MgZG9lcyBJIHRoaW5rLCB0aG91Z2ggd2l0aG91dCB0aGUgZXhwbGljaXQgcmVjb3Jk IGFuZCBwbGF5YmFjayBzZWN0aW9ucy4gIElmIHRoaXMgZGVzaWduIHdvcmtlZCBpdCBtaWdodCBi ZSBxdWl0ZSBuaWNlIHRvIHdvcmsgd2l0aC4gIElmLCBob3dldmVyLCBpdCBpbnRyb2R1Y2VkIGxv dHMgb2Ygb3Bwb3J0dW5pdHkgdG8gYmUgY29uZnVzZWQgYnkgdW5leHBlY3RlZCBiZWhhdmlvdXIg dGhlbiBJIHdvdWxkIGF2b2lkIGl0Lg0KDQpEcmV3Lg0KDQogDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNClNlbnQgZnJvbSBZYWhvbyEgPGh0dHA6Ly91cy5yZC55YWhvby5j b20vbWFpbHVrL3RhZ2xpbmVzL2lzcC9jb250cm9sLypodHRwOi91cy5yZC55YWhvby5jb20vZXZ0 PTUxOTQ5LypodHRwOi91ay5kb2NzLnlhaG9vLmNvbS9tYWlsL3dpbnRlcjA3Lmh0bWw+ICAtIGEg c21hcnRlciBpbmJveC4NCg0KIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNClNlbnQgZnJvbSBZYWhvbyEgPGh0dHA6Ly91cy5yZC55YWhvby5jb20vbWFpbHVrL3Rh Z2xpbmVzL2lzcC9jb250cm9sLypodHRwOi91cy5yZC55YWhvby5jb20vZXZ0PTUxOTQ5LypodHRw Oi91ay5kb2NzLnlhaG9vLmNvbS9tYWlsL3dpbnRlcjA3Lmh0bWw+ICAtIGEgc21hcnRlciBpbmJv eC4NCg0KIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClNlbnQg ZnJvbSBZYWhvbyEgPGh0dHA6Ly91cy5yZC55YWhvby5jb20vbWFpbHVrL3RhZ2xpbmVzL2lzcC9j b250cm9sLypodHRwOi91cy5yZC55YWhvby5jb20vZXZ0PTUxOTQ5LypodHRwOi91ay5kb2NzLnlh aG9vLmNvbS9tYWlsL3dpbnRlcjA3Lmh0bWw+ICAtIGEgc21hcnRlciBpbmJveC4NCg0K |
|
From: Steve M. <Ste...@ty...> - 2008-01-25 19:01:17
|
SSBkaWRu4oCZdCBzYXkgaXQgd2FzIHNlYW1sZXNzLCBqdXN0IHRoYXQgaW4gbXkgZXhwZXJpZW5j ZSBpdCBoYXNu4oCZdCBiZWVuIHRvbyBkaWZmaWN1bHQuICAgSSBzdGlsbCB2ZXJ5IG11Y2ggd2Fu dCB0byBzb2x2ZSB0aGUgaXNzdWUgYW5kIGdldCByaWQgb2YgdGhlIHN0cmluZ3MgaW4gYSB3YXkg dGhhdCBwcmVzZXJ2ZXMgdGhlIGZlZWwgb2YgdGhlIGZyYW1ld29yay4NCg0KIA0KDQpGcm9tOiBu bW9jay10d28tZGV2LWJvdW5jZXNAbGlzdHMuc291cmNlZm9yZ2UubmV0IFttYWlsdG86bm1vY2st dHdvLWRldi1ib3VuY2VzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldF0gT24gQmVoYWxmIE9mIERyZXcg Tm9ha2VzDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjUsIDIwMDggMTI6MTYgUE0NClRvOiBOTW9j azIgRGV2ZWxvcG1lbnQgRGlzY3Vzc2lvbg0KU3ViamVjdDogUmU6IFtOTW9jazItRGV2XSBbVXNl ciBhY3Rpb25dIFJlOiBSZWZhY3RvcmFibGUgY2FsbHMNCg0KIA0KDQo+U2luY2UgSSB1c2UgcmVz aGFycGVyLCAgdGhlIHJlZmFjdG9yaW5nIGlzc3VlIGlzIG1vb3QgYmVjYXVzZSByZXNoYXJwZXIg ZWFzaWx5IGRldGVjdHMgdGhlIHN0cmluZ3MgaW4gdGhlIG1vY2sgY2FsbHMgd2hlbiBJIGRvIGEg cmVuYW1lIHJlZmFjdG9yaW5nLg0KDQpJIGFsc28gdXNlIFIjLCBidXQgaXQgZG9lc24ndCBzZWFt bGVzc2x5IGhhbmRsZSByZW5hbWVzIG9mIGNvbW1vbiB0ZXJtcyBpbiBhIGxhcmdlIGNvZGViYXNl Li4uICAiTmFtZSIgZm9yIGV4YW1wbGUuDQoNCkRyZXcuDQoNCiANCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KU2VudCBmcm9tIFlhaG9vISA8aHR0cDovL3VzLnJkLnlhaG9v LmNvbS9tYWlsdWsvdGFnbGluZXMvaXNwL2NvbnRyb2wvKmh0dHA6L3VzLnJkLnlhaG9vLmNvbS9l dnQ9NTE5NDkvKmh0dHA6L3VrLmRvY3MueWFob28uY29tL21haWwvd2ludGVyMDcuaHRtbD4gIC0g YSBzbWFydGVyIGluYm94Lg0KDQo= |
|
From: Drew N. <dre...@ya...> - 2008-01-25 18:15:40
|
>Since I use resharper, the refactoring issue is moot because resharper ea=
sily detects the strings in the mock calls when I do a rename refactoring.=
=0A=0AI also use R#, but it doesn't seamlessly handle renames of common ter=
ms in a large codebase... "Name" for example.=0A=0ADrew.=0A=0A=0A=0A=0A=0A=
___________________________________________________________=0ASupport=
the World Aids Awareness campaign this month with Yahoo! For Good http://u=
k.promotions.yahoo.com/forgood/ |
|
From: Drew N. <dre...@ya...> - 2008-01-25 18:12:19
|
>Your signature is OnProperty(T property) for which I assume you mean OnPro= perty<T>(T property) since the Once item doesn=E2=80=99t have a generic typ= e already associated with it.=0A=0AYou're right. I meant OnProperty<T>(T p= roperty)=0A =0A>Where, in your pattern, does the information about which pr= operty is called gets passed into the system? The call stack will not have= the information you can search for.=0A=0AI tried to explain this in my ori= ginal email and my follow up. The 'Once' member sets the thread into recor= d mode. The next usage of a mock's member on that thread is considered an = expectation. I haven't spent much time working out whether this implicit m= ock state transitioning actually works in a variety of scenarios. For exam= ple if you had code "Expect.Once.ToString()" then you'd leave the thread ha= nging in record mode, but that's not a very likely scenario.=0A=0A>OnProper= ty(()=3D>foo.Prop)=0A>Where the parameter is a lambda expression that you c= an query to discover the identity of =E2=80=98Prop=E2=80=99, but I=E2=80=99= m trying to stay with .NET 2.0 for now.=0A=0AI'm personally quite excited t= o see what mocking opportunities arise from this lambda expression tree app= roach.=0A=0ADrew.=0A=0A =0A=0A=0A=0A =0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0AFrom: Drew Noakes=0A=0A[mailto:dre...@ya...] =0A=0A=0ASent: F= riday, January 25, 2008 3:35 AM=0A=0A=0ATo: Steve Mitcham=0A=0A=0ASubject: = Re: [NMock2-Dev] Refactorable calls=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A =0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A> D= rew: =0A =0A=0A=0A=0A>=0A=0AYour OnProperty method will evaluate to the val= ue of the property, not the=0A=0Aproperty itself and since the property com= es from a Mock you will access it=0A=0Abefore it is defined.=0A =0A=0A=0A= =0A =0A =0A=0A=0A=0AOnProperty does would not care about the property's re= turn=0A=0Avalue. As I said, that would just be default(T). However, at th= e=0A=0Atime that the mock's property getter is called, the framework would = treat the=0A=0Acall as a record, not a playback. The record state is estab= lished during=0A=0Athe Expect.Once getter. I think it's quite likely that = this pattern would=0A=0Awork, at least in most cases.=0A =0A=0A=0A=0A =0A = =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AFrom:=0A=0Anmock-two-dev-bounces@lists.= sourceforge.net=0A=0A[mailto:nmo...@li...] O= n Behalf Of Drew=0A=0ANoakes=0A=0A=0ASent: Thursday, January 24, 2008 11:43= AM=0A=0A=0ATo: NMock2 Development Discussion=0A=0A=0ASubject: Re: [NMock2-= Dev] Refactorable calls=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A =0A = =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A>Expect.Once.On(foo).Setter= .Plonk.With(123);=0A=0A=0A>Expect.Once.On(foo).Getter.Squee.Will(...);=0A= =0A=0A>=0A=0A=0A>where Method, Setter and Getter all return your generated = IFoo?=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AIf Setter & Getter return IFoo= , how can they have the With and Will=0A=0Amembers?=0A=0A=0A=0A=0A=0AProper= ties always have a return type so how about:=0A =0A=0A=0A=0A=0A=0A=0A=0A = =0A=0AExpect.Once.OnProperty(foo.Prop).With(123);=0A=0A=0A Expect.Once.O= nProperty(foo.Prop).Will(Return.Value(123));=0A=0A=0A=0A=0A=0AThe OnPropert= y method would have a signature like this:=0A=0A=0A=0A=0A=0A public IPro= pertyOptions<T> OnProperty(T property);=0A=0A=0A=0A=0A=0AAnd interface IPro= pertyOptions<T> would have members:=0A=0A=0A=0A=0A=0A void With(T expect= edValue);=0A=0A=0A void Will(Action<T> action);=0A=0A=0A=0A=0A=0A...as w= ell as some extra overloads to support matchers.=0A=0A=0A=0A=0A=0AUnfortuna= tely this requires some way to trap the usage of the mock during=0A=0Asetti= ng up of expectations. I believe this might be possible without an=0A=0Aex= plicit record/replay section:=0A=0A=0A=0A=0A=0A Expect.Once.OnProperty(fo= o.Prop).With(123);=0A=0A=0A=0A=0A=0AUnless I'm mistaken, the order of execu= tion here is:=0A=0A=0A=0A=0A=0A1) Expect.Once=0A=0A=0A2) foo.Prop=0A=0A=0A3= ) OnProperty(...)=0A=0A=0A=0A=0A=0ADuring step 1 a flag could be set intern= ally such that the next usage of a mock=0A=0Ais considered a recording. In= step 2 the dynamic property knows it's in=0A=0Arecord mode, so returns def= ault(T), and the recording flag is cleared. =0A=0AFinally, the property's i= dentity is used in step 3. At this point, all=0A=0Aremembered state are cl= eared. As the state is not explicitly passed=0A=0Abetween these pieces of = code it would have to be discoverable, though global=0A=0Astate would mean = no running tests concurrently. Therefore, it makes sense=0A=0Ato associate= any flags/memory to executing thread. This state would need=0A=0Ato be ca= refully considered and tested in other usage scenarios too.=0A=0A=0A=0A=0A= =0AThis is pretty similar to what Rhino.Mocks does I think, though without = the=0A=0Aexplicit record and playback sections. If this design worked it m= ight be=0A=0Aquite nice to work with. If, however, it introduced lots of o= pportunity=0A=0Ato be confused by unexpected behaviour then I would avoid i= t.=0A=0A=0A=0A=0A=0ADrew.=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A =0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0ASent=0A= =0Afrom Yahoo! - a smarter inbox.=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A =0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A =0A =0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0ASent from Yahoo!=0A=0A- a smarter inbox= .=0A =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A ___________________= _______________________________________=0ASent from Yahoo! Mail - a smarter= inbox http://uk.mail.yahoo.com=0A |
|
From: Steve M. <Ste...@ty...> - 2008-01-25 17:50:15
|
It is the chained calls that draw me to the NMock2 interface. I know
that there are only a few entry points to the API for creating mock
actions.
Expect, Fire, Is
Items like Once or Will, that are modifiers to the creation tasks, are
not available on the top level API which helps to lower the learning
curve and make intellisense more useful.
-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Nat
Pryce
Sent: Friday, January 25, 2008 11:36 AM
To: NMock2 Development Discussion
Subject: [Allowed List] Re: [NMock2-Dev] [User action] Re: Refactorable
calls
On 25/01/2008, Steve Mitcham <Ste...@ty...> wrote:
> In your example, broken out, you now have many calls for each
> expectation. There's no fluent interface wrapping these calls, so
their
> logical construction does not flow from intellisense.
It is a Fluent Interface. It's just not defined by chained calls.
> mockA.DoSomething(...);
> Once;
> mockB.GetStuff();
> Will(Return("stuff"));
>
> The questions that immediately come to mind are:
> 1. Does Once apply to the previous or future call?
In jMock 2, the expected count is a method that takes the mock, starts
capturing expectations and returns the mock to be called in capture
mode. After the call to the mock, any calls to will, then, when, etc.
apply to the expectation last captured.
So it should be:
Once (mock).doSomething();
With real closures (e.g. C# delegates), the Checking call can put the
mockery into capture mode, call the delegate, then put the mockery
back into non-capture mode. So that is not necessary and you could
perhaps define the count after the call.
mock.doSomething(); AtLeastOnce(); Will(Return(10));
Ah... I just realised that the delegate has no base class that can
define the syntactic sugar, so it probably won't work after all.
> 2. What is building up the mock state behind the scenes?
The Mockery.
> 3. How does Will know which call to associate with?
It's the last one made.
>
> To me, this would be a major departure from the workflow of NMock as
> opposed to a cleaner syntax of the existing flow.
I originally wrote NMock2 to be as close as possible to the jMock 1
API as C# would allow (plus a few improvements). I thought it would
be nice if NMock 2++ would be as close as possible to jMock 2.
Especially as the jMock 2 API was seen as a big improvement by jMock
users. But there's no real reason for it to be if noone else wants
that.
--Nat
> -----Original Message-----
> From: nmo...@li...
> [mailto:nmo...@li...] On Behalf Of Nat
> Pryce
> Sent: Thursday, January 24, 2008 12:16 PM
> To: NMock2 Development Discussion
> Subject: [User action] Re: [NMock2-Dev] Refactorable calls
>
> On 23/01/2008, Steve Mitcham <Ste...@ty...> wrote:
> > I've looked a jMock's implementation and I've looked at Rhino. I
don't
> > really like the two line setups with the Call/LastCall that is the
> same as
> > the Rhino expectations. I'm trying to think of an 'NMock-like'
> > implementation of the same thing that keeps the fluent interface
> going.
>
> JMock's API was a desperate attempt to work around Java's butt-ugly
> syntax for closures. C# has a cleaner syntax, so you could do
> something like the example below.
>
> A mockA =3D mockery.mock(typeof(A));
> B mockB =3D mockery.mock(typeof(B));
>
> mockery.Checking(delegate {
> mockA.DoSomething(EqualTo(B), NotNull);
> Once; mockB.GetStuff(); Will(Return("stuff"));
> });
>
>
> The Checking method would put the mockery into a "record" state, call
> the delegate, and then put the mockery back into a "check" state.
>
> That would be much easier to implement in C# than Java because C# has
> real generics and closures.
>
> Even better would be something like:
>
> mockery.Checking(delegate {
> ... run the test in here
> }.WillCause(delegate {
> ... expectations in here
> });
>
> Which makes the expectations read more like assertions. It puts the
> tested code and the expectations in causal order, which is easier to
> read I think.
>
> --Nat
>
>
------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> NMock-two-dev mailing list
> NMo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
>
>
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> NMock-two-dev mailing list
> NMo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
>
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NMock-two-dev mailing list
NMo...@li...
https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
|
|
From: Nat P. <nat...@gm...> - 2008-01-25 17:35:50
|
On 25/01/2008, Steve Mitcham <Ste...@ty...> wrote:
> In your example, broken out, you now have many calls for each
> expectation. There's no fluent interface wrapping these calls, so their
> logical construction does not flow from intellisense.
It is a Fluent Interface. It's just not defined by chained calls.
> mockA.DoSomething(...);
> Once;
> mockB.GetStuff();
> Will(Return("stuff"));
>
> The questions that immediately come to mind are:
> 1. Does Once apply to the previous or future call?
In jMock 2, the expected count is a method that takes the mock, starts
capturing expectations and returns the mock to be called in capture
mode. After the call to the mock, any calls to will, then, when, etc.
apply to the expectation last captured.
So it should be:
Once (mock).doSomething();
With real closures (e.g. C# delegates), the Checking call can put the
mockery into capture mode, call the delegate, then put the mockery
back into non-capture mode. So that is not necessary and you could
perhaps define the count after the call.
mock.doSomething(); AtLeastOnce(); Will(Return(10));
Ah... I just realised that the delegate has no base class that can
define the syntactic sugar, so it probably won't work after all.
> 2. What is building up the mock state behind the scenes?
The Mockery.
> 3. How does Will know which call to associate with?
It's the last one made.
>
> To me, this would be a major departure from the workflow of NMock as
> opposed to a cleaner syntax of the existing flow.
I originally wrote NMock2 to be as close as possible to the jMock 1
API as C# would allow (plus a few improvements). I thought it would
be nice if NMock 2++ would be as close as possible to jMock 2.
Especially as the jMock 2 API was seen as a big improvement by jMock
users. But there's no real reason for it to be if noone else wants
that.
--Nat
> -----Original Message-----
> From: nmo...@li...
> [mailto:nmo...@li...] On Behalf Of Nat
> Pryce
> Sent: Thursday, January 24, 2008 12:16 PM
> To: NMock2 Development Discussion
> Subject: [User action] Re: [NMock2-Dev] Refactorable calls
>
> On 23/01/2008, Steve Mitcham <Ste...@ty...> wrote:
> > I've looked a jMock's implementation and I've looked at Rhino. I don't
> > really like the two line setups with the Call/LastCall that is the
> same as
> > the Rhino expectations. I'm trying to think of an 'NMock-like'
> > implementation of the same thing that keeps the fluent interface
> going.
>
> JMock's API was a desperate attempt to work around Java's butt-ugly
> syntax for closures. C# has a cleaner syntax, so you could do
> something like the example below.
>
> A mockA = mockery.mock(typeof(A));
> B mockB = mockery.mock(typeof(B));
>
> mockery.Checking(delegate {
> mockA.DoSomething(EqualTo(B), NotNull);
> Once; mockB.GetStuff(); Will(Return("stuff"));
> });
>
>
> The Checking method would put the mockery into a "record" state, call
> the delegate, and then put the mockery back into a "check" state.
>
> That would be much easier to implement in C# than Java because C# has
> real generics and closures.
>
> Even better would be something like:
>
> mockery.Checking(delegate {
> ... run the test in here
> }.WillCause(delegate {
> ... expectations in here
> });
>
> Which makes the expectations read more like assertions. It puts the
> tested code and the expectations in causal order, which is easier to
> read I think.
>
> --Nat
>
> ------------------------------------------------------------------------
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> NMock-two-dev mailing list
> NMo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> NMock-two-dev mailing list
> NMo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
>
|
|
From: Steve M. <Ste...@ty...> - 2008-01-25 17:01:20
|
I don't see that as cleaner than the current Expect syntax. The biggest
gripe with NMock is not the syntax, but the use of strings that cause
breaks in intellisense and refactoring.
Since I use resharper, the refactoring issue is moot because resharper
easily detects the strings in the mock calls when I do a rename
refactorting.
For intellisense, I get burned on that as well and am sometimes forced
to type up some nonsense code to identify my method.
I don't want to change the feel of NMock2, just find a way to allow the
intellisense to function.
In your example, broken out, you now have many calls for each
expectation. There's no fluent interface wrapping these calls, so their
logical construction does not flow from intellisense.
mockA.DoSomething(...);
Once;
mockB.GetStuff();
Will(Return("stuff"));
The questions that immediately come to mind are:
1. Does Once apply to the previous or future call?
2. What is building up the mock state behind the scenes?
3. How does Will know which call to associate with?
To me, this would be a major departure from the workflow of NMock as
opposed to a cleaner syntax of the existing flow.
-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Nat
Pryce
Sent: Thursday, January 24, 2008 12:16 PM
To: NMock2 Development Discussion
Subject: [User action] Re: [NMock2-Dev] Refactorable calls
On 23/01/2008, Steve Mitcham <Ste...@ty...> wrote:
> I've looked a jMock's implementation and I've looked at Rhino. I don't
> really like the two line setups with the Call/LastCall that is the
same as
> the Rhino expectations. I'm trying to think of an 'NMock-like'
> implementation of the same thing that keeps the fluent interface
going.
JMock's API was a desperate attempt to work around Java's butt-ugly
syntax for closures. C# has a cleaner syntax, so you could do
something like the example below.
A mockA =3D mockery.mock(typeof(A));
B mockB =3D mockery.mock(typeof(B));
mockery.Checking(delegate {
mockA.DoSomething(EqualTo(B), NotNull);
Once; mockB.GetStuff(); Will(Return("stuff"));
});
The Checking method would put the mockery into a "record" state, call
the delegate, and then put the mockery back into a "check" state.
That would be much easier to implement in C# than Java because C# has
real generics and closures.
Even better would be something like:
mockery.Checking(delegate {
... run the test in here
}.WillCause(delegate {
... expectations in here
});
Which makes the expectations read more like assertions. It puts the
tested code and the expectations in causal order, which is easier to
read I think.
--Nat
------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
NMock-two-dev mailing list
NMo...@li...
https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
|
|
From: Steve M. <Ste...@ty...> - 2008-01-25 16:50:19
|
IA0KDQogDQoNCkZyb206IFN0ZXZlIE1pdGNoYW0gDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjUs IDIwMDggODozOSBBTQ0KVG86ICdEcmV3IE5vYWtlcycNClN1YmplY3Q6IFJFOiBbTk1vY2syLURl dl0gUmVmYWN0b3JhYmxlIGNhbGxzDQoNCiANCg0KWW91ciBzaWduYXR1cmUgaXMgT25Qcm9wZXJ0 eShUIHByb3BlcnR5KSBmb3Igd2hpY2ggSSBhc3N1bWUgeW91IG1lYW4gT25Qcm9wZXJ0eTxUPihU IHByb3BlcnR5KSBzaW5jZSB0aGUgT25jZSBpdGVtIGRvZXNu4oCZdCBoYXZlIGEgZ2VuZXJpYyB0 eXBlIGFscmVhZHkgYXNzb2NpYXRlZCB3aXRoIGl0Lg0KDQogDQoNCkxldOKAmXMgYXNzdW1lIGZv by5Qcm9wIGlzIGEgZG91YmxlDQoNCklmIHlvdSBjYWxsOg0KDQogDQoNCkV4cGVjdC5PbmNlLk9u UHJvcGVydHkoZm9vLlByb3ApLlNldHRlcg0KDQogDQoNClQgZm9yIE9uUHJvcGVydHkgd2lsbCBl dmFsdWF0ZSB0byDigJhkb3VibGXigJkNCg0KIA0KDQpPblByb3BlcnR5IHdpbGwgcmVjZWl2ZSB0 aGUgdmFsdWUgb2YgZGVmYXVsdCgpIG9uIGEgZG91YmxlIHdoaWNoIGlzIDAuDQoNCiANCg0KV2hl cmUsIGluIHlvdXIgcGF0dGVybiwgZG9lcyB0aGUgaW5mb3JtYXRpb24gYWJvdXQgd2hpY2ggcHJv cGVydHkgaXMgY2FsbGVkIGdldHMgcGFzc2VkIGludG8gdGhlIHN5c3RlbT8gIFRoZSBjYWxsIHN0 YWNrIHdpbGwgbm90IGhhdmUgdGhlIGluZm9ybWF0aW9uIHlvdSBjYW4gc2VhcmNoIGZvci4NCg0K IA0KDQpJZiB5b3UgaGFkIC5ORVQgMy41LCB5b3UgbWlnaHQgZ2V0IGF3YXkgd2l0aCBzb21ldGhp bmcgbGlrZQ0KDQogDQoNCk9uUHJvcGVydHkoKCk9PmZvby5Qcm9wKQ0KDQogDQoNCldoZXJlIHRo ZSBwYXJhbWV0ZXIgaXMgYSBsYW1iZGEgZXhwcmVzc2lvbiB0aGF0IHlvdSBjYW4gcXVlcnkgdG8g ZGlzY292ZXIgdGhlIGlkZW50aXR5IG9mIOKAmFByb3DigJksIGJ1dCBJ4oCZbSB0cnlpbmcgdG8g c3RheSB3aXRoIC5ORVQgMi4wIGZvciBub3cuDQoNCiANCg0KRnJvbTogRHJldyBOb2FrZXMgW21h aWx0bzpkcmV3bm9ha2VzQHlhaG9vLmNvbS5hdV0gDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjUs IDIwMDggMzozNSBBTQ0KVG86IFN0ZXZlIE1pdGNoYW0NClN1YmplY3Q6IFJlOiBbTk1vY2syLURl dl0gUmVmYWN0b3JhYmxlIGNhbGxzDQoNCiANCg0KPiBEcmV3OiANCg0KPiBZb3VyIE9uUHJvcGVy dHkgbWV0aG9kIHdpbGwgZXZhbHVhdGUgdG8gdGhlIHZhbHVlIG9mIHRoZSBwcm9wZXJ0eSwgbm90 IHRoZSBwcm9wZXJ0eSBpdHNlbGYgYW5kIHNpbmNlIHRoZSBwcm9wZXJ0eSBjb21lcyBmcm9tIGEg TW9jayB5b3Ugd2lsbCBhY2Nlc3MgaXQgYmVmb3JlIGl0IGlzIGRlZmluZWQuDQoNCiANCg0KT25Q cm9wZXJ0eSBkb2VzIHdvdWxkIG5vdCBjYXJlIGFib3V0IHRoZSBwcm9wZXJ0eSdzIHJldHVybiB2 YWx1ZS4gIEFzIEkgc2FpZCwgdGhhdCB3b3VsZCBqdXN0IGJlIGRlZmF1bHQoVCkuICBIb3dldmVy LCBhdCB0aGUgdGltZSB0aGF0IHRoZSBtb2NrJ3MgcHJvcGVydHkgZ2V0dGVyIGlzIGNhbGxlZCwg dGhlIGZyYW1ld29yayB3b3VsZCB0cmVhdCB0aGUgY2FsbCBhcyBhIHJlY29yZCwgbm90IGEgcGxh eWJhY2suICBUaGUgcmVjb3JkIHN0YXRlIGlzIGVzdGFibGlzaGVkIGR1cmluZyB0aGUgRXhwZWN0 Lk9uY2UgZ2V0dGVyLiAgSSB0aGluayBpdCdzIHF1aXRlIGxpa2VseSB0aGF0IHRoaXMgcGF0dGVy biB3b3VsZCB3b3JrLCBhdCBsZWFzdCBpbiBtb3N0IGNhc2VzLg0KDQogDQoNCkZyb206IG5tb2Nr LXR3by1kZXYtYm91bmNlc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgW21haWx0bzpubW9jay10d28t ZGV2LWJvdW5jZXNAbGlzdHMuc291cmNlZm9yZ2UubmV0XSBPbiBCZWhhbGYgT2YgRHJldyBOb2Fr ZXMNClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI0LCAyMDA4IDExOjQzIEFNDQpUbzogTk1vY2sy IERldmVsb3BtZW50IERpc2N1c3Npb24NClN1YmplY3Q6IFJlOiBbTk1vY2syLURldl0gUmVmYWN0 b3JhYmxlIGNhbGxzDQoNCiANCg0KPkV4cGVjdC5PbmNlLk9uKGZvbykuU2V0dGVyLlBsb25rLldp dGgoMTIzKTsNCj5FeHBlY3QuT25jZS5Pbihmb28pLkdldHRlci5TcXVlZS5XaWxsKC4uLik7DQo+ DQo+d2hlcmUgTWV0aG9kLCBTZXR0ZXIgYW5kIEdldHRlciBhbGwgcmV0dXJuIHlvdXIgZ2VuZXJh dGVkIElGb28/DQoNCg0KSWYgU2V0dGVyICYgR2V0dGVyIHJldHVybiBJRm9vLCBob3cgY2FuIHRo ZXkgaGF2ZSB0aGUgV2l0aCBhbmQgV2lsbCBtZW1iZXJzPw0KDQpQcm9wZXJ0aWVzIGFsd2F5cyBo YXZlIGEgcmV0dXJuIHR5cGUgc28gaG93IGFib3V0Og0KDQogICAgRXhwZWN0Lk9uY2UuT25Qcm9w ZXJ0eShmb28uUHJvcCkuV2l0aCgxMjMpOw0KICAgIEV4cGVjdC5PbmNlLk9uUHJvcGVydHkoZm9v LlByb3ApLldpbGwoUmV0dXJuLlZhbHVlKDEyMykpOw0KDQpUaGUgT25Qcm9wZXJ0eSBtZXRob2Qg d291bGQgaGF2ZSBhIHNpZ25hdHVyZSBsaWtlIHRoaXM6DQoNCiAgICBwdWJsaWMgSVByb3BlcnR5 T3B0aW9uczxUPiBPblByb3BlcnR5KFQgcHJvcGVydHkpOw0KDQpBbmQgaW50ZXJmYWNlIElQcm9w ZXJ0eU9wdGlvbnM8VD4gd291bGQgaGF2ZSBtZW1iZXJzOg0KDQogICAgdm9pZCBXaXRoKFQgZXhw ZWN0ZWRWYWx1ZSk7DQogICAgdm9pZCBXaWxsKEFjdGlvbjxUPiBhY3Rpb24pOw0KDQouLi5hcyB3 ZWxsIGFzIHNvbWUgZXh0cmEgb3ZlcmxvYWRzIHRvIHN1cHBvcnQgbWF0Y2hlcnMuDQoNClVuZm9y dHVuYXRlbHkgdGhpcyByZXF1aXJlcyBzb21lIHdheSB0byB0cmFwIHRoZSB1c2FnZSBvZiB0aGUg bW9jayBkdXJpbmcgc2V0dGluZyB1cCBvZiBleHBlY3RhdGlvbnMuICBJIGJlbGlldmUgdGhpcyBt aWdodCBiZSBwb3NzaWJsZSB3aXRob3V0IGFuIGV4cGxpY2l0IHJlY29yZC9yZXBsYXkgc2VjdGlv bjoNCg0KICAgRXhwZWN0Lk9uY2UuT25Qcm9wZXJ0eShmb28uUHJvcCkuV2l0aCgxMjMpOw0KDQpV bmxlc3MgSSdtIG1pc3Rha2VuLCB0aGUgb3JkZXIgb2YgZXhlY3V0aW9uIGhlcmUgaXM6DQoNCjEp IEV4cGVjdC5PbmNlDQoyKSBmb28uUHJvcA0KMykgT25Qcm9wZXJ0eSguLi4pDQoNCkR1cmluZyBz dGVwIDEgYSBmbGFnIGNvdWxkIGJlIHNldCBpbnRlcm5hbGx5IHN1Y2ggdGhhdCB0aGUgbmV4dCB1 c2FnZSBvZiBhIG1vY2sgaXMgY29uc2lkZXJlZCBhIHJlY29yZGluZy4gIEluIHN0ZXAgMiB0aGUg ZHluYW1pYyBwcm9wZXJ0eSBrbm93cyBpdCdzIGluIHJlY29yZCBtb2RlLCBzbyByZXR1cm5zIGRl ZmF1bHQoVCksIGFuZCB0aGUgcmVjb3JkaW5nIGZsYWcgaXMgY2xlYXJlZC4gIEZpbmFsbHksIHRo ZSBwcm9wZXJ0eSdzIGlkZW50aXR5IGlzIHVzZWQgaW4gc3RlcCAzLiAgQXQgdGhpcyBwb2ludCwg YWxsIHJlbWVtYmVyZWQgc3RhdGUgYXJlIGNsZWFyZWQuICBBcyB0aGUgc3RhdGUgaXMgbm90IGV4 cGxpY2l0bHkgcGFzc2VkIGJldHdlZW4gdGhlc2UgcGllY2VzIG9mIGNvZGUgaXQgd291bGQgaGF2 ZSB0byBiZSBkaXNjb3ZlcmFibGUsIHRob3VnaCBnbG9iYWwgc3RhdGUgd291bGQgbWVhbiBubyBy dW5uaW5nIHRlc3RzIGNvbmN1cnJlbnRseS4gIFRoZXJlZm9yZSwgaXQgbWFrZXMgc2Vuc2UgdG8g YXNzb2NpYXRlIGFueSBmbGFncy9tZW1vcnkgdG8gZXhlY3V0aW5nIHRocmVhZC4gIFRoaXMgc3Rh dGUgd291bGQgbmVlZCB0byBiZSBjYXJlZnVsbHkgY29uc2lkZXJlZCBhbmQgdGVzdGVkIGluIG90 aGVyIHVzYWdlIHNjZW5hcmlvcyB0b28uDQoNClRoaXMgaXMgcHJldHR5IHNpbWlsYXIgdG8gd2hh dCBSaGluby5Nb2NrcyBkb2VzIEkgdGhpbmssIHRob3VnaCB3aXRob3V0IHRoZSBleHBsaWNpdCBy ZWNvcmQgYW5kIHBsYXliYWNrIHNlY3Rpb25zLiAgSWYgdGhpcyBkZXNpZ24gd29ya2VkIGl0IG1p Z2h0IGJlIHF1aXRlIG5pY2UgdG8gd29yayB3aXRoLiAgSWYsIGhvd2V2ZXIsIGl0IGludHJvZHVj ZWQgbG90cyBvZiBvcHBvcnR1bml0eSB0byBiZSBjb25mdXNlZCBieSB1bmV4cGVjdGVkIGJlaGF2 aW91ciB0aGVuIEkgd291bGQgYXZvaWQgaXQuDQoNCkRyZXcuDQoNCiANCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCg0KU2VudCBmcm9tIFlhaG9vISA8aHR0cDovL3VzLnJkLnlh aG9vLmNvbS9tYWlsdWsvdGFnbGluZXMvaXNwL2NvbnRyb2wvKmh0dHA6L3VzLnJkLnlhaG9vLmNv bS9ldnQ9NTE5NDkvKmh0dHA6L3VrLmRvY3MueWFob28uY29tL21haWwvd2ludGVyMDcuaHRtbD4g IC0gYSBzbWFydGVyIGluYm94Lg0KDQogDQoNCiANCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KU2VudCBmcm9tIFlhaG9vISA8aHR0cDovL3VzLnJkLnlhaG9vLmNvbS9tYWls dWsvdGFnbGluZXMvaXNwL2NvbnRyb2wvKmh0dHA6L3VzLnJkLnlhaG9vLmNvbS9ldnQ9NTE5NDkv Kmh0dHA6L3VrLmRvY3MueWFob28uY29tL21haWwvd2ludGVyMDcuaHRtbD4gIC0gYSBzbWFydGVy IGluYm94Lg0KDQo= |
|
From: Steve M. <Ste...@ty...> - 2008-01-24 21:40:13
|
There were some discussions with lambda expressions for the mock expressions. This is being done in moq (mock linq) which is a new mocking framework in infancy. I don't have a link for that immediately available. While I'm excited at those types of extensions, I still want to improve the 2.0 experience because in my day job I'm stuck with 2.0 for the foreseeable future. -----Original Message----- From: nmo...@li... [mailto:nmo...@li...] On Behalf Of Mike Capp Sent: Thursday, January 24, 2008 2:31 PM To: NMock2 Development Discussion Subject: [Allowed List] Re: [NMock2-Dev] Refactorable calls On 24/01/2008, Steve Mitcham <Ste...@ty...> wrote: > Mike: As mentioned below, I'm looking at a .NET 2.0 solution currently. I > imagine that we might be able to do more with extension methods, but > currently there is no way to 'extend' the actual interface to have Will and > With after the properties are identified. Much as I appreciate the charitable interpretation, that really _was_ just me being tired and stupid. You're right, it's a messy problem. It feels as if there really ought to be a solution passing a delegate to On, giving you the target and method in one swell foop, but at least in .NET 2.0 I can't see any way to make this work without unacceptable quantities of delegate signature declarations and/or type-parameter cruft. ------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ NMock-two-dev mailing list NMo...@li... https://lists.sourceforge.net/lists/listinfo/nmock-two-dev |
|
From: Mike C. <mik...@gm...> - 2008-01-24 20:30:58
|
On 24/01/2008, Steve Mitcham <Ste...@ty...> wrote: > Mike: As mentioned below, I'm looking at a .NET 2.0 solution currently. I > imagine that we might be able to do more with extension methods, but > currently there is no way to 'extend' the actual interface to have Will and > With after the properties are identified. Much as I appreciate the charitable interpretation, that really _was_ just me being tired and stupid. You're right, it's a messy problem. It feels as if there really ought to be a solution passing a delegate to On, giving you the target and method in one swell foop, but at least in .NET 2.0 I can't see any way to make this work without unacceptable quantities of delegate signature declarations and/or type-parameter cruft. |
9 messages has been excluded from this view by a project administrator.
