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
>