nmock-two-dev — Discussion of development of NMock 2

Re: [NMock2-Dev] CVS SVN and .NET 3.5

[<aci...@ac...>]

> 2.       We need to designate someone to act as the official builder and
> produce a new build one all the bugs we want fixed are fixed.

I would be willing to take on that responsibility.

>
> 3.       We need to update the website information to reflect the new
> syntax of the event model.
>

I don't know how the new event model works so that wouldn't be a good fit
for me.

>
> Following that,  we need to produce a roadmap to the next version, the
> open areas of discussion that I've seen are
>
> 1.       .NET 3.5 support with new syntax
>
> 2.       Replacing the TransparentProxy with Castle.Dynamic proxy or
> some other full featured proxy.

I would like to add, dropping .NET 1.0/1.1. And moving to use generics
internally.

-Richard Holden

Re: [NMock2-Dev] CVS SVN and .NET 3.5

[Andrey S. <as...@gm...>]

On 10/12/07, aci...@ac... <aci...@ac...> wrote:
> On Fri, October 12, 2007 8:55 am, Steve Mitcham wrote:
> Bug #: 1740285
> Title: NMock don't work with interfaces with visiblity internal
> NMock2?: Yes
> Proposed Resolution: Need more validation, though I don't believe this is
> something that should be fixed, as it would bypass the CLR's accessibility
> protections, and possibly the original developers intentions.

Internal interfaces are definitely mockable in .Net 2.0:
http://blog.ashmind.com/index.php/2007/07/07/mocking-internal-interfaces-with-nmock2/

Re: [NMock2-Dev] CVS SVN and .NET 3.5

[<aci...@ac...>]

On Fri, October 12, 2007 8:55 am, Steve Mitcham wrote:

> What I am more concerned about right now is the following:
>
> 1.       We need to clean up the bug database, if we don't decide to
> move the project, and determine which bugs are actually NMock2 and need
> to be fixed and close out the rest.  From this perspective, a distinct
> break from the old NMock stuff by rehosting might be beneficial, but
> certainly not needed.

I actually spent a few hours on that last night. Not compeletely done but
close. Working from the bottom up.

Bug #: 774453
Title: removing get_ and set_
NMock2?: No
Proposed Resolution: Closed, Works for Me

Bug #: 774463
Title: wrong error generated
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #: 877644
Title: Cannot mock classes whose constructors call virtual methods
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #:877644
Title: Cannot mock classes whose constructors call virtual methods
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #: 1016006
Title: Support classes that do not have parameterless constructors
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #: 1017570
Title: You can't mock classes that inherit from UserControl
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #: 1019003
Title: Ignore does not work if the method is called from constr
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #: 1049495
Title: Mock object can violate type safety
NMock2?: Sort of (Already Fixed)
Proposed Resolution: Closed, Fixed

Bug #: 1085841
Title: ExpectedAndReturn with OutArgs don't work
NMock2?: Sort of (I believe this is already working in NMock2)
Proposed Resolution: Closed, Won't Fix

Bug #: 1119766
Title: Mocked implementations of virtuals don't call base class!!
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #: 1182110
Title: Expect of properties of a class does not work
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #: 1314660
Title: Overloaded methods causes TypeLoad exceptions
NMock2?: No
Proposed Resolution: Closed, Won't Fix

Bug #: 1521702
Title: Nullable types do not work in nmock 2.0
NMock2?: Yes
Proposed Resolution: Merge patch, then mark Closed, Fixed

Bug #: 1525583
Title: NMock2: Mock object can't be passed as an object parameter
NMock2?: Yes
Proposed Resolution: Not sure, Steve, comments on the bug say you have a
patch that fixes it, is this already in CVS?

Bug #: 1528423
Title: Multiple calls to Stub
NMock2?: Yes
Proposed Resolution: Leave open, I have investigated the bug and will add
my comments to the bug report, I didn't do it last night because I
finished up the investigation about midnight.

Bug #: 1694575
Title: Mock object type does not return the implementing interface
NMock2?: Yes
Proposed Resolution: Closed, Works for me (Based on CVS checkout)

Bug #: 1736091
Title: internal try/catches can mask error states
NMock2?: Yes
Proposed Resolution: Leave open, needs unit test and bug fix.

Bug #: 1740285
Title: NMock don't work with interfaces with visiblity internal
NMock2?: Yes
Proposed Resolution: Need more validation, though I don't believe this is
something that should be fixed, as it would bypass the CLR's accessibility
protections, and possibly the original developers intentions.

Bug #: 1740548
Title: using (mocks.Ordered) behavior
NMock2?: Yes
Proposed Resolution: Closed, Fixed (Fixed in Current CVS)

I add my comments on the rest of the pieces in a separate email.

-Richard Holden

[NMock2-Dev] CVS SVN and .NET 3.5

[Steve M. <Ste...@ty...>]

Sorry, I accidentally deleted the thread for this, so I don't have the
original to respond to.

=20

I am not having issues with the current hosting, so I don't see any
reason to change the version control at this time just for the sake of
change.  I've already got CVS and SVN loaded for other purposes and I
imagine that a lot of other developers already do as well.  That being
said, I do think that dealing with SVN is easier than CVS for me
personally. I haven't dealt with Codeplex directly yet, so I can't
comment on that.

=20

As for the .NET 3.5 stuff, I've mentioned similar desires a few months
ago, although I've not had the time to flesh them out.  I also didn't
find out about the () =3D> style of lambas until recently.  We should
definitely begin pursuing this in a 3.5 branch.

=20

What I am more concerned about right now is the following:

1.       We need to clean up the bug database, if we don't decide to
move the project, and determine which bugs are actually NMock2 and need
to be fixed and close out the rest.  From this perspective, a distinct
break from the old NMock stuff by rehosting might be beneficial, but
certainly not needed.

2.       We need to designate someone to act as the official builder and
produce a new build one all the bugs we want fixed are fixed.

3.       We need to update the website information to reflect the new
syntax of the event model.

=20

Following that,  we need to produce a roadmap to the next version, the
open areas of discussion that I've seen are

1.       .NET 3.5 support with new syntax

2.       Replacing the TransparentProxy with Castle.Dynamic proxy or
some other full featured proxy.

=20

=20

Re: [NMock2-Dev] Using Google Code/CodePlex + thoughts on NMock 3.5

[Andrey S. <as...@gm...>]

On 10/10/07, Nat Pryce <nat...@gm...> wrote:
> On 10/10/2007, Andrey Shchekin <as...@gm...> wrote:
> > CVS feels like a major obstacle to contribution.
>
> Why?  I can see that Hg or Bzr would be a big benefit when it comes to
> building a community, but is SVN such a big win over CVS that CVS
> stops people contributing?

Of course, I can not speak for other people.
But most of interesting developers I know already have SVN, and
installing CVS is just extra work and a strong feeling that something
is outdated about a project.

On CodePlex, SVN support is the most user-wanted feature -- and TFS is
way more advanced than CVS and has better integration with VS.

> > Also, I have several ideas about NMock considering .Net 3.5.
> > I wrote a short post on it here:
> > http://blog.ashmind.com/index.php/2007/09/23/nmock-35
> >
> > In two words, having expression trees we can make expectations much
> > more concise, like:
> > Expect.Once
> >     .That(() => fs.GetDirectories(path))
> >     .Will(Return.Value(directories));
>
> That looks cool.
>
> --Nat
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> NMock-two-dev mailing list
> NMo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-two-dev
>

Re: [NMock2-Dev] Using Google Code/CodePlex + thoughts on NMock 3.5

[Nat P. <nat...@gm...>]

On 10/10/2007, Andrey Shchekin <as...@gm...> wrote:
> CVS feels like a major obstacle to contribution.

Why?  I can see that Hg or Bzr would be a big benefit when it comes to
building a community, but is SVN such a big win over CVS that CVS
stops people contributing?

> Also, I have several ideas about NMock considering .Net 3.5.
> I wrote a short post on it here:
> http://blog.ashmind.com/index.php/2007/09/23/nmock-35
>
> In two words, having expression trees we can make expectations much
> more concise, like:
> Expect.Once
>     .That(() => fs.GetDirectories(path))
>     .Will(Return.Value(directories));

That looks cool.

--Nat

[NMock2-Dev] Using Google Code/CodePlex + thoughts on NMock 3.5

[Andrey S. <as...@gm...>]

Hello everybody.

What do you think about changing the repository/project location to
something like CodePlex or Google Code?
Or, at least, to SVN repository on SourceForge?

CVS feels like a major obstacle to contribution.

Also, mailing-list-only discussion is somewhat scary due to required
subscription and large amount of mail to read through.
Forums would be faster and nicer.

Also, I have several ideas about NMock considering .Net 3.5.
I wrote a short post on it here:
http://blog.ashmind.com/index.php/2007/09/23/nmock-35

In two words, having expression trees we can make expectations much
more concise, like:
Expect.Once
    .That(() => fs.GetDirectories(path))
    .Will(Return.Value(directories));

I think it would be interesting to do a branch targeted to NetFx 3.5.

Andrey Shchekin

[NMock2-Dev] Changing email address

[Richard H. <Ric...@qu...>]

Just as an update I am changing my email address from this one to =
aci...@ac....
-Richard Holden
Quest Software

The people and products of Vintela are now a part of Quest Software.
Read the press release to learn more.

Re: [NMock2-Dev] Patch for [1521702 ] Nullable types do not work innmock 2.0

[Steve M. <Ste...@ty...>]

I added the test case to the solution and it doesn't cause a failure.
Can someone else check this?=20

=20

From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of
Richard Holden
Sent: Thursday, September 27, 2007 1:17 AM
To: nmo...@li...
Cc: cod...@vi...
Subject: [NMock2-Dev] Patch for [1521702 ] Nullable types do not work
innmock 2.0

=20

This patch includes a test and code mod for Invocation.cs to handle
Nullable types correctly, the patch is against current CVS and can be
applied from the src directory.

-Richard Holden
Quest Software

The people and products of Vintela are now a part of Quest Software.
Read the press release to learn more.

Re: [NMock2-Dev] Patch for [1521702 ] Nullable types do not work innmock 2.0

[Steve M. <Ste...@ty...>]

I'm not sure that this patch preserves the semantics of the line it is
replacing.  I'll work on getting the test case running today.

=20

From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of
Richard Holden
Sent: Thursday, September 27, 2007 1:17 AM
To: nmo...@li...
Cc: cod...@vi...
Subject: [NMock2-Dev] Patch for [1521702 ] Nullable types do not work
innmock 2.0

=20

This patch includes a test and code mod for Invocation.cs to handle
Nullable types correctly, the patch is against current CVS and can be
applied from the src directory.

-Richard Holden
Quest Software

The people and products of Vintela are now a part of Quest Software.
Read the press release to learn more.

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[<rdr...@ar...>]

Currently my tests are not brittle... I was explaining the the missing ability to override an existing stub would make the tests more brittle. 

I finally gave in and will "reverse the setup", but i still feel its odd...  and it will cause me to add "extra" initialisation code into my test methods... (Which was hidden inside the [setup] before, since it was unimportant to the test)

I feel if JMock had the ability to override, and the sequence in which the expections are evaluated is reversed, then there is a feature that has been removed... Its a feature I expected so naturally, i was quite confused when it was not there...

Dont get me wrong though... I love NMock and enjoy using it... Or else i wouldnt complain ;)

----- Original Nachricht ----
Von:     Nat Pryce <nat...@gm...>
An:      NMock2 Development Discussion <nmo...@li...>
Datum:   12.09.2007 21:44
Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have alower
	prioritythen "Expect"

> One thing that might be worth investigating is why the tests are so
> brittle.  Why does a change to a class (adding a new event) cause many
> tests that are testing other aspects of that class to fail.  Maybe
> events can be split up somehow and tested separately.
> 
> --Nat
> 
> On 12/09/2007, rdr...@ar... <rdr...@ar...> wrote:
> > The problem still remains...
> >
> > I would have to do a lot more "Copy&Paste" inheritance if i am unable to
> override a speccific setup. For a simple view with 5 Events i would have to
> create 5 different setup functions, which would all differe in one line. And
> there is no way to refactor this out.
> >
> > Thats 25 (n^2) Lines of mock setup vs 10 (2 * n) lines... and the number
> only gets bigger for more events. The code is not complex, but it leads to
> maintenance problems if there is a change...
> >
> > If I want to add another event to the view, this would cause no less then
> 5 failed tests, and force me to update 5 Setup-functions, and create a new
> one from scratch (by Copy and Paste). on the other Version I would only have
> to update the generic setup function, and then add one event in my
> test-method... (or use the hack which I find ugly...)
> >
> > I like my testcases very short and simple... I usualy feel bad when they
> reach 10 lines, since I consider that to complex...
> >
> > Hope this makes sense...
> >
> > Heiko

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[Nat P. <nat...@gm...>]

One thing that might be worth investigating is why the tests are so
brittle.  Why does a change to a class (adding a new event) cause many
tests that are testing other aspects of that class to fail.  Maybe
events can be split up somehow and tested separately.

--Nat

On 12/09/2007, rdr...@ar... <rdr...@ar...> wrote:
> The problem still remains...
>
> I would have to do a lot more "Copy&Paste" inheritance if i am unable to override a speccific setup. For a simple view with 5 Events i would have to create 5 different setup functions, which would all differe in one line. And there is no way to refactor this out.
>
> Thats 25 (n^2) Lines of mock setup vs 10 (2 * n) lines... and the number only gets bigger for more events. The code is not complex, but it leads to maintenance problems if there is a change...
>
> If I want to add another event to the view, this would cause no less then 5 failed tests, and force me to update 5 Setup-functions, and create a new one from scratch (by Copy and Paste). on the other Version I would only have to update the generic setup function, and then add one event in my test-method... (or use the hack which I find ugly...)
>
> I like my testcases very short and simple... I usualy feel bad when they reach 10 lines, since I consider that to complex...
>
> Hope this makes sense...
>
> Heiko
>
>
> ----- Original Nachricht ----
> Von:     Steve Freeman <st...@m3...>
> An:      NMock2 Development Discussion <nmo...@li...>
> Datum:   12.09.2007 14:53
> Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have
>         alower  prioritythen "Expect"
>
> > This still feels like the wrong solution. We went round this loop a
> > while ago and it just didn't work.
> >
> > You might also consider having more than one test case (they don't
> > have to be one-to-one with classes) to manage different combinations.
> >
> > S.
> >
> > On 11 Sep 2007, at 23:50, rdr...@ar... wrote:
> > >  That would be a bahavior which would fix my "problem".
> > >
> > > Maybe enable a flag in the mockery which defines the "search order"
> > > for the expectations?
> > >
> > > I would find this behavior much more logical then the other way
> > > around. Without it i have no way to override something i setup once
> > > without resulting to "trickery" (e.g. defining something that i
> > > consider a stub to be an expect.once so i can "remove" it with the
> > > exact call)
> > >
> ---(SNIP)---
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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
>

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[Heiko H. <rdr...@gm...>]

I know its a small issue and nothing ground breaking ;)

Guess ill move my stubbing to the end of the testfixtures... The advantage I saw in stubbing inside a [Setup] is that you can remove the code thats not relevant for the test from the test. If I do it the other way around (stub after setting up my expectations), then many test will contain "useless" information, which I would have prefered to hide away so the linecount of testmethods keeps lower... Ok... I can refactor the expectations out and call the stubbing there... Like I said above... Its not a big issue... but I really would have liked a way to override a stub, once I have declared it. 

Guess its just my way of thinking here ;)


-------- Original-Nachricht --------
> Datum: Wed, 12 Sep 2007 19:18:13 +0100
> Von: "Mike Capp" <mik...@gm...>
> An: "NMock2 Development Discussion" <nmo...@li...>
> Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have alower	prioritythen "Expect"

> I may be missing something, but I don't quite see why this is a big
> deal. In your situation I'd do essentially the same thing Mike Mason
> suggested - assign the mock in SetUp , do your Stubbing in a helper
> method called at the start of each test that needs it, and Expect as
> needed _before_ calling that helper.
> 
> If it's really only a tiny minority of tests that need the special
> behavior and you don't like the helper calls in every test, call the
> helper from SetUp and reassign the mock before customizing it.
> 
> - Mike
> 
> On 12/09/2007, rdr...@ar... <rdr...@ar...> wrote:
> >
> > I would have to do a lot more "Copy&Paste" inheritance if i am unable to
> override a speccific setup. For a simple view with 5 Events i would have
> to create 5 different setup functions, which would all differe in one line.
> And there is no way to refactor this out.
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[Mike C. <mik...@gm...>]

I may be missing something, but I don't quite see why this is a big
deal. In your situation I'd do essentially the same thing Mike Mason
suggested - assign the mock in SetUp , do your Stubbing in a helper
method called at the start of each test that needs it, and Expect as
needed _before_ calling that helper.

If it's really only a tiny minority of tests that need the special
behavior and you don't like the helper calls in every test, call the
helper from SetUp and reassign the mock before customizing it.

- Mike

On 12/09/2007, rdr...@ar... <rdr...@ar...> wrote:
>
> I would have to do a lot more "Copy&Paste" inheritance if i am unable to override a speccific setup. For a simple view with 5 Events i would have to create 5 different setup functions, which would all differe in one line. And there is no way to refactor this out.

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[<rdr...@ar...>]

The problem still remains...

I would have to do a lot more "Copy&Paste" inheritance if i am unable to override a speccific setup. For a simple view with 5 Events i would have to create 5 different setup functions, which would all differe in one line. And there is no way to refactor this out. 

Thats 25 (n^2) Lines of mock setup vs 10 (2 * n) lines... and the number only gets bigger for more events. The code is not complex, but it leads to maintenance problems if there is a change... 

If I want to add another event to the view, this would cause no less then 5 failed tests, and force me to update 5 Setup-functions, and create a new one from scratch (by Copy and Paste). on the other Version I would only have to update the generic setup function, and then add one event in my test-method... (or use the hack which I find ugly...)

I like my testcases very short and simple... I usualy feel bad when they reach 10 lines, since I consider that to complex...

Hope this makes sense...

Heiko


----- Original Nachricht ----
Von:     Steve Freeman <st...@m3...>
An:      NMock2 Development Discussion <nmo...@li...>
Datum:   12.09.2007 14:53
Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have
	alower	prioritythen "Expect"

> This still feels like the wrong solution. We went round this loop a  
> while ago and it just didn't work.
> 
> You might also consider having more than one test case (they don't  
> have to be one-to-one with classes) to manage different combinations.
> 
> S.
> 
> On 11 Sep 2007, at 23:50, rdr...@ar... wrote:
> >  That would be a bahavior which would fix my "problem".
> >
> > Maybe enable a flag in the mockery which defines the "search order"  
> > for the expectations?
> >
> > I would find this behavior much more logical then the other way  
> > around. Without it i have no way to override something i setup once  
> > without resulting to "trickery" (e.g. defining something that i  
> > consider a stub to be an expect.once so i can "remove" it with the  
> > exact call)
> >
---(SNIP)---
> 

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[Nat P. <nat...@gm...>]

On 12/09/2007, Mike Mason <mg...@es...> wrote:
> Personally I've mostly stopped testing presenters -- tests thats essentially
> say "presenter should copy data from view to business logic method" aren't
> that useful, and my presenters tend to be pretty small.

I now mostly implement presenters as reflective mappings.  Similarly
to how an object/relational mapper maps objects to/from a relational
database, my presenters (object/view mappers?) map objects to/from GUI
components.

Those are not boilerplate code and are covered by a lot of unit tests
as well as the end-to-end tests.

--Nat

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[Mike M. <mg...@es...>]

Oops. Apparently tab-enter sends emails. What I meant was

[Test]
PresenterSetsMessage {
  Expect.Once.On(view).SetProperty("Message").To("Order saved");
  StubStuffOnView();
  presenter.DoSomething();
}

void StubStuffOnView() {
  Stub.On(view).SetProperty("Message");
  Stub.On(view).GetProperty("someProp");
  Stub.On(view).GetProperty("somethingElse");
}

Because a stub that isn't called won't fail your test, this kind of
arrangement works. If you don't do this, all your presenter tests will need
to expect or stub a whole different range of stuff and become quickly
unreadable.

Personally I've mostly stopped testing presenters -- tests thats essentially
say "presenter should copy data from view to business logic method" aren't
that useful, and my presenters tend to be pretty small.

Hope this helps.

Mike.

On 9/12/07, Mike Mason <mg...@es...> wrote:
>
> Also in NMock, you can set up your expectations first and then stub
> everything afterwards. So something like
>
> [Test]
> PresenterShouldSetImportantMessageOnView() {
>
>

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[Mike M. <mg...@es...>]

Also in NMock, you can set up your expectations first and then stub
everything afterwards. So something like

[Test]
PresenterShouldSetImportantMessageOnView() {

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

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

This still feels like the wrong solution. We went round this loop a  
while ago and it just didn't work.

You might also consider having more than one test case (they don't  
have to be one-to-one with classes) to manage different combinations.

S.

On 11 Sep 2007, at 23:50, rdr...@ar... wrote:
>  That would be a bahavior which would fix my "problem".
>
> Maybe enable a flag in the mockery which defines the "search order"  
> for the expectations?
>
> I would find this behavior much more logical then the other way  
> around. Without it i have no way to override something i setup once  
> without resulting to "trickery" (e.g. defining something that i  
> consider a stub to be an expect.once so i can "remove" it with the  
> exact call)
>
> So instead of having my generic setup which creates everything  
> thats not important for my test "outside" the test function, and  
> only setting one expectation i am actually currently testing inside  
> of my test.  And usually this leads to a buch of helper setup  
> functions, which usually only differ in one line, and its not  
> trivial to refactor the other N lines out... Since the other n-1  
> functions would all differ in one different line...
>
> Also i want to avoid and "logic" in my tests/setups... so a  
> function with a flag to skip one of those lines also leaves a bad  
> feeling...
>
> Anyway... short conclusion: 2 Thumbs up for a flag that defines the  
> search direction ;)

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

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[<rdr...@ar...>]

 That would be a bahavior which would fix my "problem".

Maybe enable a flag in the mockery which defines the "search order" for the=
 expectations?

I would find this behavior much more logical then the other way around. Wit=
hout it i have no way to override something i setup once without resulting =
to "trickery" (e.g. defining something that i consider a stub to be an expe=
ct.once so i can "remove" it with the exact call) =20

So instead of having my generic setup which creates everything thats not im=
portant for my test "outside" the test function, and only setting one expec=
tation i am actually currently testing inside of my test.  And usually this=
 leads to a buch of helper setup functions, which usually only differ in on=
e line, and its not trivial to refactor the other N lines out... Since the =
other n-1 functions would all differ in one different line...

Also i want to avoid and "logic" in my tests/setups... so a function with a=
 flag to skip one of those lines also leaves a bad feeling...=20

Anyway... short conclusion: 2 Thumbs up for a flag that defines the search =
direction ;)



----- Original Nachricht ----
Von:     Nat Pryce <nat...@gm...>
An:      NMock2 Development Discussion <nmo...@li...=
>
Datum:   11.09.2007 21:31
Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have alower
=09prioritythen "Expect"

> JMock used to check expectations in reverse order so you could set up
> some default expectations (stubs usually) and then override them in
> individual tests.  However, it was so confusing to users that we
> removed the feature and just check for expectation matches in the
> order that they are defined.
>=20
> We found that tests were far more readable if set-up was factored out
> into well-named methods called at the start of tests as appropriate
> than to define expectations in the SetUp method.
>=20
> --Nat
>=20
> On 11/09/2007, Steve Mitcham <Ste...@ty...> wrote:
> > It's not a matter of priority, the design philosophy is such that NMock=
 is
> expecting either a Stub or an Expectation, but not both.  Stub is just
> another expectation internally, so if it is first in the list it will mat=
ch
> all comers.
> >
> > I could see having an explicit
> Expect.Once.On(foo).ReplacingExistingExpectations.SetProperty("Id");
> >
> > Which could find and clear all the existing expectations and replace it
> for that test case; however, I don't think I'd want to add in an implicit
> 'override' behavior between expectations.
> >
> > That's my opinion of course,  if anyone else wants to chime in on this,
> please do.
> >
> > Nat, if you see this can you comment about the original nmock behavior =
for
> this case,  were you able to set up a default and then override it for
> specific tests?
> >
> > -----Original Message-----
> > From: nmo...@li...
> [mailto:nmo...@li...] On Behalf Of Heiko
> Hatzfeld
> > Sent: Tuesday, September 11, 2007 9:07 AM
> > To: NMock2 Development Discussion
> > Subject: Re: [NMock2-Dev] Feature Request: "Stub" should have alower
> prioritythen "Expect"
> >
> > Hello...
> >
> > Lets ignore the more complicated event code for a second, and get to th=
e
> "real problem" 1st...
> >
> > IDbObject foo =3D _mocks.NewMock<IDbObject>();
> > Stub.On(foo).SetProperty("Id");
> > Expect.Once.On(foo).SetProperty("Id");
> > foo.Id =3D 123;
> > _mocks.Verify.......;
> >
> > Say i have an Interface I want to mock. I know during my tests of anoth=
er
> class, there will be a buch of (generally unimportant)
> > method calls that must be "stub"ed so the test in general can run...
> >
> > But the stubs are not important, they just need to be there..
> > Example i supply a ILog mock which only has a method "Log"
> >
> > Now in most tests i dont care what will be logged... But on some i need=
 to
> make sure the right message is passed into the logger...
> >
> > Now i need to override the Log stub and supply an expect.once with a
> certain message... now the logger interface might be simple... But if you=
 do
> the same to a fairly complex view, then you need to stub all events etc s=
o
> the test can work.
> >
> > So back to the logger... My expection wont be fullfilled if i have defi=
ned
> a stub before the expection. the stub definition will swallow all calls t=
o
> Log() and the expection will never catch the "crutial" Log("SH..!!! bette=
r
> call someone NOW!")
> >
> > The exections and stubs have not been setup within an
> > using (mocks.Ordered)
> > {}
> >
> > block, so i think the expections should have a higher priority priority
> then the stubs... After all there is a way to define a strict order.
> >
> > I can post a full version of my event code if that is still requiered. =
But
> I dont want to go into a to much detail, since I see the problem as a mor=
e
> general one. I do have a workaround that works with my event code, but i
> think its a hack ;)
> >
> >
> >
> > -------- Original-Nachricht --------
> > > Datum: Tue, 11 Sep 2007 07:58:06 -0500
> > > Von: "Steve Mitcham" <Ste...@ty...>
> > > An: "NMock2 Development Discussion"
> <nmo...@li...>
> > > Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have a lower
> prioritythen "Expect"
> >
> > > Can you give a more complete example of what you are trying to
> accomplish?
> > >  In your sample, you could use Expect.AtLeastOnce as the expectation =
to
> > > achieve the same effect.
> > >
> > > I'm also not following your event code example. It appears that you a=
re
> > > only exercising the mocked view and nothing of a controller class is
> apparent
> > > in your sample.  You need to give a better example here as well for m=
e
> to
> > > determine what it is you are trying to accomplish.
> > >
> > > I will say that in the current code drop there is some new event
> handling
> > > code that may suit your needs, so you can write the following (the
> sample
> > > is from the acceptance test)
> > >
> > >                       listenerMessage =3D null;
> > >                       Mockery mocks =3D new Mockery();
> > >                       Announcer announcer =3D (Announcer)
> mocks.NewMock(typeof(Announcer));
> > >
> > >                       Expect.Once.On(announcer).EventAdd("Listeners",
> Is.Anything);
> > >
> > >                       announcer.Listeners +=3D new
> Listener(DummyListener);
> > >
> > >                       Fire.Event("Listeners").On(announcer).With("Tes=
t
> Message");
> > >
> > > This might help to serve your purpose.
> > >
> > > -----Original Message-----
> > > From: nmo...@li...
> > > [mailto:nmo...@li...] On Behalf Of Hei=
ko
> Hatzfeld
> > > Sent: Tuesday, September 11, 2007 6:09 AM
> > > To: nmo...@li...
> > > Subject: [NMock2-Dev] Feature Request: "Stub" should have a lower
> > > prioritythen "Expect"
> > >
> > > Hello...
> > >
> > > This is my first post and I already got some complains.. I know its a
> > > great start, but here we go...
> > >
> > > Giving this code:
> > >
> > >
> > >             IDbObject foo =3D _mocks.NewMock<IDbObject>();
> > >             Stub.On(foo).SetProperty("Id");
> > >             Expect.Once.On(foo).SetProperty("Id");
> > >             foo.Id =3D 123;
> > >             _mocks.Verify.......;
> > >
> > > It will generate an exception. The reason is that the above code will
> not
> > > satisfy my expection, since the stub which was defined 1st, will catc=
h
> the
> > > assignment and so the expection will never be reached.
> > >
> > > I think that an expection is much more important then a stub (Which i=
s
> > > kinda a "Fallback" only).
> > >
> > > For example... I want to test a controller for a view, and Verify tha=
t
> the
> > > events are propperly setup and processed...
> > >
> > > I cannot create an implicit setup for the view (which creates the vie=
w
> and
> > > stubs all events), and then attach a real expection onto the view, th=
at
> > > will allow me to sneak a mockEvent in, so i can fire it from the
> outside, and
> > > verify that the controler does its work.
> > >
> > > I currently need to declare an implicit setup, which defines
> expections,
> > > since those can be removed by adding a "fake" Handler on the Mock e.g=
.:
> > >
> > > //Inside CreateViewAndSetupBasicEvents Function
> > > Expect.Once.On(mockedView).EventAdd("Save", Is.Anything);
> > >
> > > //Inside my "real" test function...
> > > mockedView.Save +=3D null;
> > > Expect.Once.On(mockedView).EventAdd("Save", Is.Anything)
> > >       .Will(MockEvent.Hookup(mockevent));
> > > mockEvent.Raise();
> > >
> > >
> > > Hope this makes sense....
> > >
> > > I know i could "fix" it, by creating the view 1st and then adding the
> > > expections, and THEN finally adding all the stubs... But i kinda got
> attached
> > > to my setup functions so i can create and setup a basic mock with one
> > > call... Without that I would have to move the creation of the mock
> around, and I
> > > feel like i am "loosing" some clarity in my test, if I move to much
> into
> > > the "general" setup method.
> > >
> > >
> > > --
> > > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > > Ideal f=FCr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> > >
> > >
> -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > 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 2005.
> > > 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
> >
> > --
> > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
> >
> > -----------------------------------------------------------------------=
--
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > 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 2005.
> > 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
> >
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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
>

Re: [NMock2-Dev] Feature Request: "Stub" should have alowerprioritythen "Expect"

[Steve M. <Ste...@ty...>]

That's what I thought,  thanks for the clarification, and I agree with =
the potential for confusion.

-----Original Message-----
From: nmo...@li... =
[mailto:nmo...@li...] On Behalf Of Nat =
Pryce
Sent: Tuesday, September 11, 2007 2:32 PM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] Feature Request: "Stub" should have =
alowerprioritythen "Expect"

JMock used to check expectations in reverse order so you could set up
some default expectations (stubs usually) and then override them in
individual tests.  However, it was so confusing to users that we
removed the feature and just check for expectation matches in the
order that they are defined.

We found that tests were far more readable if set-up was factored out
into well-named methods called at the start of tests as appropriate
than to define expectations in the SetUp method.

--Nat

On 11/09/2007, Steve Mitcham <Ste...@ty...> wrote:
> It's not a matter of priority, the design philosophy is such that =
NMock is expecting either a Stub or an Expectation, but not both.  Stub =
is just another expectation internally, so if it is first in the list it =
will match all comers.
>
> I could see having an explicit =
Expect.Once.On(foo).ReplacingExistingExpectations.SetProperty("Id");
>
> Which could find and clear all the existing expectations and replace =
it for that test case; however, I don't think I'd want to add in an =
implicit 'override' behavior between expectations.
>
> That's my opinion of course,  if anyone else wants to chime in on =
this, please do.
>
> Nat, if you see this can you comment about the original nmock behavior =
for this case,  were you able to set up a default and then override it =
for specific tests?
>
> -----Original Message-----
> From: nmo...@li... =
[mailto:nmo...@li...] On Behalf Of Heiko =
Hatzfeld
> Sent: Tuesday, September 11, 2007 9:07 AM
> To: NMock2 Development Discussion
> Subject: Re: [NMock2-Dev] Feature Request: "Stub" should have alower =
prioritythen "Expect"
>
> Hello...
>
> Lets ignore the more complicated event code for a second, and get to =
the "real problem" 1st...
>
> IDbObject foo =3D _mocks.NewMock<IDbObject>();
> Stub.On(foo).SetProperty("Id");
> Expect.Once.On(foo).SetProperty("Id");
> foo.Id =3D 123;
> _mocks.Verify.......;
>
> Say i have an Interface I want to mock. I know during my tests of =
another class, there will be a buch of (generally unimportant)
> method calls that must be "stub"ed so the test in general can run...
>
> But the stubs are not important, they just need to be there..
> Example i supply a ILog mock which only has a method "Log"
>
> Now in most tests i dont care what will be logged... But on some i =
need to make sure the right message is passed into the logger...
>
> Now i need to override the Log stub and supply an expect.once with a =
certain message... now the logger interface might be simple... But if =
you do the same to a fairly complex view, then you need to stub all =
events etc so the test can work.
>
> So back to the logger... My expection wont be fullfilled if i have =
defined a stub before the expection. the stub definition will swallow =
all calls to Log() and the expection will never catch the "crutial" =
Log("SH..!!! better call someone NOW!")
>
> The exections and stubs have not been setup within an
> using (mocks.Ordered)
> {}
>
> block, so i think the expections should have a higher priority =
priority then the stubs... After all there is a way to define a strict =
order.
>
> I can post a full version of my event code if that is still requiered. =
But I dont want to go into a to much detail, since I see the problem as =
a more general one. I do have a workaround that works with my event =
code, but i think its a hack ;)
>
>
>
> -------- Original-Nachricht --------
> > Datum: Tue, 11 Sep 2007 07:58:06 -0500
> > Von: "Steve Mitcham" <Ste...@ty...>
> > An: "NMock2 Development Discussion" =
<nmo...@li...>
> > Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have a =
lower prioritythen "Expect"
>
> > Can you give a more complete example of what you are trying to =
accomplish?
> >  In your sample, you could use Expect.AtLeastOnce as the expectation =
to
> > achieve the same effect.
> >
> > I'm also not following your event code example. It appears that you =
are
> > only exercising the mocked view and nothing of a controller class is =
apparent
> > in your sample.  You need to give a better example here as well for =
me to
> > determine what it is you are trying to accomplish.
> >
> > I will say that in the current code drop there is some new event =
handling
> > code that may suit your needs, so you can write the following (the =
sample
> > is from the acceptance test)
> >
> >                       listenerMessage =3D null;
> >                       Mockery mocks =3D new Mockery();
> >                       Announcer announcer =3D (Announcer) =
mocks.NewMock(typeof(Announcer));
> >
> >                       =
Expect.Once.On(announcer).EventAdd("Listeners", Is.Anything);
> >
> >                       announcer.Listeners +=3D new =
Listener(DummyListener);
> >
> >                       =
Fire.Event("Listeners").On(announcer).With("Test Message");
> >
> > This might help to serve your purpose.
> >
> > -----Original Message-----
> > From: nmo...@li...
> > [mailto:nmo...@li...] On Behalf Of =
Heiko Hatzfeld
> > Sent: Tuesday, September 11, 2007 6:09 AM
> > To: nmo...@li...
> > Subject: [NMock2-Dev] Feature Request: "Stub" should have a lower
> > prioritythen "Expect"
> >
> > Hello...
> >
> > This is my first post and I already got some complains.. I know its =
a
> > great start, but here we go...
> >
> > Giving this code:
> >
> >
> >             IDbObject foo =3D _mocks.NewMock<IDbObject>();
> >             Stub.On(foo).SetProperty("Id");
> >             Expect.Once.On(foo).SetProperty("Id");
> >             foo.Id =3D 123;
> >             _mocks.Verify.......;
> >
> > It will generate an exception. The reason is that the above code =
will not
> > satisfy my expection, since the stub which was defined 1st, will =
catch the
> > assignment and so the expection will never be reached.
> >
> > I think that an expection is much more important then a stub (Which =
is
> > kinda a "Fallback" only).
> >
> > For example... I want to test a controller for a view, and Verify =
that the
> > events are propperly setup and processed...
> >
> > I cannot create an implicit setup for the view (which creates the =
view and
> > stubs all events), and then attach a real expection onto the view, =
that
> > will allow me to sneak a mockEvent in, so i can fire it from the =
outside, and
> > verify that the controler does its work.
> >
> > I currently need to declare an implicit setup, which defines =
expections,
> > since those can be removed by adding a "fake" Handler on the Mock =
e.g.:
> >
> > //Inside CreateViewAndSetupBasicEvents Function
> > Expect.Once.On(mockedView).EventAdd("Save", Is.Anything);
> >
> > //Inside my "real" test function...
> > mockedView.Save +=3D null;
> > Expect.Once.On(mockedView).EventAdd("Save", Is.Anything)
> >       .Will(MockEvent.Hookup(mockevent));
> > mockEvent.Raise();
> >
> >
> > Hope this makes sense....
> >
> > I know i could "fix" it, by creating the view 1st and then adding =
the
> > expections, and THEN finally adding all the stubs... But i kinda got =
attached
> > to my setup functions so i can create and setup a basic mock with =
one
> > call... Without that I would have to move the creation of the mock =
around, and I
> > feel like i am "loosing" some clarity in my test, if I move to much =
into
> > the "general" setup method.
> >
> >
> > --
> > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > Ideal f=FCr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> >
> > =
-------------------------------------------------------------------------=

> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > 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 2005.
> > 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
>
> --
> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
>
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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 2005.
> 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 2005.
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

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[Nat P. <nat...@gm...>]

JMock used to check expectations in reverse order so you could set up
some default expectations (stubs usually) and then override them in
individual tests.  However, it was so confusing to users that we
removed the feature and just check for expectation matches in the
order that they are defined.

We found that tests were far more readable if set-up was factored out
into well-named methods called at the start of tests as appropriate
than to define expectations in the SetUp method.

--Nat

On 11/09/2007, Steve Mitcham <Ste...@ty...> wrote:
> It's not a matter of priority, the design philosophy is such that NMock i=
s expecting either a Stub or an Expectation, but not both.  Stub is just an=
other expectation internally, so if it is first in the list it will match a=
ll comers.
>
> I could see having an explicit Expect.Once.On(foo).ReplacingExistingExpec=
tations.SetProperty("Id");
>
> Which could find and clear all the existing expectations and replace it f=
or that test case; however, I don't think I'd want to add in an implicit 'o=
verride' behavior between expectations.
>
> That's my opinion of course,  if anyone else wants to chime in on this, p=
lease do.
>
> Nat, if you see this can you comment about the original nmock behavior fo=
r this case,  were you able to set up a default and then override it for sp=
ecific tests?
>
> -----Original Message-----
> From: nmo...@li... [mailto:nmock-two-dev-b=
ou...@li...] On Behalf Of Heiko Hatzfeld
> Sent: Tuesday, September 11, 2007 9:07 AM
> To: NMock2 Development Discussion
> Subject: Re: [NMock2-Dev] Feature Request: "Stub" should have alower prio=
ritythen "Expect"
>
> Hello...
>
> Lets ignore the more complicated event code for a second, and get to the =
"real problem" 1st...
>
> IDbObject foo =3D _mocks.NewMock<IDbObject>();
> Stub.On(foo).SetProperty("Id");
> Expect.Once.On(foo).SetProperty("Id");
> foo.Id =3D 123;
> _mocks.Verify.......;
>
> Say i have an Interface I want to mock. I know during my tests of another=
 class, there will be a buch of (generally unimportant)
> method calls that must be "stub"ed so the test in general can run...
>
> But the stubs are not important, they just need to be there..
> Example i supply a ILog mock which only has a method "Log"
>
> Now in most tests i dont care what will be logged... But on some i need t=
o make sure the right message is passed into the logger...
>
> Now i need to override the Log stub and supply an expect.once with a cert=
ain message... now the logger interface might be simple... But if you do th=
e same to a fairly complex view, then you need to stub all events etc so th=
e test can work.
>
> So back to the logger... My expection wont be fullfilled if i have define=
d a stub before the expection. the stub definition will swallow all calls t=
o Log() and the expection will never catch the "crutial" Log("SH..!!! bette=
r call someone NOW!")
>
> The exections and stubs have not been setup within an
> using (mocks.Ordered)
> {}
>
> block, so i think the expections should have a higher priority priority t=
hen the stubs... After all there is a way to define a strict order.
>
> I can post a full version of my event code if that is still requiered. Bu=
t I dont want to go into a to much detail, since I see the problem as a mor=
e general one. I do have a workaround that works with my event code, but i =
think its a hack ;)
>
>
>
> -------- Original-Nachricht --------
> > Datum: Tue, 11 Sep 2007 07:58:06 -0500
> > Von: "Steve Mitcham" <Ste...@ty...>
> > An: "NMock2 Development Discussion" <nmo...@li...=
t>
> > Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have a lower p=
rioritythen "Expect"
>
> > Can you give a more complete example of what you are trying to accompli=
sh?
> >  In your sample, you could use Expect.AtLeastOnce as the expectation to
> > achieve the same effect.
> >
> > I'm also not following your event code example. It appears that you are
> > only exercising the mocked view and nothing of a controller class is ap=
parent
> > in your sample.  You need to give a better example here as well for me =
to
> > determine what it is you are trying to accomplish.
> >
> > I will say that in the current code drop there is some new event handli=
ng
> > code that may suit your needs, so you can write the following (the samp=
le
> > is from the acceptance test)
> >
> >                       listenerMessage =3D null;
> >                       Mockery mocks =3D new Mockery();
> >                       Announcer announcer =3D (Announcer) mocks.NewMock=
(typeof(Announcer));
> >
> >                       Expect.Once.On(announcer).EventAdd("Listeners", I=
s.Anything);
> >
> >                       announcer.Listeners +=3D new Listener(DummyListen=
er);
> >
> >                       Fire.Event("Listeners").On(announcer).With("Test =
Message");
> >
> > This might help to serve your purpose.
> >
> > -----Original Message-----
> > From: nmo...@li...
> > [mailto:nmo...@li...] On Behalf Of Heiko=
 Hatzfeld
> > Sent: Tuesday, September 11, 2007 6:09 AM
> > To: nmo...@li...
> > Subject: [NMock2-Dev] Feature Request: "Stub" should have a lower
> > prioritythen "Expect"
> >
> > Hello...
> >
> > This is my first post and I already got some complains.. I know its a
> > great start, but here we go...
> >
> > Giving this code:
> >
> >
> >             IDbObject foo =3D _mocks.NewMock<IDbObject>();
> >             Stub.On(foo).SetProperty("Id");
> >             Expect.Once.On(foo).SetProperty("Id");
> >             foo.Id =3D 123;
> >             _mocks.Verify.......;
> >
> > It will generate an exception. The reason is that the above code will n=
ot
> > satisfy my expection, since the stub which was defined 1st, will catch =
the
> > assignment and so the expection will never be reached.
> >
> > I think that an expection is much more important then a stub (Which is
> > kinda a "Fallback" only).
> >
> > For example... I want to test a controller for a view, and Verify that =
the
> > events are propperly setup and processed...
> >
> > I cannot create an implicit setup for the view (which creates the view =
and
> > stubs all events), and then attach a real expection onto the view, that
> > will allow me to sneak a mockEvent in, so i can fire it from the outsid=
e, and
> > verify that the controler does its work.
> >
> > I currently need to declare an implicit setup, which defines expections=
,
> > since those can be removed by adding a "fake" Handler on the Mock e.g.:
> >
> > //Inside CreateViewAndSetupBasicEvents Function
> > Expect.Once.On(mockedView).EventAdd("Save", Is.Anything);
> >
> > //Inside my "real" test function...
> > mockedView.Save +=3D null;
> > Expect.Once.On(mockedView).EventAdd("Save", Is.Anything)
> >       .Will(MockEvent.Hookup(mockevent));
> > mockEvent.Raise();
> >
> >
> > Hope this makes sense....
> >
> > I know i could "fix" it, by creating the view 1st and then adding the
> > expections, and THEN finally adding all the stubs... But i kinda got at=
tached
> > to my setup functions so i can create and setup a basic mock with one
> > call... Without that I would have to move the creation of the mock arou=
nd, and I
> > feel like i am "loosing" some clarity in my test, if I move to much int=
o
> > the "general" setup method.
> >
> >
> > --
> > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> > Ideal f=FCr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> >
> > -----------------------------------------------------------------------=
--
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > 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 2005.
> > 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
>
> --
> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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 2005.
> 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
>

Re: [NMock2-Dev] Feature Request: "Stub" should have alower prioritythen "Expect"

[Steve M. <Ste...@ty...>]

It's not a matter of priority, the design philosophy is such that NMock =
is expecting either a Stub or an Expectation, but not both.  Stub is =
just another expectation internally, so if it is first in the list it =
will match all comers.

I could see having an explicit =
Expect.Once.On(foo).ReplacingExistingExpectations.SetProperty("Id");

Which could find and clear all the existing expectations and replace it =
for that test case; however, I don't think I'd want to add in an =
implicit 'override' behavior between expectations.

That's my opinion of course,  if anyone else wants to chime in on this, =
please do.

Nat, if you see this can you comment about the original nmock behavior =
for this case,  were you able to set up a default and then override it =
for specific tests?

-----Original Message-----
From: nmo...@li... =
[mailto:nmo...@li...] On Behalf Of Heiko =
Hatzfeld
Sent: Tuesday, September 11, 2007 9:07 AM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] Feature Request: "Stub" should have alower =
prioritythen "Expect"

Hello...

Lets ignore the more complicated event code for a second, and get to the =
"real problem" 1st...

IDbObject foo =3D _mocks.NewMock<IDbObject>();
Stub.On(foo).SetProperty("Id");
Expect.Once.On(foo).SetProperty("Id");
foo.Id =3D 123;
_mocks.Verify.......;

Say i have an Interface I want to mock. I know during my tests of =
another class, there will be a buch of (generally unimportant)
method calls that must be "stub"ed so the test in general can run...=20

But the stubs are not important, they just need to be there..
Example i supply a ILog mock which only has a method "Log"

Now in most tests i dont care what will be logged... But on some i need =
to make sure the right message is passed into the logger...

Now i need to override the Log stub and supply an expect.once with a =
certain message... now the logger interface might be simple... But if =
you do the same to a fairly complex view, then you need to stub all =
events etc so the test can work.=20

So back to the logger... My expection wont be fullfilled if i have =
defined a stub before the expection. the stub definition will swallow =
all calls to Log() and the expection will never catch the "crutial" =
Log("SH..!!! better call someone NOW!")

The exections and stubs have not been setup within an=20
using (mocks.Ordered)
{}

block, so i think the expections should have a higher priority priority =
then the stubs... After all there is a way to define a strict order.

I can post a full version of my event code if that is still requiered. =
But I dont want to go into a to much detail, since I see the problem as =
a more general one. I do have a workaround that works with my event =
code, but i think its a hack ;)



-------- Original-Nachricht --------
> Datum: Tue, 11 Sep 2007 07:58:06 -0500
> Von: "Steve Mitcham" <Ste...@ty...>
> An: "NMock2 Development Discussion" =
<nmo...@li...>
> Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have a lower	=
prioritythen "Expect"

> Can you give a more complete example of what you are trying to =
accomplish?
>  In your sample, you could use Expect.AtLeastOnce as the expectation =
to
> achieve the same effect.
>=20
> I'm also not following your event code example. It appears that you =
are
> only exercising the mocked view and nothing of a controller class is =
apparent
> in your sample.  You need to give a better example here as well for me =
to
> determine what it is you are trying to accomplish.
>=20
> I will say that in the current code drop there is some new event =
handling
> code that may suit your needs, so you can write the following (the =
sample
> is from the acceptance test)
>=20
> 			listenerMessage =3D null;
> 			Mockery mocks =3D new Mockery();
> 			Announcer announcer =3D (Announcer) =
mocks.NewMock(typeof(Announcer));
> 		=09
> 			Expect.Once.On(announcer).EventAdd("Listeners", Is.Anything);
> 		=09
> 			announcer.Listeners +=3D new Listener(DummyListener);
> 		=09
> 			Fire.Event("Listeners").On(announcer).With("Test Message");
>=20
> This might help to serve your purpose.
>=20
> -----Original Message-----
> From: nmo...@li...
> [mailto:nmo...@li...] On Behalf Of =
Heiko Hatzfeld
> Sent: Tuesday, September 11, 2007 6:09 AM
> To: nmo...@li...
> Subject: [NMock2-Dev] Feature Request: "Stub" should have a lower
> prioritythen "Expect"
>=20
> Hello...
>=20
> This is my first post and I already got some complains.. I know its a
> great start, but here we go...
>=20
> Giving this code:
>=20
>=20
>             IDbObject foo =3D _mocks.NewMock<IDbObject>();
>             Stub.On(foo).SetProperty("Id");
>             Expect.Once.On(foo).SetProperty("Id");
>             foo.Id =3D 123;
>             _mocks.Verify.......;
>=20
> It will generate an exception. The reason is that the above code will =
not
> satisfy my expection, since the stub which was defined 1st, will catch =
the
> assignment and so the expection will never be reached.
>=20
> I think that an expection is much more important then a stub (Which is
> kinda a "Fallback" only).
>=20
> For example... I want to test a controller for a view, and Verify that =
the
> events are propperly setup and processed...
>=20
> I cannot create an implicit setup for the view (which creates the view =
and
> stubs all events), and then attach a real expection onto the view, =
that
> will allow me to sneak a mockEvent in, so i can fire it from the =
outside, and
> verify that the controler does its work.
>=20
> I currently need to declare an implicit setup, which defines =
expections,
> since those can be removed by adding a "fake" Handler on the Mock =
e.g.:
>=20
> //Inside CreateViewAndSetupBasicEvents Function
> Expect.Once.On(mockedView).EventAdd("Save", Is.Anything);
>=20
> //Inside my "real" test function...
> mockedView.Save +=3D null;
> Expect.Once.On(mockedView).EventAdd("Save", Is.Anything)
>       .Will(MockEvent.Hookup(mockevent));
> mockEvent.Raise();
>=20
>=20
> Hope this makes sense....
>=20
> I know i could "fix" it, by creating the view 1st and then adding the
> expections, and THEN finally adding all the stubs... But i kinda got =
attached
> to my setup functions so i can create and setup a basic mock with one
> call... Without that I would have to move the creation of the mock =
around, and I
> feel like i am "loosing" some clarity in my test, if I move to much =
into
> the "general" setup method.
>=20
>=20
> --=20
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!=20
> Ideal f=FCr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>=20
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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
>=20
> =
-------------------------------------------------------------------------=

> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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

--=20
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten=20
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

-------------------------------------------------------------------------=

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
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

Re: [NMock2-Dev] Feature Request: "Stub" should have a lower prioritythen "Expect"

[Heiko H. <rdr...@gm...>]

Hello...

Lets ignore the more complicated event code for a second, and get to the "real problem" 1st...

IDbObject foo = _mocks.NewMock<IDbObject>();
Stub.On(foo).SetProperty("Id");
Expect.Once.On(foo).SetProperty("Id");
foo.Id = 123;
_mocks.Verify.......;

Say i have an Interface I want to mock. I know during my tests of another class, there will be a buch of (generally unimportant)
method calls that must be "stub"ed so the test in general can run... 

But the stubs are not important, they just need to be there..
Example i supply a ILog mock which only has a method "Log"

Now in most tests i dont care what will be logged... But on some i need to make sure the right message is passed into the logger...

Now i need to override the Log stub and supply an expect.once with a certain message... now the logger interface might be simple... But if you do the same to a fairly complex view, then you need to stub all events etc so the test can work. 

So back to the logger... My expection wont be fullfilled if i have defined a stub before the expection. the stub definition will swallow all calls to Log() and the expection will never catch the "crutial" Log("SH..!!! better call someone NOW!")

The exections and stubs have not been setup within an 
using (mocks.Ordered)
{}

block, so i think the expections should have a higher priority priority then the stubs... After all there is a way to define a strict order.

I can post a full version of my event code if that is still requiered. But I dont want to go into a to much detail, since I see the problem as a more general one. I do have a workaround that works with my event code, but i think its a hack ;)



-------- Original-Nachricht --------
> Datum: Tue, 11 Sep 2007 07:58:06 -0500
> Von: "Steve Mitcham" <Ste...@ty...>
> An: "NMock2 Development Discussion" <nmo...@li...>
> Betreff: Re: [NMock2-Dev] Feature Request: "Stub" should have a lower	prioritythen "Expect"

> Can you give a more complete example of what you are trying to accomplish?
>  In your sample, you could use Expect.AtLeastOnce as the expectation to
> achieve the same effect.
> 
> I'm also not following your event code example. It appears that you are
> only exercising the mocked view and nothing of a controller class is apparent
> in your sample.  You need to give a better example here as well for me to
> determine what it is you are trying to accomplish.
> 
> I will say that in the current code drop there is some new event handling
> code that may suit your needs, so you can write the following (the sample
> is from the acceptance test)
> 
> 			listenerMessage = null;
> 			Mockery mocks = new Mockery();
> 			Announcer announcer = (Announcer) mocks.NewMock(typeof(Announcer));
> 			
> 			Expect.Once.On(announcer).EventAdd("Listeners", Is.Anything);
> 			
> 			announcer.Listeners += new Listener(DummyListener);
> 			
> 			Fire.Event("Listeners").On(announcer).With("Test Message");
> 
> This might help to serve your purpose.
> 
> -----Original Message-----
> From: nmo...@li...
> [mailto:nmo...@li...] On Behalf Of Heiko Hatzfeld
> Sent: Tuesday, September 11, 2007 6:09 AM
> To: nmo...@li...
> Subject: [NMock2-Dev] Feature Request: "Stub" should have a lower
> prioritythen "Expect"
> 
> Hello...
> 
> This is my first post and I already got some complains.. I know its a
> great start, but here we go...
> 
> Giving this code:
> 
> 
>             IDbObject foo = _mocks.NewMock<IDbObject>();
>             Stub.On(foo).SetProperty("Id");
>             Expect.Once.On(foo).SetProperty("Id");
>             foo.Id = 123;
>             _mocks.Verify.......;
> 
> It will generate an exception. The reason is that the above code will not
> satisfy my expection, since the stub which was defined 1st, will catch the
> assignment and so the expection will never be reached.
> 
> I think that an expection is much more important then a stub (Which is
> kinda a "Fallback" only).
> 
> For example... I want to test a controller for a view, and Verify that the
> events are propperly setup and processed...
> 
> I cannot create an implicit setup for the view (which creates the view and
> stubs all events), and then attach a real expection onto the view, that
> will allow me to sneak a mockEvent in, so i can fire it from the outside, and
> verify that the controler does its work.
> 
> I currently need to declare an implicit setup, which defines expections,
> since those can be removed by adding a "fake" Handler on the Mock e.g.:
> 
> //Inside CreateViewAndSetupBasicEvents Function
> Expect.Once.On(mockedView).EventAdd("Save", Is.Anything);
> 
> //Inside my "real" test function...
> mockedView.Save += null;
> Expect.Once.On(mockedView).EventAdd("Save", Is.Anything)
>       .Will(MockEvent.Hookup(mockevent));
> mockEvent.Raise();
> 
> 
> Hope this makes sense....
> 
> I know i could "fix" it, by creating the view 1st and then adding the
> expections, and THEN finally adding all the stubs... But i kinda got attached
> to my setup functions so i can create and setup a basic mock with one
> call... Without that I would have to move the creation of the mock around, and I
> feel like i am "loosing" some clarity in my test, if I move to much into
> the "general" setup method.
> 
> 
> -- 
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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 2005.
> 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

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Re: [NMock2-Dev] Feature Request: "Stub" should have a lower prioritythen "Expect"

[Steve M. <Ste...@ty...>]

Can you give a more complete example of what you are trying to =
accomplish?  In your sample, you could use Expect.AtLeastOnce as the =
expectation to achieve the same effect.

I'm also not following your event code example. It appears that you are =
only exercising the mocked view and nothing of a controller class is =
apparent in your sample.  You need to give a better example here as well =
for me to determine what it is you are trying to accomplish.

I will say that in the current code drop there is some new event =
handling code that may suit your needs, so you can write the following =
(the sample is from the acceptance test)

			listenerMessage =3D null;
			Mockery mocks =3D new Mockery();
			Announcer announcer =3D (Announcer) mocks.NewMock(typeof(Announcer));
		=09
			Expect.Once.On(announcer).EventAdd("Listeners", Is.Anything);
		=09
			announcer.Listeners +=3D new Listener(DummyListener);
		=09
			Fire.Event("Listeners").On(announcer).With("Test Message");

This might help to serve your purpose.

-----Original Message-----
From: nmo...@li... =
[mailto:nmo...@li...] On Behalf Of Heiko =
Hatzfeld
Sent: Tuesday, September 11, 2007 6:09 AM
To: nmo...@li...
Subject: [NMock2-Dev] Feature Request: "Stub" should have a lower =
prioritythen "Expect"

Hello...

This is my first post and I already got some complains.. I know its a =
great start, but here we go...

Giving this code:


            IDbObject foo =3D _mocks.NewMock<IDbObject>();
            Stub.On(foo).SetProperty("Id");
            Expect.Once.On(foo).SetProperty("Id");
            foo.Id =3D 123;
            _mocks.Verify.......;

It will generate an exception. The reason is that the above code will =
not satisfy my expection, since the stub which was defined 1st, will =
catch the assignment and so the expection will never be reached.

I think that an expection is much more important then a stub (Which is =
kinda a "Fallback" only).

For example... I want to test a controller for a view, and Verify that =
the events are propperly setup and processed...

I cannot create an implicit setup for the view (which creates the view =
and stubs all events), and then attach a real expection onto the view, =
that will allow me to sneak a mockEvent in, so i can fire it from the =
outside, and verify that the controler does its work.

I currently need to declare an implicit setup, which defines expections, =
since those can be removed by adding a "fake" Handler on the Mock e.g.:

//Inside CreateViewAndSetupBasicEvents Function
Expect.Once.On(mockedView).EventAdd("Save", Is.Anything);

//Inside my "real" test function...
mockedView.Save +=3D null;
Expect.Once.On(mockedView).EventAdd("Save", Is.Anything)
      .Will(MockEvent.Hookup(mockevent));
mockEvent.Raise();


Hope this makes sense....

I know i could "fix" it, by creating the view 1st and then adding the =
expections, and THEN finally adding all the stubs... But i kinda got =
attached to my setup functions so i can create and setup a basic mock =
with one call... Without that I would have to move the creation of the =
mock around, and I feel like i am "loosing" some clarity in my test, if =
I move to much into the "general" setup method.


--=20
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!=20
Ideal f=FCr Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

-------------------------------------------------------------------------=

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
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