StructuralEqualityComparer<T> from MbUnit *always* returns TRUE under NUnit tests

[savornicesei]

Issue by sbohlen
Monday Jan 12, 2015 at 14:29 GMT
Originally opened as NDbUnit#59

---

Common base class for Integration tests https://github.com/NDbUnit/NDbUnit/blob/master/test/NDbUnit.Test/IntegationTestBase.cs relies upon the StructuralEqualityComparer<T> class from MbUnit to compare the "contents" of the actual vs. expected datasets for all of the integration tests. Under the MbUnit test-runner this functioned as expected (passing the tests if the contents of the two datasets were "the same" and failing them if they were found to differ).

Disappointingly, NUnit offers no functional equivalent for MbUnit's StructuralEqualityComparer<T>. When moving to NUnit for the tests, it seemed reasonable to retain the reference to MbUnit's StructuralEqualityComparer<T> and to "reuse" it in the NUnit asserts. Since StructuralEqualityComparer<T> implements IComparable<T>, etc., it should seemingly have been possible to leverage StructuralEqualityComparer<T> in NUnit's equality, etc. asserts along the lines of the following:

Assert.That(dataset1, Is.EqualTo(dataset2).Using(new StructuralEqualityComparer<DataSet>()));

Unfortunately, while this seems like an entirely valid use of StructuralEqualityComparer<T>, I've now discovered that this doesn't function as expected. Unfortunately StructuralEqualityComparer<T> returns TRUE no matter what values are compared when the tests are run under NUnit. This means that these tests presently all potentially return false-positives (pass when they shouldn't).

I've discovered that even the following clearly failing test actually still passes under NUnit...

var comparer = new StructuralEqualityComparer<string>();
var s1 = "hello";
var s2 = "world";
Assert.That(s1, Is.EqualTo(s2).Using(comparer));

Rather than try to troubleshoot what's wrong with StructuralEqualityComparer<T> under NUnit, I think the better course of action is to implement a specialized capability in NDbUnit directly that is capable of properly evaluating dataset "contents" equality.

Rather than creating this as an additional custom assert (which would unnecessarily tie it to NUnit) I'm instead thinking that this will probably take the form of an extension method on the DataSet type along the lines of ...

dataset1.HasSameDataAs(dataset2)

...which will just return a bool. This approach would make using these extension methods in test asserts, etc. the most flexible, along the lines of...

Assert.That(dataset1.HasSameDataAs(dataset2), Is.True);

...or even just the shorter form...

Assert.That(dataset1.HasSameDataAs(dataset2));

Longer term, this approach would also support a more useful feature for NDbUnit that would support comparing two datasets and reporting on their differences as part of a test-run for user test code using NDbUnit in tests where the failed assertion could eventually be made to contain a detailed list of the DIFFGRAM between the two datasets.

This could potentially support much more granular test failure reporting along the lines of the following ...

Table User, Row1: Expected FirstName="Steve" but was FirstName="Joe"
Table User, Row7: Expected Age=12 but was Age=45

[savornicesei]

Comment by sbohlen
Monday Jan 12, 2015 at 18:29 GMT

---

After some further thought on this (and the poss. scope/complexity of the comparison task) I'm now thinking that it might be simpler to just use https://comparenetobjects.codeplex.com/ for this job...