Expected/actual values are not precise enough for BCL types

[drieseng]

The format that is used to produce the expected and actual components of an assertion failure message does not provide enough precision.
This leads to non-informative failure messages such as:

Assertion failed. Expected values to be equal.

expected: 09/06/2026 13:12:21
actual:   09/06/2026 13:12:21

To reproduce, compile and run the following test:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public sealed class DateTimeTest
{
    [TestMethod]
    public void DateTime_AreEqual_TicksNotEqual()
    {
        var d1 = DateTime.Now;
        var d2 = DateTime.Now.AddTicks(1);

        Assert.AreEqual(d1, d2);
    }
}

This "issue" applies to DateTime and DateTimeOffset, but I'm sure it applies to other types as well.
Would you consider using another (type-specific) format, eg. "O" for DateTime?
Alternatively, MSTest could be configured with specific "formatters".

[Evangelink]

Hi @drieseng,

Thank you for the dogfood and for reporting the problem early! I am considering this as a bug as it's impacting capacity to properly understand easily failure.

[Evangelink]

Confirmed — still reproducible on main. The root cause is that the RFC-012 structured-assertion renderer (AssertionValueRenderer.RenderValue) falls back to value.ToString() for any type other than string/bool/char/IEnumerable. For BCL types like DateTime/DateTimeOffset/TimeSpan/DateOnly/TimeOnly/float/double/decimal the default ToString() either truncates precision (e.g. DateTime to seconds), uses the current culture (e.g. , decimal separator under fr-FR), or both — so two values that differ by a few ticks or one ULP render identically in the failure message.

Fix in #8964: add type-specific, full-precision, culture-invariant arms to the central RenderValue switch ("O" for date/time types, "c" for TimeSpan, "R" for float/double, CultureInfo.InvariantCulture everywhere). Since every assertion that uses structured messages funnels through this one method, the fix is centralized.

[Youssef1313]

@Evangelink type/bug label got re-created. That doesn't sound right.

[Evangelink]

@Evangelink type/bug label got re-created. That doesn't sound right.

On it, thanks!