2013-04-18 2 views
26

Was bevorzugen:Assert.that vs Assert.True

Assert.That(obj.Foo, Is.EqualTo(true)) 

oder

Assert.True(obj.Foo) 

Für mich beide behauptet äquivalent sind, so welche sollte man lieber sein?

+2

'obj.Foo.Should(). BeTrue();' http://fluenassertions.codeplex.com/ (Es spielt keine Rolle, was Sie verwenden, solange es lesbar ist und dem Leser liefert, was Sie zu erreichen versucht haben) –

+0

https://twitter.com/jamesiry/status/74127537562857472 –

+0

Assert hat keine "That" -Methode, woher kommt das? – usefulBee

Antwort

15

In diesem speziellen Fall gibt es keinen Unterschied: Sie sehen die Ausgabe von ungefähr der gleichen Detailstufe (d. H. Es sagt Ihnen, dass etwas, das true ausgewertet wurde, auf false ausgewertet wurde). Das Gleiche gilt für

Assert.IsTrue(obj.Foo); 

und

Assert.That(obj.Foo, Is.True); 

Ihr Team eine Art von Behauptungen wählen sollte, und bleiben Sie dabei in allen Ihren Tests. Wenn Ihr Team den Stil Assert.That bevorzugt, sollten Sie Assert.That(obj.Foo, Is.True) verwenden.

+0

FWIW, unsere Firma geht mit Assert.That, damit Ihre Tests mehr wie Sätze lesen können. Sie würden wahrscheinlich beide Behauptungen lesen als "Stellen Sie sicher, dass obj.Foo wahr ist", was buchstäblich genau so ist, wie die zweite Behauptung geschrieben wird. – EJay

2

Das ist ein bisschen pingelig, aber IMHO Ich denke, dass in diesem Fall Assert.That ist unnötig ausführlich und kann daher als Verschleierung angesehen werden. Mit anderen Worten, Assert.True ist ein wenig sauberer, einfacher und einfacher zu lesen und daher zu verstehen.

Um ein wenig mehr nit-picky bekomme ich die Assert.IsTrue API würde vorschlagen, statt Assert.True da wieder IMHO, IsTrue „liest“ besser.

3

Also ok, Sie haben Ihre Testsuite auf dem CI-Server ausgeführt und leider ist einer von ihnen ausgefallen. Sie öffnen die Protokolle und nächste Nachricht

BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false 

nun sehen, wie auf der Erde würden Sie bekommen, was mit dieser Tests falsch passiert, wenn die alle Informationen, die Sie sehen, ist, dass irgendwo in AutoLoginTests Bool wurde wahr erwartet, aber falsch erhalten? Jetzt müssen Sie zur Quelldatei Ihrer Testfälle gehen und sehen, welche Assertion fehlgeschlagen ist. Sie sehen

Assert.True(obj.Foo) 

Erstaunlicher .. es immer noch schwer zu sagen, was falsch ist, nur, wenn Sie dieses Modul 1 Stunde entwickelt vor. Sie müssen noch tiefer in Testquellen und wahrscheinlich Produktionsquellen gehen oder sogar Ihren Code debuggen, damit Sie endlich herausfinden können, dass Sie eine Variable im Funktionsaufruf falsch geschrieben haben oder falsches Prädikat verwendet haben, um registrierte Benutzer zu filtern. Somit haben Sie die sofortige Rückmeldung von Tests blockiert, was sehr wertvoll ist.

Mein Punkt ist, dass es egal ist, wie fließend Ihre Behauptungen sind (die auch relevant sind), aber welche Informationen Sie im Falle von versagenden Tests und wie schnell können Sie den zugrunde liegenden Grund des Scheiterns, selbst wenn Sie erhalten arbeitete vor langer Zeit mit dieser Funktion

+0

Sie haben völlig Recht. Dies war nur die Frage nach dem Stil. Es sollte eine korrekte Ausgabe geben, wenn eine Assertion den Fehler nicht leicht finden kann. – Razer

10

Assert.That heißt die Constraint-basierte Modell. Es ist flexibel, da die Methode einen Parameter IConstraint Typ verwendet. Dies bedeutet, dass Sie Ihren Code mit einer generischeren Hierarchie oder einer aufrufenden Struktur strukturieren können, indem Sie alle alten IConstraint übergeben. Es bedeutet, Sie können Ihre eigenen custom constraints

Das ist ein Design-Problem. Wie alle sagen, egal, was Sie noch brauchen, um anständige Fehlermeldung Rückmeldung zu geben.

+0

Gute kurze Erklärung, was ist Constraint-basierte Assertion-Modell. –

Verwandte Themen