Re: [NMock2-Dev] Re: mocking interface with generic list property

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

I agree that this should be part of the standard set of constraints.=20
Perhaps there should be constraints for dictionaries too.  I merged a
patch into jMock recently that contributed useful constraints for
collections and dictionaries, so you can specify that a parameter is
an element of a list, or is a key of a dictionary, etc.  Very useful
for keeping tests flexible.

--Nat.

On 3/2/06, Joe Poon <joe...@gm...> wrote:
> i agree with mike on the definition of two lists being equal.
>
> as i imagine this is the most common definition, i'd find it convenient i=
f a
> built-in ListMatcher (perhaps like the one mike has in the tutorial) was =
the
> default matcher used by nmock2 when comparing two lists.  and in the
> scenario where order doesn't matter, bring on the custom matcher.
>
> - joe
>
>
> On 3/1/06, Mike Mason <mik...@gm...> wrote:
> >
> > On 3/1/06, Joe Ross <joe...@gm... > wrote:
> >
> >
> >
> > > I'm not involved in the development of NMock2 obviously, but the
> > > question I raise is whether or not everyone's definition of two lists
> > > being equal is the same.  My definition for my purpose was that each
> > > list contained the same items in the same order.  Someone else might
> > > only care about the same items being in each list but not necessarily
> > > the same order.  I realize there is also a SortedList<T> in .NET 2.0,
> > > but I want to use List<T> and add the objects in the correct order
> > > based on business logic
> >
> >
> >
> > Well to me, if I'm using a List I would say I did care about order of
> items. If I didn't care, I'd use a Set or a Bag. Problem is neither of th=
ose
> are built-in types for .NET (which is an entirely different rant ;-) ).
> >
> > I was just thinking that "check lists are not null, same size, and each
> object in turn .Equals() the corresponding object in the other list" is a
> piece of code most people are gonna end up writing, so maybe we should
> provide it.
> > Cheers,
> >
> > Mike.
> >
>
>