nmock-general

[Nmock-general] nmock2/src - New directory

[Steve F. <sm...@us...>]

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

Log Message:
Directory /cvsroot/nmock/nmock2/src added to the repository

[Nmock-general] nmock2/src/NMock2 - New directory

[Steve F. <sm...@us...>]

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

Log Message:
Directory /cvsroot/nmock/nmock2/src/NMock2 added to the repository

[Nmock-general] nmock2/lib - New directory

[Steve F. <sm...@us...>]

Update of /cvsroot/nmock/nmock2/lib
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23977/lib

Log Message:
Directory /cvsroot/nmock/nmock2/lib added to the repository

[Nmock-general] nmock2 - New directory

[Steve F. <sm...@us...>]

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

Log Message:
Directory /cvsroot/nmock/nmock2 added to the repository

Re: [Nmock-general] NMO-37 - Indexers in c# are not working properly

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

Ok, I'm happy with that.  I'm sure the users will be too!

I've also been thinking about some sort of compatability layer to help
the transition.  I'm not sure how yet.  We tried it with jMock, but
(a) it wasn't really a compatability layer, and (b) it was a too much
work for the dev-team (i.e. me!).

--Nat.

On 5/24/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> Hi Nat
>=20
> > However, is it worth fundamentally changing the semantics of NMock
> > expectations?  I'm going to check NMock-2 into CVS this thursday,
> > which dispatches on argument values and more.  The API and semantics
> > are different, but I've put the new code into a different namespace to
> > allow a gradual transition from NMock to NMock2.  However, if the
> > semantics of NMock are going to change, how are users going to upgrade
> > -- they can't gradually upgrade to the latest version of NMock1 -- and
> > is this going to confuse users?
>=20
> Although I'm suffering myself from that ;), I think we should avoid
> putting too much effort on nmock1... I'm aware that the change
> required to fix NMO-37 and other related issues will necessarily bring
> regressions into existing test code for some users, and involves
> somehow a big change in the semantics of NMock 1.
>=20
> IMHO we should only fix simple bugs on NMock 1, and concentrate on NMock =
2.
>=20
>=20
> Thibaut
>=20
>=20
> > What do people think?  How should we approach this?
> >
> > --Nat.
> >
> >
> > On 5/24/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> > > Hi Johan
> > >
> > > have a look at my previous post named SetupResult behavior and NMO-37
> > > (indexed properties). Here's the current state of my "investigation"
> > > (I'm discovering the source so please bear with me ;)
> > >
> > > 1/ About c# indexed properties, with SetupResult and ExpectAndReturn
> > >
> > > Actually SetupResult works for index property if there is only one
> > > index definition, eg the following does work :
> > >
> > > public interface IFoo
> > > {
> > >         string this[int index] { get; }
> > > }
> > >
> > > [Test]
> > > public void UniqueIndexedProperty()
> > > {
> > >         DynamicMock mock =3D new DynamicMock(typeof(IFoo));
> > >         mock.SetupResult("Item","TheValue",typeof(int));
> > >         IFoo foo =3D (IFoo)mock.MockInstance;
> > >         Assert.AreEqual("TheValue",foo[45]);
> > > }
> > >
> > > The failure appears when you have more than one index, eg:
> > >
> > > public interface IFoo
> > > {
> > >         string this[int index] { get; }
> > >         string this[string index] { get; }
> > > }
> > >
> > > as this leads to ambiguous match and other issues the way it's
> > > currently implemented. So actually indexed properties do work for
> > > SetupResult as long as there is no more than one index... The same
> > > applies for ExpectAndReturn.
> > >
> > > 2/ about non c# indexed properties
> > >
> > > Did you actually already try to use non c# index properties (with onl=
y
> > > one index) ? I didn't test that, but I suppose it could already work
> > > as long as you only have one index defined (else we go back to issue
> > > described in 1/).
> > >
> > > 3/ about helping
> > >
> > > sure you can. What I'd like to get first is a test fixture to isolate
> > > each of the cases we want to implement (more or less what I wrote
> > > above, but for each case : one indexed property with setupresult, one
> > > with expectandreturn, two with setupresult, two with expectandreturn)=
.
> > >
> > >
> > >
> > >
> > >
> > > =3D> to other nmock devs: in order to fix this, we would have to chan=
ge
> > > the way we store the expectations / method registrations, which use
> > > the method name as a key in current code (see _methods Hashtable), an=
d
> > > use something (such as the signature) which takes the parameters type=
s
> > > into account in the key. Any opinion before I try to proceed ?
> > >
> > >
> > >
> > > kind regards
> > >
> > > Thibaut
> > >
> > >
> > > 2005/5/24, Johan Appelgren <joh...@gm...>:
> > > > On 5/16/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> > > > > If nothing has already been done for this one, I can look at it
> > > > > (unless there are more critical issues)
> > > > >
> > > > > Thibaut
> > > >
> > > > Have you had time to make any progress on this?
> > > >
> > > > If support for the only indexed property that C# can generate is
> > > > added, would it be possible to also extend it to support indexed
> > > > properties generally. Like for those that can be defined using mana=
ged
> > > > c++? The reason for this is that I want to mock some com interop
> > > > interfaces that use indexed properties extensively.
> > > >
> > > > If I can help in some way let me know.
> > > >
> > > > /Johan
> > > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > > Want to be the first software developer in space?
> > > Enter now for the Oracle Space Sweepstakes!
> > > http://ads.osdn.com/?ad_idt12&alloc_id=16344&opclick
> > > _______________________________________________
> > > Nmock-general mailing list
> > > Nmo...@li...
> > > https://lists.sourceforge.net/lists/listinfo/nmock-general
> > >
> >
>

Re: [Nmock-general] NMO-37 - Indexers in c# are not working properly

[<thi...@gm...>]

Hi Nat

> However, is it worth fundamentally changing the semantics of NMock
> expectations?  I'm going to check NMock-2 into CVS this thursday,
> which dispatches on argument values and more.  The API and semantics
> are different, but I've put the new code into a different namespace to
> allow a gradual transition from NMock to NMock2.  However, if the
> semantics of NMock are going to change, how are users going to upgrade
> -- they can't gradually upgrade to the latest version of NMock1 -- and
> is this going to confuse users?

Although I'm suffering myself from that ;), I think we should avoid
putting too much effort on nmock1... I'm aware that the change
required to fix NMO-37 and other related issues will necessarily bring
regressions into existing test code for some users, and involves
somehow a big change in the semantics of NMock 1.

IMHO we should only fix simple bugs on NMock 1, and concentrate on NMock 2.


Thibaut


> What do people think?  How should we approach this?
>=20
> --Nat.
>=20
>=20
> On 5/24/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> > Hi Johan
> >
> > have a look at my previous post named SetupResult behavior and NMO-37
> > (indexed properties). Here's the current state of my "investigation"
> > (I'm discovering the source so please bear with me ;)
> >
> > 1/ About c# indexed properties, with SetupResult and ExpectAndReturn
> >
> > Actually SetupResult works for index property if there is only one
> > index definition, eg the following does work :
> >
> > public interface IFoo
> > {
> >         string this[int index] { get; }
> > }
> >
> > [Test]
> > public void UniqueIndexedProperty()
> > {
> >         DynamicMock mock =3D new DynamicMock(typeof(IFoo));
> >         mock.SetupResult("Item","TheValue",typeof(int));
> >         IFoo foo =3D (IFoo)mock.MockInstance;
> >         Assert.AreEqual("TheValue",foo[45]);
> > }
> >
> > The failure appears when you have more than one index, eg:
> >
> > public interface IFoo
> > {
> >         string this[int index] { get; }
> >         string this[string index] { get; }
> > }
> >
> > as this leads to ambiguous match and other issues the way it's
> > currently implemented. So actually indexed properties do work for
> > SetupResult as long as there is no more than one index... The same
> > applies for ExpectAndReturn.
> >
> > 2/ about non c# indexed properties
> >
> > Did you actually already try to use non c# index properties (with only
> > one index) ? I didn't test that, but I suppose it could already work
> > as long as you only have one index defined (else we go back to issue
> > described in 1/).
> >
> > 3/ about helping
> >
> > sure you can. What I'd like to get first is a test fixture to isolate
> > each of the cases we want to implement (more or less what I wrote
> > above, but for each case : one indexed property with setupresult, one
> > with expectandreturn, two with setupresult, two with expectandreturn).
> >
> >
> >
> >
> >
> > =3D> to other nmock devs: in order to fix this, we would have to change
> > the way we store the expectations / method registrations, which use
> > the method name as a key in current code (see _methods Hashtable), and
> > use something (such as the signature) which takes the parameters types
> > into account in the key. Any opinion before I try to proceed ?
> >
> >
> >
> > kind regards
> >
> > Thibaut
> >
> >
> > 2005/5/24, Johan Appelgren <joh...@gm...>:
> > > On 5/16/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> > > > If nothing has already been done for this one, I can look at it
> > > > (unless there are more critical issues)
> > > >
> > > > Thibaut
> > >
> > > Have you had time to make any progress on this?
> > >
> > > If support for the only indexed property that C# can generate is
> > > added, would it be possible to also extend it to support indexed
> > > properties generally. Like for those that can be defined using manage=
d
> > > c++? The reason for this is that I want to mock some com interop
> > > interfaces that use indexed properties extensively.
> > >
> > > If I can help in some way let me know.
> > >
> > > /Johan
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Oracle Space Sweepstakes
> > Want to be the first software developer in space?
> > Enter now for the Oracle Space Sweepstakes!
> > http://ads.osdn.com/?ad_idt12&alloc_id=16344&opclick
> > _______________________________________________
> > Nmock-general mailing list
> > Nmo...@li...
> > https://lists.sourceforge.net/lists/listinfo/nmock-general
> >
>

Re: [Nmock-general] NMO-37 - Indexers in c# are not working properly

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

NMock-1 is a port of DynaMock, an old Java mock library I wrote.  It
keys expectations on method name.  As you're finding out, that's very
limiting.  We changed this in DynaMock-0.09, but the then nmock
developers didn't port our changes.  We carried on the design in
jMock, but again the changes weren't ported.

DynaMock-0.09 and jMock dispatch invocations to expectations by using
all the constraints to match the invocation.  This lets the user
define expectations and/or stubs on methods and their argument
*values*, which is very powerful and expressive.

However, is it worth fundamentally changing the semantics of NMock
expectations?  I'm going to check NMock-2 into CVS this thursday,
which dispatches on argument values and more.  The API and semantics
are different, but I've put the new code into a different namespace to
allow a gradual transition from NMock to NMock2.  However, if the
semantics of NMock are going to change, how are users going to upgrade
-- they can't gradually upgrade to the latest version of NMock1 -- and
is this going to confuse users?

What do people think?  How should we approach this?

--Nat.


On 5/24/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> Hi Johan
>=20
> have a look at my previous post named SetupResult behavior and NMO-37
> (indexed properties). Here's the current state of my "investigation"
> (I'm discovering the source so please bear with me ;)
>=20
> 1/ About c# indexed properties, with SetupResult and ExpectAndReturn
>=20
> Actually SetupResult works for index property if there is only one
> index definition, eg the following does work :
>=20
> public interface IFoo
> {
>         string this[int index] { get; }
> }
>=20
> [Test]
> public void UniqueIndexedProperty()
> {
>         DynamicMock mock =3D new DynamicMock(typeof(IFoo));
>         mock.SetupResult("Item","TheValue",typeof(int));
>         IFoo foo =3D (IFoo)mock.MockInstance;
>         Assert.AreEqual("TheValue",foo[45]);
> }
>=20
> The failure appears when you have more than one index, eg:
>=20
> public interface IFoo
> {
>         string this[int index] { get; }
>         string this[string index] { get; }
> }
>=20
> as this leads to ambiguous match and other issues the way it's
> currently implemented. So actually indexed properties do work for
> SetupResult as long as there is no more than one index... The same
> applies for ExpectAndReturn.
>=20
> 2/ about non c# indexed properties
>=20
> Did you actually already try to use non c# index properties (with only
> one index) ? I didn't test that, but I suppose it could already work
> as long as you only have one index defined (else we go back to issue
> described in 1/).
>=20
> 3/ about helping
>=20
> sure you can. What I'd like to get first is a test fixture to isolate
> each of the cases we want to implement (more or less what I wrote
> above, but for each case : one indexed property with setupresult, one
> with expectandreturn, two with setupresult, two with expectandreturn).
>=20
>=20
>=20
>=20
>=20
> =3D> to other nmock devs: in order to fix this, we would have to change
> the way we store the expectations / method registrations, which use
> the method name as a key in current code (see _methods Hashtable), and
> use something (such as the signature) which takes the parameters types
> into account in the key. Any opinion before I try to proceed ?
>=20
>=20
>=20
> kind regards
>=20
> Thibaut
>=20
>=20
> 2005/5/24, Johan Appelgren <joh...@gm...>:
> > On 5/16/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> > > If nothing has already been done for this one, I can look at it
> > > (unless there are more critical issues)
> > >
> > > Thibaut
> >
> > Have you had time to make any progress on this?
> >
> > If support for the only indexed property that C# can generate is
> > added, would it be possible to also extend it to support indexed
> > properties generally. Like for those that can be defined using managed
> > c++? The reason for this is that I want to mock some com interop
> > interfaces that use indexed properties extensively.
> >
> > If I can help in some way let me know.
> >
> > /Johan
> >
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_idt12&alloc_id=16344&opclick
> _______________________________________________
> Nmock-general mailing list
> Nmo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-general
>

[Nmock-general] how to introspect variables???

[Dean H. <dea...@Bo...>]

I have a statement like so

=20

ServiceRequest req =3D new ServiceRequest();

req.Id =3D "xyz"

req.result =3D "abc";

Mock.expect("method", new IsEquals(req));

=20

Except I am not expecting req and actual to be equal. I am actually only
expecting the req.result to be equal.  How do I do this with nmock?  I
used to use java's mocklib which returned the parameters to you so you
could just use normal JUnit assert statements statements(though this is
because java's mocklib does the expects after calling the method on the
implementation instead of before, therefore it caches the params and
returns them to you on the call to expect.

=20

Is there a way to do this with nmock though?

Thanks,

dean

--------------------------------------------------------
The information contained in this e-mail and any attachments hereto are =
for the exclusive use of the addressee and may contain confidential, =
privileged and nondisclosable information. If the recipient of this =
e-mail is not the addressee, or a person responsible for delivering this =
e-mail to the addressee, such recipient is strictly prohibited from =
reading, printing, photocopying, distributing or otherwise using this =
e-mail or any attachments hereto in any way. If the recipient has =
received this e-mail in error, please send return e-mail immediately =
notifying us of your receipt of this e-mail and delete the e-mail from =
your inbox. Thank you.

Re: [Nmock-general] NMO-37 - Indexers in c# are not working properly

[<thi...@gm...>]

Hi Johan

have a look at my previous post named SetupResult behavior and NMO-37
(indexed properties). Here's the current state of my "investigation"
(I'm discovering the source so please bear with me ;)

1/ About c# indexed properties, with SetupResult and ExpectAndReturn

Actually SetupResult works for index property if there is only one
index definition, eg the following does work :

public interface IFoo
{
=09string this[int index] { get; }
}

[Test]
public void UniqueIndexedProperty()
{
=09DynamicMock mock =3D new DynamicMock(typeof(IFoo));
=09mock.SetupResult("Item","TheValue",typeof(int));
=09IFoo foo =3D (IFoo)mock.MockInstance;
=09Assert.AreEqual("TheValue",foo[45]);
}

The failure appears when you have more than one index, eg:

public interface IFoo
{
=09string this[int index] { get; }
=09string this[string index] { get; }
}

as this leads to ambiguous match and other issues the way it's
currently implemented. So actually indexed properties do work for
SetupResult as long as there is no more than one index... The same
applies for ExpectAndReturn.

2/ about non c# indexed properties

Did you actually already try to use non c# index properties (with only
one index) ? I didn't test that, but I suppose it could already work
as long as you only have one index defined (else we go back to issue
described in 1/).

3/ about helping

sure you can. What I'd like to get first is a test fixture to isolate
each of the cases we want to implement (more or less what I wrote
above, but for each case : one indexed property with setupresult, one
with expectandreturn, two with setupresult, two with expectandreturn).





=3D> to other nmock devs: in order to fix this, we would have to change
the way we store the expectations / method registrations, which use
the method name as a key in current code (see _methods Hashtable), and
use something (such as the signature) which takes the parameters types
into account in the key. Any opinion before I try to proceed ?



kind regards

Thibaut


2005/5/24, Johan Appelgren <joh...@gm...>:
> On 5/16/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> > If nothing has already been done for this one, I can look at it
> > (unless there are more critical issues)
> >
> > Thibaut
>=20
> Have you had time to make any progress on this?
>=20
> If support for the only indexed property that C# can generate is
> added, would it be possible to also extend it to support indexed
> properties generally. Like for those that can be defined using managed
> c++? The reason for this is that I want to mock some com interop
> interfaces that use indexed properties extensively.
>=20
> If I can help in some way let me know.
>=20
> /Johan
>

Re: [Nmock-general] Couple questions and suggestions

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

Ok, I'll do that.  I'll also make sure that all references to NUnit
are removed from the codebase (Assert, mainly).

--Nat.

On 5/24/05, Johan Appelgren <joh...@gm...> wrote:
> Sounds good to me.
>=20
> /Johan
>=20
> On 5/24/05, Nat Pryce <nat...@gm...> wrote:
> > Currently NMock2 throws NUnit's AssertionException when it detects a
> > test failure.  I can make it throw it's own exception
> > (ExpectationException, say) so that it is entirely self contained.
> >
> > What do people think?
> >
> > On 5/23/05, Johan Appelgren <joh...@gm...> wrote:
> > > Thank you, I'll try and take a look at it during the week.
> > >
> > > Just opened the project to take a quick peek now and I noticed that
> > > the mock project depends on nunit. Do you plan to make it dependant o=
n
> > > nunit?
> > >
> > > /Johan
> > >
> > > On 5/23/05, Nat Pryce <nat...@gm...> wrote:
> > > > I haven't had a chance to check it in anywhere public yet... hopefu=
lly
> > > > this week.  I've attached a zip of the latest code.  The attachment=
 is
> > > > a normal ZIP archive.
> > > >
> > > > --Nat.
> > > >
> > > > On 5/23/05, Johan Appelgren <joh...@gm...> wrote:
> > > > > On 5/11/05, Nat Pryce <nat...@gm...> wrote:
> > > > > > On that topic, I've just about finished version 0.00000001 pre-=
alpha
> > > > > > technology preview.  Anybody want to play with it and give feed=
back?
> > > > > >
> > > > > > Also, where should I check it in? And what shall we call it --
> > > > > > nMock-2? jMock .NET? At the moment it's called SharpMock, but t=
hat's a
> > > > > > crap name.
> > > > > >
> > > > > > --Nat.
> > > > >
> > > > > Did you check in the code somewhere? I'd like to take a look, and=
 if
> > > > > possible give feedback :)
> > > > >
> > > > > /Johan
> > > > >
> > > >
> > > >
> > > >
> > >
> >
>

Re: [Nmock-general] NMO-37 - Indexers in c# are not working properly

[Johan A. <joh...@gm...>]

On 5/16/05, Thibaut Barr=E8re <thi...@gm...> wrote:
> If nothing has already been done for this one, I can look at it
> (unless there are more critical issues)
>=20
> Thibaut

Have you had time to make any progress on this?=20

If support for the only indexed property that C# can generate is
added, would it be possible to also extend it to support indexed
properties generally. Like for those that can be defined using managed
c++? The reason for this is that I want to mock some com interop
interfaces that use indexed properties extensively.

If I can help in some way let me know.

/Johan

Re: [Nmock-general] Couple questions and suggestions

[Johan A. <joh...@gm...>]

Sounds good to me.=20

/Johan

On 5/24/05, Nat Pryce <nat...@gm...> wrote:
> Currently NMock2 throws NUnit's AssertionException when it detects a
> test failure.  I can make it throw it's own exception
> (ExpectationException, say) so that it is entirely self contained.
>=20
> What do people think?
>=20
> On 5/23/05, Johan Appelgren <joh...@gm...> wrote:
> > Thank you, I'll try and take a look at it during the week.
> >
> > Just opened the project to take a quick peek now and I noticed that
> > the mock project depends on nunit. Do you plan to make it dependant on
> > nunit?
> >
> > /Johan
> >
> > On 5/23/05, Nat Pryce <nat...@gm...> wrote:
> > > I haven't had a chance to check it in anywhere public yet... hopefull=
y
> > > this week.  I've attached a zip of the latest code.  The attachment i=
s
> > > a normal ZIP archive.
> > >
> > > --Nat.
> > >
> > > On 5/23/05, Johan Appelgren <joh...@gm...> wrote:
> > > > On 5/11/05, Nat Pryce <nat...@gm...> wrote:
> > > > > On that topic, I've just about finished version 0.00000001 pre-al=
pha
> > > > > technology preview.  Anybody want to play with it and give feedba=
ck?
> > > > >
> > > > > Also, where should I check it in? And what shall we call it --
> > > > > nMock-2? jMock .NET? At the moment it's called SharpMock, but tha=
t's a
> > > > > crap name.
> > > > >
> > > > > --Nat.
> > > >
> > > > Did you check in the code somewhere? I'd like to take a look, and i=
f
> > > > possible give feedback :)
> > > >
> > > > /Johan
> > > >
> > >
> > >
> > >
> >
>

Re: [Nmock-general] Couple questions and suggestions

[<thi...@gm...>]

I agree with Mike on both points...

Thibaut

Re: [Nmock-general] Couple questions and suggestions

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

On 5/24/05, Nat Pryce <nat...@gm...> wrote:
> Currently NMock2 throws NUnit's AssertionException when it detects a
> test failure.  I can make it throw it's own exception
> (ExpectationException, say) so that it is entirely self contained.
>=20
> What do people think?

That seems a good idea to me. If NMock were to ever be a part of
NUnit, then ExpectationException could just be made to sub-class
AssertionException.

But for now, I think breaking the dependency would be good.

Mike

Re: [Nmock-general] Couple questions and suggestions

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

Currently NMock2 throws NUnit's AssertionException when it detects a
test failure.  I can make it throw it's own exception
(ExpectationException, say) so that it is entirely self contained.

What do people think?

On 5/23/05, Johan Appelgren <joh...@gm...> wrote:
> Thank you, I'll try and take a look at it during the week.
>=20
> Just opened the project to take a quick peek now and I noticed that
> the mock project depends on nunit. Do you plan to make it dependant on
> nunit?
>=20
> /Johan
>=20
> On 5/23/05, Nat Pryce <nat...@gm...> wrote:
> > I haven't had a chance to check it in anywhere public yet... hopefully
> > this week.  I've attached a zip of the latest code.  The attachment is
> > a normal ZIP archive.
> >
> > --Nat.
> >
> > On 5/23/05, Johan Appelgren <joh...@gm...> wrote:
> > > On 5/11/05, Nat Pryce <nat...@gm...> wrote:
> > > > On that topic, I've just about finished version 0.00000001 pre-alph=
a
> > > > technology preview.  Anybody want to play with it and give feedback=
?
> > > >
> > > > Also, where should I check it in? And what shall we call it --
> > > > nMock-2? jMock .NET? At the moment it's called SharpMock, but that'=
s a
> > > > crap name.
> > > >
> > > > --Nat.
> > >
> > > Did you check in the code somewhere? I'd like to take a look, and if
> > > possible give feedback :)
> > >
> > > /Johan
> > >
> >
> >
> >
>

[Nmock-general] SetupResult behavior and NMO-37 (indexed properties)

[<thi...@gm...>]

Hi,

I've been digging into nmock code this week end. I'd just like a
comment about how is SetupResult is supposed to work so I can really
understand what is intented.

Internally a SetupResult("methodName",xxx) after another
SetupResult("methodName") will simply void the effects of the first
call (as the key used to store the expectations is just the method
name, and previous setup will get erased).

This means that a dynamic mock with :
SetupResult("Item","InvokedWithIntParam",typeof(int))
SetupResult("Item","InvokedWithStringParam",typeof(string))
will always return "InvokedWithStringParam", whatsoever the type of
arguments passed.

This seems to be the cause of NMO-37

Is it what is expected ? At first sight I think we should have a key
based on the whole signature rather than just the method name here.


regards

Thibaut

Re: [Nmock-general] Couple questions and suggestions

[Johan A. <joh...@gm...>]

On 5/11/05, Nat Pryce <nat...@gm...> wrote:
> On that topic, I've just about finished version 0.00000001 pre-alpha
> technology preview.  Anybody want to play with it and give feedback?
>=20
> Also, where should I check it in? And what shall we call it --
> nMock-2? jMock .NET? At the moment it's called SharpMock, but that's a
> crap name.
>=20
> --Nat.

Did you check in the code somewhere? I'd like to take a look, and if
possible give feedback :)

/Johan

RE: [Nmock-general] Couple questions and suggestions

[John P. <Joh...@de...>]

I've attached the two files I changed (DynamicMock.cs and =
DynamicMockTest.cs) as well as a diff.  I'm new to this submitting =
thing, so if there's some other way you'd like this done in future, just =
let me know.

The fix changes the "checkReturnTypeIsValid" method, which now delegates =
to a "findReturnType" method.  If the mocked object is mocking an =
interface and the given method or property is not found in said =
interface, the method will traverse the interface's inheritance =
hierarchy looking for the method/property in any parents.

To be honest, I'm not sure why calling Type.GetMethod(...) on an =
interface as DynamicMock.cs was doing doesn't return inherited members =
in the first place, but this seems to fix the problem.

John.

-----Original Message-----
From: nmo...@li... =
[mailto:nmo...@li...] On Behalf Of Thibaut =
Barr=E8re
Sent: Monday, May 16, 2005 5:15 PM
To: John Price; Steve Freeman
Cc: nmo...@li...
Subject: Re: [Nmock-general] Couple questions and suggestions

> More generally, it's not really clear where the "official" source for
> information on NMock is.  Clicking on the "Tracker" link on NMock.org =
takes
> you to one bug tracking system, while another set of issues are =
tracked on
> SourceForge.  In general, the only reference the NMock.org page makes =
to
> SourceForge is for downloading source or binaries.

Steve, can't we just bring back the issues from sf to the Jira
tracker, and close the sf one ? Having the two trackers is really
confusing.

> Anyway, the reason I emailed Joe in the first place was that I ran =
into bug
> "NMO-44" as tracked by the JIRA bug tracker ("Using DynamicMock with
> inheriting interfaces throws NullReferenceException") and think that =
I've
> got a fix for it (and a unit test to check for it).  How can I go =
about
> submitting my change back to the project for review?

Can you post the patch + tests here if you didn't send it already to =
someone ?


Thibaut


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick
_______________________________________________
Nmock-general mailing list
Nmo...@li...
https://lists.sourceforge.net/lists/listinfo/nmock-general

Re: [Nmock-general] Couple questions and suggestions

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

> Steve, can't we just bring back the issues from sf to the Jira
> tracker, and close the sf one ? Having the two trackers is really
> confusing.

+1.  this is what we did on ccnet.  the sf trackers are pretty poor
and it is a headache to have to manage this in 2 places.  thibaut: do
you have sufficient access now to do this?

cheers,
owen.
--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Re: [Nmock-general] Couple questions and suggestions

[<thi...@gm...>]

> More generally, it's not really clear where the "official" source for
> information on NMock is.  Clicking on the "Tracker" link on NMock.org tak=
es
> you to one bug tracking system, while another set of issues are tracked o=
n
> SourceForge.  In general, the only reference the NMock.org page makes to
> SourceForge is for downloading source or binaries.

Steve, can't we just bring back the issues from sf to the Jira
tracker, and close the sf one ? Having the two trackers is really
confusing.

> Anyway, the reason I emailed Joe in the first place was that I ran into b=
ug
> "NMO-44" as tracked by the JIRA bug tracker ("Using DynamicMock with
> inheriting interfaces throws NullReferenceException") and think that I've
> got a fix for it (and a unit test to check for it).  How can I go about
> submitting my change back to the project for review?

Can you post the patch + tests here if you didn't send it already to someon=
e ?


Thibaut

[Nmock-general] NMO-37 - Indexers in c# are not working properly

[<thi...@gm...>]

If nothing has already been done for this one, I can look at it
(unless there are more critical issues)

Thibaut

Re: [Nmock-general] Couple questions and suggestions

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

That's fine with me. Your call.

S.

On 16 May 2005, at 22:15, Thibaut Barr=E8re wrote:
>> More generally, it's not really clear where the "official" source for
>> information on NMock is.  Clicking on the "Tracker" link on NMock.org=20=

>> takes
>> you to one bug tracking system, while another set of issues are=20
>> tracked on
>> SourceForge.  In general, the only reference the NMock.org page makes=20=

>> to
>> SourceForge is for downloading source or binaries.
>
> Steve, can't we just bring back the issues from sf to the Jira
> tracker, and close the sf one ? Having the two trackers is really
> confusing.
>
>> Anyway, the reason I emailed Joe in the first place was that I ran=20
>> into bug
>> "NMO-44" as tracked by the JIRA bug tracker ("Using DynamicMock with
>> inheriting interfaces throws NullReferenceException") and think that=20=

>> I've
>> got a fix for it (and a unit test to check for it).  How can I go=20
>> about
>> submitting my change back to the project for review?
>
> Can you post the patch + tests here if you didn't send it already to=20=

> someone ?
>
>
> Thibaut
>
>

Re: [Nmock-general] Couple questions and suggestions

[<thi...@gm...>]

> On that topic, I've just about finished version 0.00000001 pre-alpha
> technology preview.  Anybody want to play with it and give feedback?

yep, i'd love to

Re: [Nmock-general] Couple questions and suggestions

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

hi nat,
if you don't mind sending over the code, i can have a look at it and
get a better idea of where the best place to put it might be.
btw, if you include it under the current nmock cvs module then any
changes committed will get picked by the ccnet instance over on
http://ccnetlive.thoughtworks.com.  granted it won't build your
changes yet; i just wanted to let you know that the infrastructure is
in place to do so.
cheers,
owen.

On 5/13/05, Mike Roberts <mik...@gm...> wrote:
> On 5/11/05, Nat Pryce <nat...@gm...> wrote:
> > On that topic, I've just about finished version 0.00000001 pre-alpha
> > technology preview.  Anybody want to play with it and give feedback?
>=20
> Yup - count me in.
>=20
> > Also, where should I check it in? And what shall we call it?
>=20
> 'Susan' ? ;)
>=20
> If I were you I'd put it in a new tree in nmock for now. Just call it
> something completely random as a codename. But maybe not 'Susan'. Or
> 'Longhorn' - I think someone else got that one.
>=20
> Mike
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_ids93&alloc_id=16281&opclick
> _______________________________________________
> Nmock-general mailing list
> Nmo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-general
>=20


--=20
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com

Re: [Nmock-general] Couple questions and suggestions

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

On 5/11/05, Nat Pryce <nat...@gm...> wrote:
> On that topic, I've just about finished version 0.00000001 pre-alpha
> technology preview.  Anybody want to play with it and give feedback?

Yup - count me in.

> Also, where should I check it in? And what shall we call it?

'Susan' ? ;)

If I were you I'd put it in a new tree in nmock for now. Just call it
something completely random as a codename. But maybe not 'Susan'. Or
'Longhorn' - I think someone else got that one.

Mike