Error message when DateTime is not equal does not provide any help about fsunit HOT 4 CLOSED

Is this not the goal of the "equal" assertion failure message?

FsUnit nor any other testing framework does this. They only execute the ToString() (or something similar) to have stringified values.
Especially in the implementation of NUnit FsUnit just consumes the NUnit constraints here: https://github.com/fsprojects/FsUnit/blob/master/src/FsUnit.NUnit/Equality.fs#L23

Anyway, this is not reasonable to do for us. We cannot implement every format for every specific type that has a "special" format.

Sorry for that.

from fsunit.

Many database (or thair drivers) store the datetime with the precision of milliseconds.
That is not enough when the original DateTime is written and then read back to guarantee the "equality".
The following is an example of a DateTime saved and read back on MongoDB 3.x:

DateTime differs only for fraction of milliseconds.

from fsunit.

Hey @alex-piccione,
I see the problem. I think the root cause is the underlaying .NET type system.

Let me figure it out:
When you create a DateTime variable you get a date which you already see in your 2nd post with all the seconds, milliseconds and ticks etc..

Now, you want to test your record and the type system checks the types if they match and the values if they match, too. Values of the two DateTimes don't match and stringifies it to build a message with it.
The format is just %A, in this result the code is like:
let date = System.DateTime.UtcNow in printfn "%A" date
the output is: 04.02.2022 08:09:59 (differs with culture, doesn't matter here)
You see, that milliseconds are not included.

My recommendation: Restructure your test(s) to test your DateTimes manually with milliseconds.
The result from your code above will be:

item.D.ToString "dd.MM.yyyy HH:mm:ss.ffff" 
|> should equal (expectedItem.D.ToString "dd.MM.yyyy HH:mm:ss.ffff")

The summary of the output window will be:

Message: 
  String lengths are both 24. Strings differ at index 20.
  Expected: "04.02.2022 08:26:53.1455"
  But was:  "04.02.2022 08:26:53.0355"
  -------------------------------^

I hope that helps.

(P.S.: This could also be the solution for #200.) Just comment if you need further help with it.

from fsunit.

Hi, Thanks for the reply.
I know that I can manually test the dates equality in a way that provides a meaningfull message, but I think it should automatically be done by the simple assertion:
actual |> should equal expected.

Is this not the goal of the "equal" assertion failure message? or it is not reasonable to do?
I have a lot of them, not just this one. Also, other items have more DateTime properties, not just one.
I need to use a simple "equal", sometime I created a function to do a custom equal, (e.g. "equalMyItem"), but I have enough to reinvent the wheel everytime... I need a generic one.
The best solution (for me) is to create my version/copy of "equal" (still not sure it is this one that creates the message, I need to find out).

Thanks.

from fsunit.