it-swarm.com.de

Unit-Tests: Aufgeschobene Aussagen mit Linq

Ist es in Ordnung, solche zurückgestellten Behauptungen hinzuzufügen?

var actualKittens = actualKittens.Select(kitten => {
    Assert.IsСute(kitten);
    return kitten
});

Warum? So kann ich auch mit Anweisungen, die eine materialisierte Sammlung erwarten, nur einmal iterieren, zum Beispiel:

CollectionAssert.AreEquivalent(expectedKittens, actualKittens.ToList());

Und es könnte auch nicht nur Select sein, sondern eine Methode, bei der ein Iterator definiert ist und viele Überprüfungen und Logik aufweist (z. B. etwas Zählen und Filtern).

Der Grund für Zweifel ist die Komplexität des Lesens und Debuggens eines solchen Codes im Falle eines fehlgeschlagenen Tests.

18
SerG

Ist es in Ordnung, zurückgestellte Behauptungen wie diese hinzuzufügen [..]

Nein ist es nicht. Warum? Wenn Sie aus irgendeinem Grund die zweite Behauptung entfernen, wird der Test immer noch grün und Sie würden denken, dass er immer noch funktioniert, aber nicht, da die Sammlung nicht aufgezählt wird. Wenn Sie zwei oder mehr unabhängige Behauptungen haben, werden sie Ich mache ihre Arbeit weiter, auch wenn Sie einen von ihnen deaktivieren.

Betrachten Sie diese Kombination:

Assert.IsTrue(actualKittens.All(x => x.IsCute());
CollectionAssert.AreEquivalent(expectedKittens, actualKittens.ToList());

Selbst wenn Sie eine der Zusicherungen deaktivieren oder entfernen, würde die andere ihre Arbeit trotzdem erledigen. Auch wenn Sie vergessen , die Sammlung zu materialisieren, kann die Ausführung länger dauern, aber sie funktioniert weiterhin. Unabhängige Tests sind robuster und zuverlässiger.

Es gibt auch eine Sekunde nein. Ich bin nicht sicher, wie andere Frameworks damit umgehen, aber wenn Sie die MS Test-Plattform verwenden, wissen Sie nicht, welcher Test fehlgeschlagen ist. Wenn Sie auf den fehlgeschlagenen Test doppelklicken, wird das CollectionAssert als fehlgeschlagen angezeigt. In Wirklichkeit ist jedoch das verschachtelte Assert schiefgegangen, und das Debuggen ist äußerst schwierig. Hier ist ein Beispiel:

    [TestMethod]
    public void TestMethod()
    {
        var numbers = new[] { 1, 2, 3 }.Select(x =>
        {
            Assert.Fail("Wrong number.");
            return x;
        });

        // This will fail and you won't be sure why.
        CollectionAssert.AreEqual(new[] { 1, 2, 3 }, numbers.ToList()); 

    }

Dies bedeutet, dass der erste Test tatsächlich nutzlos ist, da es nicht hilft, einen Fehler zu finden. Sie wissen nicht, ob es fehlgeschlagen ist, weil eine Nummer ungültig war oder weil beide Sammlungen unterschiedlich waren.


Warum? So kann ich auch mit Aussagen, die eine materialisierte Sammlung erwarten, nur einmal iterieren

Ich frage mich, warum es dich interessiert. Dies sind Unit-Tests. Sie müssen nicht jedes einzelne davon optimieren, und für Tests sind normalerweise nicht Millionen von Elementen erforderlich, sodass die Leistung kein Problem darstellen sollte.

Sie müssen solche Tests beibehalten. Warum sollten Sie sie komplexer als nötig gestalten? Schreiben Sie einfache Behauptungen, die funktionieren.

37
t3chb0t