The issue with null enumerables is fixed, in r3323.

On 11 April 2012 19:29, Graham Hay <[email protected]> wrote:

> Yes, that does sound like a bug. We should handle null collections
> appropriately. Could you raise an issue 
> here<http://code.google.com/p/mb-unit/issues/entry>,
> please?
>
> I wonder if we could improve the API, to make it more obvious to use a
> child comparer for collections?
>
>
> On 11 April 2012 10:27, Michal Levý <[email protected]> wrote:
>
>> Hello again
>>
>> As any workaround i was able to come with seemed very cumbersome, i dig
>> in the documentation and found out StructuralEqualityComparer  Add method
>> has overload which uses Accessor returning IEnumerable !
>> So i changed last part of my comparer to this:
>>
>> { x => x.Data, new StructuralEqualityComparer<FsDataDTO>()
>>                     {
>>                         { x => x.Items, new
>> StructuralEqualityComparer<FsItemDTO>
>>                             {
>>                                 x => x.ItemId,
>>                                 x => x.Value
>>                             }
>>                         },
>>                         { x => x.FreeItems,new
>> StructuralEqualityComparer<FsFreeItemDTO>()
>>                             {
>>                                 x => x.ItemName,
>>                                 x => x.ParentItemId,
>>                                 x => x.Value
>>                             }
>>                         }
>>                     }
>>                 }
>>
>> Now i have another problem.
>> In some cases, those collections can by NULL and
>> StructuralEqualityComparer fails on such case with NullReferenceException
>>
>> System.NullReferenceException: Object reference not set to an instance of
>> an object.
>> at
>> MbUnit.Framework.StructuralEqualityComparer`1.CompareEnumerables[TValue](IEnumerable`1
>> xEnumerable, IEnumerable`1 yEnumerable, EqualityComparison`1 comparer) in
>> c:\Server\Projects\MbUnit
>> v3.3\Work\src\MbUnit\MbUnit\Framework\StructuralEqualityComparer.cs:line 475
>> at
>> MbUnit.Framework.StructuralEqualityComparer`1.<>c__DisplayClassa`1.<Add>b__7(T
>> x, T y) in c:\Server\Projects\MbUnit
>> v3.3\Work\src\MbUnit\MbUnit\Framework\StructuralEqualityComparer.cs:line 469
>> at System.Collections.Generic.List`1.TrueForAll(Predicate`1 match)
>> at System.Collections.Generic.List`1.TrueForAll(Predicate`1 match)
>>
>> This does seem as bug to me....
>>
>> Michal
>>
>>
>> On Wednesday, April 11, 2012 8:04:43 AM UTC+2, Michal Levý wrote:
>>>
>>> Hello
>>>
>>> Im currently using nightly build 3.3.668.0 x86
>>>
>>> Trying to test some Web services results. Those are not so complex
>>> objects with strict schema so comparing current response with one
>>> serialized on disk in XML and deserialized during the test was natural
>>> choice.
>>> I like the idea of StructuralEqualityComparer so i decided to give it a
>>> try. Everything worked nice until i added collections into the mix.
>>>
>>> Here is my comparer:
>>>
>>> protected readonly IEqualityComparer<**FinancialStatementDTO>
>>> FinancialStatementComparer = new StructuralEqualityComparer<**
>>> FinancialStatementDTO>
>>>             {
>>>                 { x => x.ClientInfo, new StructuralEqualityComparer<**
>>> ClientInfoDTO>
>>>                     {
>>>                         x => x.CisId,
>>>                         x => x.AdditionalInfo
>>>                     }
>>>                 },
>>>                 { x => x.Header, new StructuralEqualityComparer<**
>>> FinancialStatementHeaderDTO>
>>>                     {
>>>                         x => x.Id,
>>>                         x => x.Year,
>>>                         x => x.Month,
>>>                         x => x.EconomicMonth,
>>>                         x => x.FormatIdent,
>>>                         x => x.TypeIdent,
>>>                         x => x.CurrencyIdent,
>>>                         x => x.CreateDate,
>>>                         x => x.Note
>>>                     }
>>>                 },
>>>                 { x => x.Data, new StructuralEqualityComparer<**
>>> FsDataDTO>()
>>>                     {
>>>                         *// unfortuanately doesnt work*
>>>                         x => x.Items,
>>>                         x => x.FreeItems
>>>                     }
>>>                 }
>>>             };
>>>
>>> Problem is last comparer. x.Items and x.FreeItems are arrays of objects.
>>> Test result is always: *Both values look the same when formatted but
>>> they are distinct instances.*
>>> Documentation says *Although the equality 
>>> assertions<http://www.gallio.org/wiki/doku.php?id=mbunit:assertions:equality>work
>>>  nicely with enumerations natively, you may find more convenient to use
>>> the dedicated collection 
>>> assertions<http://www.gallio.org/wiki/doku.php?id=mbunit:assertions:collection>
>>> *Doesn't seem to me like "working nicely". Both objects are same for
>>> sure (comparing XML serialised instances as text) but MbUnit seems to still
>>> using identity comparison....
>>>
>>> I would like to use collection assertions but problem is that equality
>>> comparison logic contained in those cannot be used outside those assertions
>>> (for example in structural comparer)
>>>
>>> Any idea?
>>> Thx
>>>
>>> Michal
>>>
>>> **
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "MbUnit.User" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/mbunituser/-/Kzz-SSE217gJ.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/mbunituser?hl=en.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"MbUnit.User" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/mbunituser?hl=en.

Reply via email to