Null reference exception when using custom comparer in equivalency options #2595
Comments
|
What happens if you change |
|
@ITaluone If I change, it does not use the comparer at all. If you change in my example, it will work, because it will compare two nullble DateTimes with the default way, but in the real project I have custom comparer, and it is not used in case it is of using NUnit.Framework;
namespace UnitTests;
public class FluentAssertionsEquivalencyFailureTest
{
[Test]
public void Success()
{
var expected = new TestClass();
var actual = new TestClass() { NullableField = DateTime.UtcNow };
FluentActions.Invoking(() => actual.Should().BeEquivalentTo(expected))
.Should()
.Throw<AssertionException>()
.WithMessage("Expected property actual.NullableField to be <null>, but found <*>.*");
}
[Test]
public void NullReferenceFailure()
{
var expected = new TestClass();
var actual = new TestClass() { NullableField = DateTime.UtcNow };
FluentActions.Invoking(() => actual.Should().BeEquivalentTo(expected, o => o.Using(EqualityComparer<DateTime>.Default)))
.Should()
.Throw<AssertionException>()
.WithMessage("Expected property actual.NullableField to be <null>, but found <*>.*");
}
[Test]
public void TestToShowThatNullableDateTimeComparerIsNotUsed()
{
var dateTimeValue1 = DateTime.UtcNow;
var dateTimeValue2 = new DateTime(dateTimeValue1.Ticks + 1, dateTimeValue1.Kind);
var expected = new TestClass() { NullableField = dateTimeValue1 };
var actual = new TestClass() { NullableField = dateTimeValue2 };
FluentActions.Invoking(() => actual.Should().BeEquivalentTo(expected, o => o.Using(CustomNullableDateTimeComparer.Instance)))
.Should()
.NotThrow();
// Did not expect any exception, but found NUnit.Framework.AssertionException with message
// "Expected property actual.NullableField to be <2024-03-04 06:48:49.3389094>, but found <2024-03-04 06:48:49.3389095>.
}
[Test]
public void CustomNullableDateTimeComparer_Works()
{
var dateTimeValue1 = DateTime.UtcNow;
var dateTimeValue2 = new DateTime(dateTimeValue1.Ticks + 1, dateTimeValue1.Kind);
CustomNullableDateTimeComparer.Instance.Equals(dateTimeValue1, dateTimeValue2).Should().BeTrue(); //ok
var hashCode1 = CustomNullableDateTimeComparer.Instance.GetHashCode(dateTimeValue1);
var hashCode2 = CustomNullableDateTimeComparer.Instance.GetHashCode(dateTimeValue2);
hashCode1.Should().Be(hashCode2); //ok
}
}
public class CustomNullableDateTimeComparer : IEqualityComparer<DateTime?>
{
public static readonly CustomNullableDateTimeComparer Instance = new();
private const long TicksEpsilon = 1000;
private static DateTime? Round(DateTime? x) =>
x is null ? null : new DateTime(x.Value.Ticks / TicksEpsilon * TicksEpsilon);
public bool Equals(DateTime? x, DateTime? y) => Round(x).Equals(Round(y));
public int GetHashCode(DateTime? obj) => Round(obj).GetHashCode();
}
public class TestClass
{
public DateTime? NullableField { get; set; }
}To put it in a nutshell,
|
|
The test named |
|
The reason the test named The first thing it does is making sure the types match. if (comparands.GetExpectedType(context.Options) != typeof(T))
{
return EquivalencyResult.ContinueWithNext;
}In the current scenario, the types being compared are From my point of view, the fix would be to modify the right part of the if (comparands.GetExpectedType(context.Options) != typeof(T).NullableOrActualType())
{
return EquivalencyResult.ContinueWithNext;
} |
|
There are a couple of things that I think might be wrong here:
So this bug need two individual fixes. |
|
Sorry for the confusion, but with the current state of |
Description
Look at the code below. The second test fails with unexpected NRE.
I'm using the latest alpha version:
7.0.0-alpha.3.Net 6
Reproduction Steps
For reproduction please look at the description - there is a code sample which reproduces the error.
Expected behavior
Expected that the second test behaves exactly like the first.
Actual behavior
Unexpected NRE is thrown.
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response
Are you willing to help with a pull-request?
No
The text was updated successfully, but these errors were encountered: