Should be available soon in v3.2.254 and later ( http://ccnet.gallio.org/Distributables/)
2010/3/9 Yann Trevin <[email protected]> > Scott, > > Assert.Equal should now support equality tests between multidimensional > arrays. The assertion fails when: > > - Ranks are different (their type being different, it will fail > anyway), > - Dimensional lengths are different, > - Or of course, when the contents of the arrays differ. > > However, I wonder whether we should extend Assert.AreElementsEqual to > support T[,] and T[,,] as well. Even if it's clearly documented in the > wiki, I guess that the average user might expect to find multidimensional > array support in Assert.AreElementsEqual rather than in Assert.Equal. > > In the other hand, it's just a corner case and we can live with it. > > Regards, > Yann. > > > > > Regards, > Yann > > 2010/3/9 Jeff Brown <[email protected]> > > I agree, let's abandon System.Array. Three dimensions should be enough for >> the vast majority of people. >> >> There is another trick here though. Notice that Assert.AreEqual and >> Assert.AreElementsEqual behave identically when the operands are two arrays. >> >> So if the correct logic is implemented in ComparisonSemantics, then you >> should be able to Assert.AreEqual arrays of any number of dimensions. >> >> With that in mind, perhaps it's not worth implementing overloads for >> Assert.AreElementsEqual given that Assert.AreEqual will work just as well >> and be just as typesafe. We could document the case on >> Assert.AreElementsEqual and on the wiki to guide people over there. >> >> Jeff. >> >> On Mon, Mar 8, 2010 at 11:27 PM, Yann Trevin <[email protected]>wrote: >> >>> The main problem I see with System.Array is that we will get "ambiguous >>> invocation" warnings when using AreElementsEqual&co with unidimensional >>> arrays. >>> >>> On the other hand, with T[,] and T[,,], we force the user to compare >>> arrays with the same rank already (but I don't know if this is really an >>> issue). The number of supported dimensions is also limited to 2 and 3 (but >>> I'm not sure it's an issue neither) An advantage of the generic version is >>> that we can report easily the exact coordinates of the failing elements. >>> >>> I think we should abandon System.Array. >>> >>> Agree? >>> >>> >>> 2010/3/9 Yann Trevin <[email protected]> >>> >>> Jeff, >>>> >>>> I'm not sure whether we should get stick with System.Array like in v2, >>>> or make several more specific but generic overloads with T[,] and T[,,] >>>> . >>>> >>>> What do you think? >>>> >>>> >>>> >>>> 2010/3/8 Jeff Brown <[email protected]> >>>> >>>>> Beware that you might encounter subtle problems if you reference both >>>>> MbUnit v2 and MbUnit v3 assemblies at the same time. Gallio will try to >>>>> run >>>>> tests using both MbUnit v2 and MbUnit v3. Normally there is no conflict >>>>> but >>>>> it could confuse some things like the ReSharper plugins. >>>>> >>>>> >>>>> Jeff. >>>>> >>>>> >>>>> On Mon, Mar 8, 2010 at 1:31 PM, Scott Williams >>>>> <[email protected]>wrote: >>>>> >>>>>> > > For now, use OldCollectionAssert in the MbUnit.Compatibility.dll. >>>>>> These >>>>>> > > are basically the old MbUnit v2 asserts wrapped up in a form that >>>>>> MbUnit v3 >>>>>> > > can handle. >>>>>> >>>>>> Thank you, this is working fine. I had also figured out how to setup >>>>>> an extern alias to be able to reference both v2 and v3 mbUnit >>>>>> assemblies at one time, but the MbUnit.Compatibility.dll is a better >>>>>> solution. >>>>>> >>>>>> -- >>>>>> 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]<mbunituser%[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]<mbunituser%[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]<mbunituser%[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]<mbunituser%[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.
