Einheitentestbeschränkungen und NUnit-Syntaxhelfer verstehen

Question

Ich und ein Kollege beginnen ein neues Projekt und versuchen, TDD voll auszunutzen. Wir sind noch dabei, alle Konzepte rund um Komponententests herauszufinden und stützen uns dabei hauptsächlich auf andere Beispiele.

Mein Kollege hat kürzlich den Sinn der NUnit-Syntax-Helfer in Frage gestellt und ich bemühe mich, ihren Nutzen zu erklären (da ich es selbst nicht wirklich verstehe, außer mein Bauch sagt, dass sie gut sind!). Hier ist ein Beispiel Behauptung:

Assert.That(product.IsValid(), Is.False); 

Für mich durchaus Sinn macht, wir sagen, wir der Wert von product.IsValid() erwarten false zu sein. Mein Kollege auf der anderen Seite würde uns lieber einfach schreiben:

Assert.That(!product.IsValid()); 

Er sagt ihm dies mehr Sinn macht, und er kann es leichter lesen.

Bis jetzt können wir uns nur darauf einigen, dass Sie wahrscheinlich mehr hilfreiche Ergebnisse erhalten, wenn der Test nicht erfolgreich ist, aber ich denke, dass es eine bessere Erklärung geben muss. Ich habe einige Informationen zu den Syntax-Helfern (http://nunit.com/blogs/?p=44) gelesen und sie sind sinnvoll, aber ich verstehe das Konzept der Einschränkungen nicht, außer dass sie sich richtig fühlen.

Ich frage mich, ob jemand erklären könnte, warum wir das Konzept der Constraints verwenden, und warum sie die Unit-Test-Beispiele oben verbessern?

Danke.

Answer 1

Ich denke, es ist vor allem mit der reinen englischen Lesung der Aussage zu tun.

Die erste liest

Assert, dass das Produkt gültig falsch ist

Der zweite

Assert liest das nicht Produkt

gültig ist, ich persönlich finde das erste einfacher zu verarbeiten. Ich denke, es hängt alles von der Vorliebe ab. Einige der Erweiterungsmethoden gibt, sind interessant aber, dass können Sie tun Sie Behauptungen wie folgt aus:

product.IsValid().IsFalse(); 

Answer 2

ich Ihre Version ist besser als Ihre Kollegen sehen können. Aber ich würde immer noch mindestens so bequem mit:

Assert.IsFalse(product.IsValid()); 

Wenn Sie mich davon überzeugen können, dass die Assert.That Syntax einen objektiven Vorteil gegenüber dem oben hat, wäre ich sehr interessiert sein :) Es kann auch nur Kraft von Gewohnheit, aber ich kann sehr leicht lesen "Welche Art von Behauptung machen wir? Nun, worüber behaupten wir es?" Stil.

Answer 3

Es ist alles Zucker. Intern werden sie in Constraints konvertiert.

Von Pragmatische Unit Testing, S. 37:

„2 NUnit.4 führte eine neue Art von Assertionen ein, die etwas weniger prozedural sind und eine objektorientierte Implementierung ermöglichen. ... Zum Beispiel:

Assert.That(actual, Is.EqualTo(expected)); 

Wandelt zu:

Assert.That(actual, new EqualConstraint(expected));" 

Einschränkungen auch ermöglicht es Ihnen, von Constraint zu erben und Ihre eigenen benutzerdefinierten Einschränkung erstellen (s), während eine einheitliche Syntax zu halten.

Answer 4

Ich mag Assert.That, insbesondere die Tatsache, dass das häufigste Szenario (Vergleich der Gleichheit zweier Objekte) messbar schlechter als die "klassische" Assert.AreEqual() -Syntax ist.

Auf der anderen Seite, ich liebe die MSpec NUnit Erweiterungen. Ich empfehle Ihnen, sie zu überprüfen (oder schauen Sie sich die SpecUnit-Erweiterungen oder NBehave Erweiterungen oder N Behave Spec * Unit-Erweiterungen, ich denke, sie sind alle gleich).