Asserts for DateTime do not take into account the Kind

[drieseng]

Summary

When asserting DateTime values, the Kind is not taken into account.

Background and Motivation

In our asserts, we want a comparison of two DateTime values to take into account the Kind.
This is current not the case as DateTime ignores any difference on that level in its implementation of Equals (and its operators).

To reproduce, compile and run test following test:

using System;

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public sealed class DateTimeTest
{
    [TestMethod]
    public void DateTime_AreNotEqual_KindNotEqual()
    {
        var d1 = new DateTime(1973, 08, 13, 00, 00, 00, DateTimeKind.Local);
        var d2 = new DateTime(1973, 08, 13, 00, 00, 00, DateTimeKind.Utc);

        Assert.AreNotEqual(d1, d2);
    }
}

Expected result:

Test should pass.

Actual result:

Assertion failed. Expected values to differ.

notExpected: 13/08/1973 00:00:00
actual:      13/08/1973 00:00:00

Proposal

I don't suppose you'll want to modify the behavior of MSTest as it could break existing tests.
I therefore see two alternate solutions:

1. We implement extensions methods for DateTime.
2. MSTest supports specifying custom "comparers" (each for a distinct type).

Do you see other options?

[Youssef1313]

There should be an overload that takes IEqualityComparer<T>. I think this is the right way here.

[drieseng]

Hm, ok. The only issue I see with this approach is that the failure message will not be actionable unless you include the Kind in the string you produce for expected/actual.

If not, we'll again get failure messages stating that the expected and actual are not equal (or equal), but both values in the message will be equal.

[Evangelink]

@drieseng I think the output will now be improved/fixed (thanks to your other issue - see PR #8964).

I think we could also offer some new analyzer (opt-in) that would report on 2 date times used without explicit comparison. I am saying opt-in because that would be hard to tune it so that it's always adding value. Let me know if that's interesting for you, otherwise I'll close as completed.

[drieseng]

@Evangelink the output will indeed be much improved. It was something that I've been wanting to submit for a few years, but never did as I was sure it would not be accepted. Thanks a lot for taking the feedback to heart!

Feedback on your proposal:

1. I'm not sure a lot of people want to take the Kind of a DateTime into considering when evaluating equality.
   An opt-in analyzer would indeed force those that enable it to be explicit as to how they want the comparison to be performed.
2. If someone (like us) want to use a comparison that takes into account the Kind of a DateTime, he'll still end up with failure messages that show both the expected and the actual as "equal" if only the Kind differs.

I only see two options:

• We introduce a extension method for Assert or a custom asserter that uses a custom comparer that also takes into account the Kind to determine whether expected and actual are equal and throws an AssertFailedException with a custom message that outputs the expected and actual with full precision and their respective Kind.
• MSTest somehow supports a custom formatter for specific types. I'm sure I'm pushing my luck proposing this :p

[Evangelink]

@Evangelink the output will indeed be much improved. It was something that I've been wanting to submit for a few years, but never did as I was sure it would not be accepted. Thanks a lot for taking the feedback to heart!

Please always feel free to suggest or ask anything here! With @Youssef1313 we are really fighting to get feedback and discussions with our users so we can provide the best value!

Feedback on your proposal:

I am not 100% sure to understand your point here. When passing the 2 dates, the new output will be:

Assertion failed. Expected values to differ.

notExpected: 1973-08-13T00:00:00.0000000+02:00
actual:      1973-08-13T00:00:00.0000000Z

Assert.AreNotEqual(d1, d2)

This is clearly showing a difference, allowing you to investigate.

As pointed out by Youssef, you do have the overload that takes a custom comparer. Is your question being "please ship a DateTimeKindAwareEqualityComparer (or similar) so we don't all have to roll our own."?

MSTest somehow supports a custom formatter for specific types. I'm sure I'm pushing my luck proposing this :p

I don't think you are. Are you thinking about somthing similar to https://docs.nunit.org/articles/nunit/writing-tests/TestContext.html#addformatter-32?
This is something I had in mind for some time and I wanted to first get the full rewrite of the style of our assertions (which is done already).

[Evangelink]

I've opened #9089 with a concrete proposal for the custom value formatter angle — scoped registration via AsyncLocal anchored on the test context (method / class / assembly), modeled on NUnit's TestContext.AddFormatter but exposed on Assert for discoverability. That issue intentionally covers the rendering half only; the equality half is already covered by the existing Assert.AreEqual<T>(T, T, IEqualityComparer<T>) / Assert.AreNotEqual<T>(T, T, IEqualityComparer<T>) overloads, which lets you wire your own Kind-aware comparer.

Combined with the rendering improvements from #8964 (failure now shows 1973-08-13T00:00:00.0000000+02:00 vs ...Z, so the Kind difference is visible) and the formatter API once #9089 ships, you would be able to:

1. Define a KindAwareDateTimeComparer : IEqualityComparer<DateTime> once in your test infra and pass it to Assert.AreEqual / Assert.AreNotEqual.
2. Register a custom DateTime formatter in [AssemblyInitialize] that renders Kind exactly the way your team wants (e.g. 1973-08-13T00:00:00 [Utc]).

Would that cover your needs here, @drieseng? If yes, I'll close this issue in favor of #9089 (plus the still-open opt-in analyzer idea, which can land as a separate issue if there is appetite).

[drieseng]

I totally f***d up my earlier comment. I forgot that the "O" format will also output the time zone offset (or Z for UTC) in case of DateTime.

For what I'm concerned, it's ok to close this issue. I'll go for the custom comparer in combination with the rendering changes in #8964.

Again, thanks for listening!