10 Stimmen

Visual Studio Unit Test: warum Testlauf nicht schlüssig während der Prüfung der gleichen Float-Werte?

Ich lerne VS Unit Test und versuchte dies:

    [TestMethod()]
    public void calcTest()
    {
        double expected = 1.234F; // TODO: Initialize to an appropriate value
        double actual;
        actual = 1.234F;
        Assert.AreEqual(expected, actual);
        Assert.Inconclusive("Verify the correctness of this test method.");
    }

Wenn ich diese Testmethode ausführe, heißt es "nicht schlüssig". Warum?

Aktualisieren: Man kann sagen, dass man Floats nicht vergleichen sollte, aber die geschäftlichen Anforderungen sind, was sie sind. Was sollte ich also tun, wenn ich sie vergleichen muss?

Meinen Sie, dass es unmöglich ist, eine fließende Berechnung ohne Kopfschmerzen zu testen? Wenn das Testen von Finanzberechnungen so viel Kopfzerbrechen bereitet, ist es dann nicht besser, überhaupt nicht zu testen?

Scheint wie ein großer Fehler oder Design-Fehler in vs Test-Framework eher :) wie es hier gesagt wird http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.inconclusive%28VS.80%29.aspx

Zeigt an, dass eine Behauptung weder als wahr noch als falsch bewiesen werden kann.

Da ich 2 gleiche Wurfsendungen vergleiche, ist es sicher wahr.

1 Stimmen

Die Microsoft-Unit-Test-Suite enthält jetzt auch überladene Methoden zum Testen von Gleitkommazahlen (und Doubles) durch Übergabe einer Delta-Toleranz, die angibt, wie gleich die Werte sein müssen, um zu bestehen ( msdn.microsoft.com/de-us/library/ms243456.aspx ). Wird so verwendet: Assert.AreEqual(float expected, float actual, float delta, string failingTestMessage)

17voto

Marc Gravell Punkte 970173

Ähm, weil Sie es so wollten?

Assert.Inconclusive("Verify the correctness of this test method.");

Jetzt haben Sie Ihre AreEqual sollten Sie diese entfernen können Inconclusive

Jede Fehler während eines Tests (mit Ausnahme von Ausnahmen, die Sie absichtlich behandeln) sind in der Regel endgültig, aber jede Behauptung, die geht (wie die AreEqual hier) läuft einfach weiter. Der erste Test ist also erfolgreich, aber die letzte Zeile zeigt an, dass er nicht schlüssig ist.

0 Stimmen

Warum gibt es Assert.Conclusive nicht? Wir führen keine statistischen Tests durch, bei denen eine solche Unschlüssigkeit sinnvoll wäre, sondern es handelt sich um deterministische Tests, bei denen das Testergebnis ja oder nein lautet.

0 Stimmen

Ich denke, Sie haben Recht, aber die Vorlage sollte nicht setzen dies als Standard in Code-Schnipsel, weil dies sehr verwirrend ist.

1 Stimmen

@user310291 Aus der Sicht des Testens ist das nicht verwirrend. Alle Tests schlagen fehl, bis Sie entweder den richtigen Test schreiben (und den nicht schlüssigen Teil entfernen) oder den zu testenden Code korrigieren.

8voto

ChrisF Punkte 130622

Auch wenn Sie die Assert.Inconclusive könnten Sie trotzdem Probleme haben.

Sie testen die Gleichheit von zwei Fließkommazahlen und im Allgemeinen mit berechneten Werten du wirst sie nie bekommen genau dasselbe. Sie müssen prüfen, ob der tatsächliche Wert innerhalb eines akzeptablen Bereichs des erwarteten Werts liegt:

Math.Abs(actual - expected) < 0.00001;

zum Beispiel.

Ihr Assert.AreEqual(expected, actual); funktioniert in diesem Fall, weil Sie beiden Variablen denselben Wert zuweisen.

1 Stimmen

Gute Warnung, aber in diesem Fall vergleicht er zwei Variablen, die aus Literalen initialisiert wurden, also würde ich erwarten dass es in Ordnung ist. Aber +1, auf jeden Fall ein sehr guter Punkt, den man ansprechen sollte!

0 Stimmen

@Marc - Ich habe das bemerkt und eine entsprechende Anmerkung hinzugefügt.

0 Stimmen

Die Tatsache, dass es für bestimmte Dezimalzahlen keine exakten Gleitkommadarstellungen gibt, macht sie nicht "unscharf". Der allgemeine Punkt, dass 2 Gleitkommazahlen nicht auf Gleichheit verglichen werden sollten, ist gut, aber er trifft in diesem Fall nicht zu: Es gibt keinen Grund, warum der Compiler unterschiedliche double Vertretungen für die dieselbe float wörtlich.

2voto

Jon Skeet Punkte 1325502

Bedeutet das nicht einfach, dass die AreEqual bestanden, was bedeutete, dass sie Assert.Inconclusive die zu einem Ergebnis von "nicht schlüssig" führt?

Desde die Dokumente :

Ähnlich wie bei Fail, da es anzeigt dass eine Behauptung nicht schlüssig ist, ohne Bedingungen zu prüfen.

Wenn Sie nicht wollen, dass das Ergebnis inklusive ist, entfernen Sie den Aufruf von Assert.Inconclusive :)

0 Stimmen

Mein Punkt ist, dass es mathematisch und aus geschäftlicher Sicht sicher nicht nicht schlüssig ist, sondern schlüssig, da es wahr ist :)

0 Stimmen

Assert.Inconclusive Methode Gibt an, dass eine Behauptung nicht als wahr oder falsch bewiesen werden kann.

0 Stimmen

2voto

Shikeh Punkte 21

Der automatische UnitTest wird von VS generiert und weist Sie an, einige Operationen zum Vergleich zu erstellen. Wenn Sie den letzten Assert-Befehl kommentieren, erhalten Sie "Passed" mit grüner Markierung, aber Sie haben es nicht getestet.
Sie brauchen, wie im Kommentar, "Initialize to an appropriate value" und wie im letzten Assert "Verify the correctness of this test method".
Initialisieren Sie die erwarteten und die tatsächlichen Werte von dort, wo sie herkommen z.B. Erwarteter Wert ist der erwartete Wert der Funktion Add(x,y) mit x=2 und y=3. Der tatsächliche Wert sollte aus der Funktion stammen. in diesem Fall:

// Sample - Start
Expected = 2+3;
Actual = Add(2,3);
Assert.AreEqual(expected, actual);
// Sample - End

Hoffentlich hat es geholfen, ich habe mir dafür ein paar Zähne gebrochen... ;-)

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X