EqualConstraint provides inadequate failure information for IEnumerables
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
NUnit Framework |
Fix Released
|
High
|
Charlie Poole | ||
NUnit V2 |
Fix Released
|
High
|
Charlie Poole |
Bug Description
When an EqualConstraint compares two IEnumerables and one of them is _not_ a collection, the failure reported inadequately. This was called to our attention by the following post on nunit-discuss by Gishu Pillai but applies more generally than the post indicates.
Given any CustomType containing a Data (int) property and Name
(string) property. Equals and ToString overridden
var someArray = new[] { "A001", "B002", "C003" };
someArray);
Expected and actual are both <System.String[3]>
Values differ at index [0]
Expected string length 1 but was 4. Strings differ at index 0.
Expected: "x"
But was: "A001"
-------
Which is perfect. But now if any of the arguments to AreEqual are a
result of a Linq query, the failure message drops in readability
var someArray = new[] { "A001", "B002", "C003" };
someArray.
Expected: < "x", "Y", "Z" >
But was: <System.
+WhereSelectArr
-------
Even worse
'C'}.Select(
"Dog"}.
Expected: <System.
+WhereSelectArr
But was: <System.
+WhereSelectArr
if you change the 'C' to 'D' - the test passes as expected.
I've been trying to write something similar for my custom-adaptation
of Hamcrest and I think I see what is happening (an are-types-
compatible check failing for IEnumerable<T> and IEnumerable<K>) .
However if CollectionAsser
ToArray() before processing its arguments, I think the error messages
would be much more helpful.
Changed in nunitv2: | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → Charlie Poole (charlie.poole) |
milestone: | none → 2.6.0b1 |
status: | Triaged → Fix Committed |
Changed in nunitv2: | |
status: | Fix Committed → Fix Released |
Changed in nunit-3.0: | |
milestone: | none → 2.9.6 |
Changed in nunit-3.0: | |
assignee: | nobody → Charlie Poole (charlie.poole) |
Changed in nunit-3.0: | |
status: | Triaged → Fix Committed |
Changed in nunit-3.0: | |
status: | Fix Committed → Fix Released |
The fix in NUnit 2.6 is somewhat adhoc. NUnit 3.0 needs a better fix after the Constraint class refactoring is done.
Note that an IEnumerable may not be repeatable, so it's important to save the failing value rather than re-fetching it as we do in the case of a collection.