nunit-core team mailing list archive

[Adam Brengesjö <ca.brengesjo@xxxxxxxxx>]

Yea, I was inspired by your post and checked out the current
implementation and noticed that TimeSpan has tolerance constraints in
this way.

But I agree it would by far would be better if it was context aware by
using generics and the 'StrictDatetimeKind' (or what ever name) or the
current tolerance properties for that matter, was not not available if
not using the correct type.

But on the other hand, if comparing two System.Object, the equality
comparer should be able to detect that they are boxed value types, just
as the current implementation does. This is a drawback of generics.

-- 
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/1172247

Title:
  Improve DateTime equality assertions to include DateTimeKind

Status in NUnit V2 Test Framework:
  New

Bug description:
  The following test will fail, even if the two DateTime structs are not equal.
  (I know it's because the equality members of the DateTime type does the evaluation which doesn't care of the Kind property)

  [Test]
  public void Foo()
  {
      var localDate = new DateTime(2013, 04, 24, 13, 17, 44, 678, DateTimeKind.Local);
      var systemDate = new DateTime(2013, 04, 24, 13, 17, 44, 678, DateTimeKind.Utc);

      Assert.AreNotEqual(localDate, systemDate);
  }

  But I always extracts my assertions to a helper method which also
  checks the Kind property.

  public static class AssertX
  {
      public static void AreEqual(DateTime expected, DateTime actual)
      {
          Assert.AreEqual(expected, actual);
          Assert.AreEqual(expected.Kind, actual.Kind);
      }
  }

  I would like to have NUnit help me with this instead of always calling
  my own helper class.

  However, I'm not sure how this best could be implemented in NUnit.
  A simple overload of AreEqual(object, object) to AreEqual(DateTime, DateTime) risk breaking compability with existing tests out there.

  One way would be to instead use another name, Assert.Identical or
  similar.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nunitv2/+bug/1172247/+subscriptions