nunit-core team mailing list archive

[Simone Busoli <1172247@xxxxxxxxxxxxxxxxxx>]

Hi Adam,

I can very well see your point, but my opinion is that there is a very
clear difference between asserting over the equality of two arrays and that
of two datetimes.
In the first case the behavior you expect from NUnit is obvious*, and it is
indeed the very same reason why you would use NUnit over the .NET default
implementation (which does reference comparison). In the second case there
is no obvious behavior that NUnit could carry out, as I mentioned in my
previous comment, in which case it makes more sense to simply fall back to
the default .NET comparison (which ignores the Kind property).
Rather than either providing users with an unsafe safety net - since
there's no obvious way to implement DateTime comparison - or introducing
breaking changes I would rather let developers realize that when they care
about time zones they should use DateTimeOffset rather than DateTime.

Frankly speaking I can see a single option to support this behavior that I
would not dislike, which is to have a modifier similar to "CompareKind" on
assertions involving DateTime, but this in turn would require generic
assertions that we don't have in NUnit. Do not forget that you can write
your own assertions and use them in the Assert.That flavor of the assertion
syntax or supply your own comparer to equality assertions.

*recursive data structures are one exception

Simone


On Wed, Apr 24, 2013 at 5:19 PM, Adam Brengesjö <ca.brengesjo@xxxxxxxxx>wrote:

> I agree. Breaking changes is a *major* concern.
>
> >Besides that I'm not sure it would be sensible to compare
> >DateTimes using a logic different from that of the default .NET
> >implementation, it might be confusing for users.
>
> Initially that was my thought too.
> But NUnit does other comparisons different from .NET, like when comparing
> arrays.
> .NET will simply evaluate them as different, while NUnit compares each
> element (which I really love and is one of the features that kicks MSTest's
> butt....)
>
>
> I can see your point. And I wish I could provide a more obvious case. I'm
> just hoping other could benefit from this.
>
> I discovered this after tracking down a bug where (I later concluded)
> * a handheld device re-constructed datetimes from the database without
> setting Kind
> * which lead to the communication layer omitting the time offset...
> * which caused the server to parse the time as local...
> * which led to a incorrect utc time being written to the database...
> * which caused the web to supply the browser with a incorrect time...
> * which had the web javascript add incorrect time offset when displaying
> the timestamp...
>
> After I changed well over 2000 DateTime assertions in the test suite,
> about 5% of them failed because the the Kind property was not set or not
> what was expected.
>
> Of course, this was not caused by NUnit, but as a framework, NUnit should
> help sloppy (or unknowing) developers from making common, but not so
> obvious, mistakes.
> And this is a rather... unintuitive feature of .NET... which I belive is a
> case where NUnit could prove very helpful to developers (which NUnit
> already is btw in so many other cases).
>
> --
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~nunit-core
> Post to     : nunit-core@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~nunit-core
> More help   : https://help.launchpad.net/ListHelp
>

-- 
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