nunit-core team mailing list archive

[Simone Busoli <1172247@xxxxxxxxxxxxxxxxxx>]

Before giving up I would wait to see if Charlie has a different opinion on
the topic.


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

> The reason why we don't use DateTimeOffset is simple - we develop for the
> .NET Compact Framework.
> (The testing is however actually done in 'desktop' .NET, referencing CF
> assemblies, but we minimize the use of emulator/device tests to increase
> speed in our development since deployment is painfully slow. Only
> pinvokes/other platform dependant tests is done in emulator).
>
> And you are right, it is not difficult to do custom assertions, either by
> Assert.That or other ways.
> Well I won't argue. And if this isn't a obvious fit for NUnit, you are a
> better judge of that than I.
>
> --
> 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