Comparing datatables with dbnull in expectation doesn't cause test to fail when subject has a value

Description

Comparing DataTables where a column in the expectation containing a dbnull value passes comparison regardless of the value in the same column in the subject.

Complete minimal example reproducing the issue

// Arrange
var expected = new DataTable();
expected.Columns.AddRange(new[] 
{ 
    new DataColumn("Column1", typeof(string)), 
    new DataColumn("Column2", typeof(string)), 
    new DataColumn("Column3", typeof(string)) 
});

expected.Rows.Add("test", null, "1" );

// Act
var actual = new DataTable();
actual.Columns.AddRange(new[] 
{
    new DataColumn("Column1", typeof(string)),
    new DataColumn("Column2", typeof(string)),
    new DataColumn("Column3", typeof(string))
});
actual.Rows.Add("test", "fail", "1");

// Assert
actual.Should().BeEquivalentTo(expected);

Expected behavior:

The test to fail because “Column2” in the expectation is null while it has a value of “fail” in the subject

Actual behavior:

The test passes. Reversing the order leads to the test failing as expected, i.e.,

// Assert
expected.Should().BeEquivalentTo(actual);

fails.

Versions

• Which version of Fluent Assertions are you using? 6.7.0
• Which .NET runtime and version are you targeting? .NET 6

Additional Information

Any additional information, configuration or data that might be necessary to reproduce the issue.

[dennisdoomen]

The reason for this is that DbNull.Value is a singleton which does not override Equals. You can call Equals on it, but it will defer to the default object.Equals implementation, which will use reference equality. Since Value always returns the same instance, comparing it to itself will work. Because of this behavior, our HasValueSemantics extension method will not treat it as a value type and thus tell BeEquivalentTo to treat it as a complex type. But since the DbNull instance doesn’t have properties or fields, nothing will happen.

You can work around this by using the ComparingByValue<DBNull>() option, but the default formatter won’t make the message very nice:

Expected property actual.Value to be , but found "fail".

So maybe we should treat DbNull as something special?

[Corniel]

Although I personally hardly use DbNull.Value at all (anymore), I think the types deserves a special treatment. You could even argue that objects (including new object()) that do not have properties should always be treated as value types.