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

Re: [NMock2-Dev] NMock2 RC2 status

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

As is the case with side development, the explosion of fires in my day
job has eliminated my time in the immediate future.  However, I believe
unless there is any pressing need for the repair of any of the remaining
items in the database there isn't anything preventing someone from
building the RC2 build and posting it to sourceforge.

The latest discussions about the nature of the 'Cause' addition to the
syntax can be tabled until after an RC release.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Andrey
Shchekin
Sent: Wednesday, October 24, 2007 1:55 AM
To: NMock2 Development Discussion
Subject: [NMock2-Dev] NMock2 RC2 status

Hello all,
Do you have a thought on when NMock2 RC2 will be completed?
I am quite interested in it, but it seems last discussions have died.

Thanks,
  Andrey.

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

[NMock2-Dev] NMock2 RC2 status

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

Hello all,
Do you have a thought on when NMock2 RC2 will be completed?
I am quite interested in it, but it seems last discussions have died.

Thanks,
  Andrey.

Re: [NMock2-Dev] Fire syntax

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

I actually very rarely use actions in my test code.  The biggest purpose
of my class was for the common actions of firing an event and setting
parameters, which are pretty straightforward and will benefit from the
readability I think.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Nat
Pryce
Sent: Sunday, October 14, 2007 6:13 AM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] Fire syntax

What about error messages?  It looks convenient to write, but does it
generate useful diagnostics when tests fail?  What is the name of an
anonymous delegate?

JMock and NMock2 were designed favour ease of maintenance over ease of
writing.  E.g. when writing a test  it's worth spending a couple of
minutes writing a new action class that can generate good error
messages to save a couple of hours debugging time later in the project
when that test fails unexpectedly.

--Nat

On 14/10/2007, Andrey Shchekin <as...@gm...> wrote:
> On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> > I see what you are saying with the delegate now.  I think that we
get
> > that into the action by adding an action delegate with no parameters
and
> > allow an anonymous method to be added perhaps something like
> >
> > .Will(Cause.Action(new delegate { DoSomething(); }))
> >
> > And later in 3.5
> >
> > .Will(Cause.Action(()=3D> DoSomething();)); // At least I think that
would
> > be the syntax.
>
> That is cool, but that is one part.
>
> I actually passed the original method parameters to the Action so you
> could provide full method implementation. I also passed the return
> value back if there was one (in this case delegate was not Action, of
> course).
>
> I am attaching code for the Be class to demonstrate the point.
>
>
------------------------------------------------------------------------
-
> 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
>
>
>

------------------------------------------------------------------------
-
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] Fire syntax

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

On 10/14/07, Nat Pryce <nat...@gm...> wrote:
> What about error messages?  It looks convenient to write, but does it
> generate useful diagnostics when tests fail?  What is the name of an
> anonymous delegate?

I generally debug with TestDriven.Net -- Run With Debugger. You can
easily set a breakpoint in the anonymous delegate.
Anyway it is an Action not a matcher, so it never fails expectations.

> JMock and NMock2 were designed favour ease of maintenance over ease of
> writing.  E.g. when writing a test  it's worth spending a couple of
> minutes writing a new action class that can generate good error
> messages to save a couple of hours debugging time later in the project
> when that test fails unexpectedly.

I have never stumled into a situation where I looked at any Actions in log.
It is great to have diagnostics for expectations and *Unit asserts,
but it is much easier to step through code if test itself has a flaw.

And my suggestion is not an only holy way to do it.
If you prefer writing a new class, you can always do it this way.

Also, you do not have to use anonymous delegates -- if a delegate is
allowed, you can pass any method with the required signature.
Something like Will(Cause.Action(this.DoSomethingUseful)). The
anonymous delegates are better only if you want easier access to scope
variables.

Re: [NMock2-Dev] Fire syntax

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

What about error messages?  It looks convenient to write, but does it
generate useful diagnostics when tests fail?  What is the name of an
anonymous delegate?

JMock and NMock2 were designed favour ease of maintenance over ease of
writing.  E.g. when writing a test  it's worth spending a couple of
minutes writing a new action class that can generate good error
messages to save a couple of hours debugging time later in the project
when that test fails unexpectedly.

--Nat

On 14/10/2007, Andrey Shchekin <as...@gm...> wrote:
> On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> > I see what you are saying with the delegate now.  I think that we get
> > that into the action by adding an action delegate with no parameters and
> > allow an anonymous method to be added perhaps something like
> >
> > .Will(Cause.Action(new delegate { DoSomething(); }))
> >
> > And later in 3.5
> >
> > .Will(Cause.Action(()=> DoSomething();)); // At least I think that would
> > be the syntax.
>
> That is cool, but that is one part.
>
> I actually passed the original method parameters to the Action so you
> could provide full method implementation. I also passed the return
> value back if there was one (in this case delegate was not Action, of
> course).
>
> I am attaching code for the Be class to demonstrate the point.
>
> -------------------------------------------------------------------------
> 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] Fire syntax

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

On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> I see what you are saying with the delegate now.  I think that we get
> that into the action by adding an action delegate with no parameters and
> allow an anonymous method to be added perhaps something like
>
> .Will(Cause.Action(new delegate { DoSomething(); }))
>
> And later in 3.5
>
> .Will(Cause.Action(()=> DoSomething();)); // At least I think that would
> be the syntax.

That is cool, but that is one part.

I actually passed the original method parameters to the Action so you
could provide full method implementation. I also passed the return
value back if there was one (in this case delegate was not Action, of
course).

I am attaching code for the Be class to demonstrate the point.

Re: [NMock2-Dev] Fire syntax

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

I see what you are saying with the delegate now.  I think that we get
that into the action by adding an action delegate with no parameters and
allow an anonymous method to be added perhaps something like

.Will(Cause.Action(new delegate { DoSomething(); }))

And later in 3.5=20

.Will(Cause.Action(()=3D> DoSomething();)); // At least I think that =
would
be the syntax.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Andrey
Shchekin
Sent: Saturday, October 13, 2007 4:54 PM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] Fire syntax

On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> Your syntax adds complexity to the API without benefit.  There is
> nothing stopping you from calling your own 'new MyAction()' or 'new
> delegate(){}' at the Will clause in the call.

I can not use delegate() since Will does not receive delegates (at
least in the last release). But I agree that my suggestion is nowhere
near being nice to implement, it's just an idea.

> Also, for the Change instead of Cause,  we are not changing parameters
> we are setting them.  I agree that ToBe might be hard to remember, but
> that's what intellisense is for :)  and once written it reads very
well.

Well, strictly speaking, we change them since thay can be ref not out.
;)
But that's nitpicking.

After some thinking, I agree that Cause is a good choice.
Change is a possible collision trap for other fluent frameworks, and
single Parameter method is not enough to justify it.

------------------------------------------------------------------------
-
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] Fire syntax

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

On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> Your syntax adds complexity to the API without benefit.  There is
> nothing stopping you from calling your own 'new MyAction()' or 'new
> delegate(){}' at the Will clause in the call.

I can not use delegate() since Will does not receive delegates (at
least in the last release). But I agree that my suggestion is nowhere
near being nice to implement, it's just an idea.

> Also, for the Change instead of Cause,  we are not changing parameters
> we are setting them.  I agree that ToBe might be hard to remember, but
> that's what intellisense is for :)  and once written it reads very well.

Well, strictly speaking, we change them since thay can be ref not out. ;)
But that's nitpicking.

After some thinking, I agree that Cause is a good choice.
Change is a possible collision trap for other fluent frameworks, and
single Parameter method is not enough to justify it.

Re: [NMock2-Dev] Fire syntax

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

Your syntax adds complexity to the API without benefit.  There is
nothing stopping you from calling your own 'new MyAction()' or 'new
delegate(){}' at the Will clause in the call.  I mean that for the
elements in the provided interface, I don't want to have to use new.

There was an earlier request to provide 'lazy' resolution for the
methods being passed in, but that hasn't been addressed yet.

Also, for the Change instead of Cause,  we are not changing parameters
we are setting them.  I agree that ToBe might be hard to remember, but
that's what intellisense is for :)  and once written it reads very well.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Andrey
Shchekin
Sent: Saturday, October 13, 2007 4:06 PM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] Fire syntax

On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> I'm trying to avoid calling new in the fluent interface part

I do not know how you can do Be.A(delegate) without having to call new.
One possible way could be Be.An<Action<T>>(delegate(T value) {}) which
does seem better, but I am not sure if it would actually compile (I do
not have time to check now).

I agree that both ways are too cryptic and verbose.
But being able to provide method body just-in-place for some cases is
very  convenient.

------------------------------------------------------------------------
-
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] Fire syntax

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

They are related in that they are actions that could be 'caused' by a
call to a mocked method.=20

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Andrey
Shchekin
Sent: Saturday, October 13, 2007 3:50 PM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] Fire syntax

On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> That's why I used 'Cause' instead of set,  I'm pretty sure that set
> isn't a collision in any namespace.   Importing the NMock2 namespace
is
> just a convenience.  There's nothing from stopping anyone from not
> 'using' the NMock2 namespace and typing:
>
> NMock2.Cause.Parameter(1).ToBe("Foo");
>
> I do, however, want to avoid obvious collisions like 'Set'

What about Change.Parameter(1).To("Foo")?

I think ToBe is harder than To to type and to remember.
And is there actually a need to group event raising and parameter
changing in single class? These concepts seem quite unrelated to me.

------------------------------------------------------------------------
-
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] Fire syntax

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

On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> I'm trying to avoid calling new in the fluent interface part

I do not know how you can do Be.A(delegate) without having to call new.
One possible way could be Be.An<Action<T>>(delegate(T value) {}) which
does seem better, but I am not sure if it would actually compile (I do
not have time to check now).

I agree that both ways are too cryptic and verbose.
But being able to provide method body just-in-place for some cases is
very  convenient.

Re: [NMock2-Dev] Fire syntax

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

On 10/14/07, Steve Mitcham <Ste...@ty...> wrote:
> That's why I used 'Cause' instead of set,  I'm pretty sure that set
> isn't a collision in any namespace.   Importing the NMock2 namespace is
> just a convenience.  There's nothing from stopping anyone from not
> 'using' the NMock2 namespace and typing:
>
> NMock2.Cause.Parameter(1).ToBe("Foo");
>
> I do, however, want to avoid obvious collisions like 'Set'

What about Change.Parameter(1).To("Foo")?

I think ToBe is harder than To to type and to remember.
And is there actually a need to group event raising and parameter
changing in single class? These concepts seem quite unrelated to me.

Re: [NMock2-Dev] Fire syntax

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

That's why I used 'Cause' instead of set,  I'm pretty sure that set
isn't a collision in any namespace.   Importing the NMock2 namespace is
just a convenience.  There's nothing from stopping anyone from not
'using' the NMock2 namespace and typing:

NMock2.Cause.Parameter(1).ToBe("Foo");

I do, however, want to avoid obvious collisions like 'Set'

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of
Charlie Poole
Sent: Saturday, October 13, 2007 12:24 PM
To: 'NMock2 Development Discussion'
Subject: Re: [NMock2-Dev] Fire syntax

Hi All,=20

> I used Will(Set.Parameter("foo").To("bar")), but this, of=20
> course, will have problems in VB where Set is a keyword.

FWIW, I have been dealing with a similar issue in NUnit after
introducing a new syntax similar to NMock's. There are language
problems with VB, C++ and probably others I don't know about.

What I'm thinking of doing is putting the C# syntax into a=20
separate namespace and having one or more other assemblies
that provide a syntax tailored for other languages.

That way, other folks can provide alternative syntax layers
without colliding with the names used for C#.

Charlie



------------------------------------------------------------------------
-
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] Fire syntax

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

I'm trying to avoid calling new in the fluent interface part, but I do
agree that just having one Parameter() method that accepts either an
index or a name.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Andrey
Shchekin
Sent: Saturday, October 13, 2007 3:26 AM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] Fire syntax

> To complete the discussion the Cause will also have
>
>
Expect.Once.On(mock).Method("MethodWithRefParameters").With(Is.Out).Will
> (Cause.NamedParameter("foo").ToBe("bar"));
>
>
Expect.Once.On(mock).Method("MethodWithRefParameters").With(Is.Out).Will
> (Cause.IndexedParameter(0).ToBe("bar""));

I used Will(Set.Parameter("foo").To("bar")), but this, of course, will
have problems in VB where Set is a keyword.

But I think Cause.Parameter(_nameOrIndex_).ToBe(value) would be more
concise. Or, maybe, Change.Parameter.To. While it requires another
root class, it is shorter and easier to remember.

By the way, I also use a Will(Be.A(new Action(delegate() {}))) in my
work code.
I am not sure if there is anything similar to this in the current NMock2
code.

------------------------------------------------------------------------
-
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] Fire syntax

[Charlie P. <ch...@po...>]

Hi All, 

> I used Will(Set.Parameter("foo").To("bar")), but this, of 
> course, will have problems in VB where Set is a keyword.

FWIW, I have been dealing with a similar issue in NUnit after
introducing a new syntax similar to NMock's. There are language
problems with VB, C++ and probably others I don't know about.

What I'm thinking of doing is putting the C# syntax into a 
separate namespace and having one or more other assemblies
that provide a syntax tailored for other languages.

That way, other folks can provide alternative syntax layers
without colliding with the names used for C#.

Charlie

Re: [NMock2-Dev] Fire syntax

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

> To complete the discussion the Cause will also have
>
> Expect.Once.On(mock).Method("MethodWithRefParameters").With(Is.Out).Will
> (Cause.NamedParameter("foo").ToBe("bar"));
>
> Expect.Once.On(mock).Method("MethodWithRefParameters").With(Is.Out).Will
> (Cause.IndexedParameter(0).ToBe("bar""));

I used Will(Set.Parameter("foo").To("bar")), but this, of course, will
have problems in VB where Set is a keyword.

But I think Cause.Parameter(_nameOrIndex_).ToBe(value) would be more
concise. Or, maybe, Change.Parameter.To. While it requires another
root class, it is shorter and easier to remember.

By the way, I also use a Will(Be.A(new Action(delegate() {}))) in my work code.
I am not sure if there is anything similar to this in the current NMock2 code.

Re: [NMock2-Dev] Fire syntax

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

As a consumer of the NMock library, I'd prefer method (2) also. Some of the
folks with a closer view of the internals might be able to pitch in on the
technical pros and cons.

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

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

Ok.  Got the patch in.  I reordered the directives to make it easier to
dump the excess when we go to 2.0 only.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of Steve
Mitcham
Sent: Friday, October 12, 2007 2:46 PM
To: NMock2 Development Discussion
Cc: smi...@gm...
Subject: Re: [NMock2-Dev] CVS SVN and .NET 3.5

I'll get a clean checkout and do a diff.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of
aci...@ac...
Sent: Friday, October 12, 2007 2:37 PM
To: NMock2 Development Discussion
Cc: smi...@gm...
Subject: Re: [NMock2-Dev] CVS SVN and .NET 3.5

On Fri, October 12, 2007 1:10 pm, Steve Mitcham wrote:
> Bug #: 1521702
> Title: Nullable types do not work in nmock 2.0
> NMock2?: Yes
> Proposed Resolution: Merge patch, then mark Closed, Fixed
>
> I'm not getting a failure when I added the test case from the patch
> before adding the solution in.

Just to validate I got a clean checkout from CVS and added the test in
to
my copy, ran it and it fails.

Environment:
Windows 2003
Visual Studio 2005
.NET 1.0.03705, 1.1.4322, 2.0.50727 and 3.0 installed

Not sure what is different about our setups, anything else I can look at
let me know.

-Richard Holden


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

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

[NMock2-Dev] Fire syntax

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

There is currently not a unit test for the FireAction class, which is
meant to fire an event in response to an expectation.  I'm trying to
write some documentation for the event class and think that for clarity
we should try and combine the two actions.  I'm not sure how to proceed
at the moment though.  I see a couple of possible paths.

1.=20

Leave the Fire class alone.
Create a parallel 'Cause' class that holds the actions for Event,
SetNamedParameter, and SetIndexedParameter (which currently must be
created by hand).
There will need to be a different interface for the final stop on the
cause class for events because it doesn't require an object and must
return an action.  Currently the Fire class fires the event.

2.=20

Break the Fire class but set it up to combine with the Cause class.  The
new syntax would look like

Fire.Event("Foo").On(mockInterfaceWithEvents).With(mockInterfaceWithEven
ts,EventArgs.Empty).Now();

And

Expect.Once.On(mockInterfaceWithEvents).Method("CausesEventToFire").With
NoArguments().
=20
Will(Cause.Event("Foo").With(mockInterfaceWithEvents,EventArgs.Empty).To
Fire());


I hesitate to break existing code (especially mine), but I think now is
the time to make adjustments before an official release that includes
the event stuff.

To complete the discussion the Cause will also have

Expect.Once.On(mock).Method("MethodWithRefParameters").With(Is.Out).Will
(Cause.NamedParameter("foo").ToBe("bar"));

Expect.Once.On(mock).Method("MethodWithRefParameters").With(Is.Out).Will
(Cause.IndexedParameter(0).ToBe("bar""));


Any comments on a course of action would be appreciated,   I prefer 2
unless anyone has a better suggestion.

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

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

I'll get a clean checkout and do a diff.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of
aci...@ac...
Sent: Friday, October 12, 2007 2:37 PM
To: NMock2 Development Discussion
Cc: smi...@gm...
Subject: Re: [NMock2-Dev] CVS SVN and .NET 3.5

On Fri, October 12, 2007 1:10 pm, Steve Mitcham wrote:
> Bug #: 1521702
> Title: Nullable types do not work in nmock 2.0
> NMock2?: Yes
> Proposed Resolution: Merge patch, then mark Closed, Fixed
>
> I'm not getting a failure when I added the test case from the patch
> before adding the solution in.

Just to validate I got a clean checkout from CVS and added the test in
to
my copy, ran it and it fails.

Environment:
Windows 2003
Visual Studio 2005
.NET 1.0.03705, 1.1.4322, 2.0.50727 and 3.0 installed

Not sure what is different about our setups, anything else I can look at
let me know.

-Richard Holden


------------------------------------------------------------------------
-
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] CVS SVN and .NET 3.5

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

On Fri, October 12, 2007 1:10 pm, Steve Mitcham wrote:
> Bug #: 1521702
> Title: Nullable types do not work in nmock 2.0
> NMock2?: Yes
> Proposed Resolution: Merge patch, then mark Closed, Fixed
>
> I'm not getting a failure when I added the test case from the patch
> before adding the solution in.

Just to validate I got a clean checkout from CVS and added the test in to
my copy, ran it and it fails.

Environment:
Windows 2003
Visual Studio 2005
.NET 1.0.03705, 1.1.4322, 2.0.50727 and 3.0 installed

Not sure what is different about our setups, anything else I can look at
let me know.

-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 12:56 pm, Andrey Shchekin wrote:
> > 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/
>
> So it is possible, which is nice to know. Your blog post however
> reinforces my statement that we shouldn't fix the "bug". As a developer
> you know you are going to be mocking your code and can add the
> InternalsVisibleTo attribute if you want to. This doesn't work with
> someone elses code but it doesn't make sense to try and rely on behavior
> that an outside library has explicitly marked internal.

Personally I am absolutely fine with the current behavior.
But it needs to be described in Q&A somewhere, with a code snippet.

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

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

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

I'm not getting a failure when I added the test case from the patch
before adding the solution in.




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?

I'll look at this one later today if I get a chance or over the weekend
otherwise.




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

I've already patched this one in I believe.




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.

I read the blog entry about this post, and I'm not understanding it
works.  I thought 'InternalsVisibleTo' required a signed assembly.  I
agree that it may not work with a signed DLL.  If something is
completely internal, I usually don't try to test it directly, so
anything I mock is public.



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

Agree.

-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of
aci...@ac...
Sent: Friday, October 12, 2007 1:50 PM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] CVS SVN and .NET 3.5

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


------------------------------------------------------------------------
-
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] CVS SVN and .NET 3.5

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

On Fri, October 12, 2007 12:56 pm, Andrey Shchekin wrote:
> 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/

So it is possible, which is nice to know. Your blog post however
reinforces my statement that we shouldn't fix the "bug". As a developer
you know you are going to be mocking your code and can add the
InternalsVisibleTo attribute if you want to. This doesn't work with
someone elses code but it doesn't make sense to try and rely on behavior
that an outside library has explicitly marked internal.

-Richard Holden

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

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

Yes, moving the solution to fully 2.0 and archiving the support for
1.1/1.0 has been discussed, and I think agreed to, which implies once we
get a tag down, we can go through and get rid of all the conditional
directives.

I think once we make the change to support 2005 only, we can take a good
look at the internals and do quite a bit of cleanup.  I'd like to hold
off on 3.5 work until we get the internals cleaned up, because I think
it will help.

The event stuff is pretty straightforward, and if I hadn't been hit with
about 5 4-alarm fires at work, I'd be done by now.  I'm going to get a
little bit of budget to work on NMock2 in the near future (i.e. next 2
weeks max) for some internal stuff and I've already got the permission I
need to export the changes, so I'll be able to document the event on the
clock.



-----Original Message-----
From: nmo...@li...
[mailto:nmo...@li...] On Behalf Of
aci...@ac...
Sent: Friday, October 12, 2007 1:57 PM
To: NMock2 Development Discussion
Subject: Re: [NMock2-Dev] CVS SVN and .NET 3.5

> 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


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