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