Perché Assert.Areequal (1.0, Double.nan, 1.0) passa?

Question

Breve domanda, perché lo fa Assert.AreEqual(1.0, double.NaN, 1.0) passaggio? Invece Assert.AreEqual(1.0, double.NaN) non riesce.

È un bug in MSTEST (Microsoft.VisualStudio.qualityTools.UnittestFramework) o mi manca qualcosa qui?

Cordiali saluti, Egil.

---

AGGIORNAMENTO: dovrebbe probabilmente aggiungere, che il motivo alla base della mia domanda è che ho un sacco di test unitari che purtroppo sono passati a causa del risultato di alcune operazioni di matrice algebrica lineare che sono NAN o (+/-) infinito. I test unitari vanno bene, ma dal momento che Assert.Areequal On Doubles With a Delta passerà quando gli effettivi o/e previsti sono nan o infiniti, sono stato lasciato a credere che il codice che stavo testando fosse corretto.

Answer 1

Stai attento. NAN è strano, un po 'nullo in molti DBMS, e non dovresti confrontare i valori con esso (direttamente o con Assert.Areequal). Dai documenti per Double.nan:

Usa ISNan per determinare se un valore non è un numero. Non è possibile determinare se un valore non è un numero confrontandolo con un altro valore pari a NAN.

double zero = 0;
Console.WriteLine((0 / zero) == Double.NaN);  // prints false
Console.WriteLine(Double.IsNaN(0 / zero));  // prints true

Dovresti scrutare gli interni di Assert (doppio, doppio) per vedere cosa sta succedendo, ma in generale, dipendi dal comportamento indefinito rispetto a NAN.

Answer 2

Le risposte sono obsolete. Se il bug è stato risolto, quando e in quali versioni di quale assembly?

È corretto, è stato risolto in VS2013 con Microsoft.VisualStudio.qualitytools.unittestFramework.dll Assembly, versione 10.0.0.0. Presente nel GAC legacy, C: Windows Assembly, ha anche la versione 10.1.0.0.

C'è una storia DLL Hell qui, la versione 10.1.0.0 è stata quella utilizzata in VS2010. Aveva il bug, non controllava correttamente il doppio.nan. Microsoft ha commesso un errore, hanno risolto 10.1.0.0 ma non hanno modificato il numero di versione. Quindi chiunque abbia installato VS2010 dopo L'installazione di VS2013 si farà male, sovrascriverà la DLL con la versione buggy.

Svelare DLL Hell è mai così semplice, ma appare dal Connetti l'articolo E dal modo in cui funziona sulla mia macchina che hanno identificato la modalità di errore dal reclamo del cliente. E fornito una correzione, consegnata in un aggiornamento. Non è chiaro quale, dopo luglio 2014. Ora utilizzerai v10.0.0.0, il runner di test MSTEST.EXE e i QTagents hanno un file .Config con A <bindingRedirect> che reindirizza da 10.1.0.0 a 10.0.0.0 (non un errore di battitura). Assicurati di ottenere l'ultimo aggiornamento, attualmente 4. Cerca l'aiuto + se non sei sicuro di quale aggiornamento hai installato.

Per il record, il codice fisso ha acquisito controlli specifici per Double.nan, sembra così:

public static void AreEqual(double expected, double actual, double delta, string message, params object[] parameters)
{
    if ((double.IsNaN(expected) || double.IsNaN(actual)) || double.IsNaN(delta))
    {
        string str = (string) FrameworkMessages.AreEqualDeltaFailMsg((message == null) ? string.Empty : ReplaceNulls(message), expected.ToString(CultureInfo.CurrentCulture.NumberFormat), actual.ToString(CultureInfo.CurrentCulture.NumberFormat), delta.ToString(CultureInfo.CurrentCulture.NumberFormat));
        HandleFail("Assert.AreEqual", str, parameters);
    }
    if (Math.Abs((double) (expected - actual)) > delta)
    {
        string str2 = (string) FrameworkMessages.AreEqualDeltaFailMsg((message == null) ? string.Empty : ReplaceNulls(message), expected.ToString(CultureInfo.CurrentCulture.NumberFormat), actual.ToString(CultureInfo.CurrentCulture.NumberFormat), delta.ToString(CultureInfo.CurrentCulture.NumberFormat));
        HandleFail("Assert.AreEqual", str2, parameters);
    }
}

Answer 3

MStest utilizza la seguente formula per Assert.AreEqual<double>(expected, actual, delta) metodo:

if (Math.Abs(expected - actual) > delta)
    Assert.HandleFail("Assert.AreEqual", ...)

L'operazione si riduce a double.NaN > delta, che restituisce vero in questo caso. O indefinito.