ShouldBeEquivalentTo failing for equivalent objects when the subject is a DateTime

Question

What I'm trying to do

I've just set up a test to ensure that a NodaTime LocalDateTime is mapped to a .NET DateTime, retaining the same date and time values. I'm using FluentAssertions' ShouldBeEquivalentTo method to compare the corresponding property values.

[TestClass]
public class LocalDateTimeMapping
{
    [TestMethod]
    public void RetainsComponentValues()
    {
        var nodatimeTime = new LocalDateTime();
        var dotnetTime = nodatimeTime.ToDateTimeUnspecified();

        dotnetTime.ShouldBeEquivalentTo(nodatimeTime,
            o => o
                .Including(d => d.Year)
                .Including(d => d.Month)
                .Including(d => d.Day)
                .Including(d => d.Hour)
                .Including(d => d.Minute)
                .Including(d => d.Second)
                .Including(d => d.Millisecond)
        );
    }
}

The problem

The test is failing:

Expected subject to be 01/01/1970 00:00:00, but found <1970-01-01>.

With configuration:
- Select property System.DateTime.Year
- Select property System.DateTime.Month
- Select property System.DateTime.Day
- Select property System.DateTime.Hour
- Select property System.DateTime.Minute
- Select property System.DateTime.Second
- Select property System.DateTime.Millisecond
- Match property by name (or throw)
- Invoke Action<DateTime> when info.RuntimeType.IsSameOrInherits(System.DateTime)
- Invoke Action<String> when info.RuntimeType.IsSameOrInherits(System.String)

I don't know what the last two lines mean.

What I've tried

Running the test in the debugger to confirm that the values of each of these were the same.
Seeing if the problem was a specific property by removing the Includes for the different properties.
Basing the configuration on EquivalencyAssertionOptions<DateTime>.Empty() to ensure that no extra checks or properties were implicitly involved.

Simplifying it all down to just the following.

dotnetTime.ShouldBeEquivalentTo(nodatimeTime,
    o => EquivalencyAssertionOptions<DateTime>.Empty()
);

I'm not familiar with FluentAssertions... it's a shame it doesn't show *which* property differed (or what else was wrong). Is there any way of getting it to provide more information? — Jon Skeet, Nov 29 '13 at 15:52
@JonSkeet, I think it normally does give you a specific error. It seems that this particular situation might be an exception. — Sam, Dec 01 '13 at 22:24
ShouldBeEquivalentTo() is intended to be used for comparing complex object graphs rather than the primitive types part of the .NET framework. That specific action at the end of the exception report is meant to say that for DateTime properties it will use the built-in DateTime-specific assertions. So apparently one of the selected properties is of type DateTime. — Dennis Doomen, Dec 02 '13 at 08:21
@DennisDoomen, in the code in my question, none of the selected properties were of type `DateTime`. Does that mean there is a bug in FluentAssertions, or am I misunderstanding what you mean? — Sam, Dec 03 '13 at 20:10
No, but you are invoking the ShouldBeEquivalentTo() method on a DateTime rather than on a complex type. I never meant to support that. — Dennis Doomen, Dec 04 '13 at 06:54
@DennisDoomen, it seems to work OK for `LocalDateTime`, which is also a `struct`. Anyway, thanks for clarifying that this is by design. I suggest this be treated as a design flaw or bug since I think it's unintuitive. It'd be interesting to see what other users of the library think. — Sam, Dec 05 '13 at 01:18
It's not about being a `struct`, it's because we treat DateTime as a primitive for which FA contains dedicated assertions. — Dennis Doomen, Dec 05 '13 at 05:17
But I see your point, there's currently no way to clear those default assertion rules. — Dennis Doomen, Dec 05 '13 at 05:25

Ryan · Answer 1 · 2019-10-10T13:48:17.007

3

You can compare datetimes with fluent assertions, they have added lots of nice methods to chain it up now:

https://fluentassertions.com/datetimespans/

e.g.

theDatetime.Should().BeLessThan(10.Minutes()).Before(otherDatetime);

edited Oct 10 '19 at 13:48

answered Oct 25 '17 at 12:28

Ryan

2,109
1
15
19

The link is no longer available. – Tar Dec 30 '18 at 12:02

score 2 · Accepted Answer · answered Dec 01 '13 at 22:28

The following line from the error message indicated that some sort of special treatment was being given to the DateTime:

Invoke Action<DateTime> when info.RuntimeType.IsSameOrInherits(System.DateTime)

I tried swapping the two date-times I was comparing, and this resolved the problem:

nodatimeTime.ShouldBeEquivalentTo(dotnetTime,
    o => o
        .Including(d => d.Year)
        .Including(d => d.Month)
        .Including(d => d.Day)
        .Including(d => d.Hour)
        .Including(d => d.Minute)
        .Including(d => d.Second)
        .Including(d => d.Millisecond)
);

So I conclude that ShouldBeEquivalentTo should not be called on a .NET DateTime.

Maybe you can fix this with the `WithAutoConversion` option? Or maybe Fluent Assertions version 5.0 would fix this? https://fluentassertions.com/objectgraphs/#auto-conversion — JohnB, Sep 24 '20 at 19:37

ShouldBeEquivalentTo failing for equivalent objects when the subject is a DateTime

What I'm trying to do

The problem

What I've tried

2 Answers2

Linked