Asserting Setup und Vorbedingungen in Unit Tests

Ist mehr als ein Assert pro Test einen wirklich schlechten Geruch? Ich versuche normalerweise, das Muster "arrangiere, handle, bestätige" sowie die Richtlinie für einzelne Tests pro Test zu befolgen. Ich denke, saubere, kleine, isolierte Tests zu haben, ist pure Ehrfurcht. Zum größten Teil gelingt mir das. Aber manchmal finde ich mich „Vorbedingungen“ gleich nach meinem arrangieren wie so behauptet:Asserting Setup und Vorbedingungen in Unit Tests

'arrange: 
'pre-conditions:  
    Assert the arrange worked 
'act: 
'assert:

Ist mein Test Tests zu viel? Kümmert es sich um Dinge, die es nicht interessieren sollte? Ich würde gerne einige Meinungen dazu hören.

Quelle

2010-08-31 Buzzer

mögliche Duplikate von [Ist es schlechte Praxis, mehr als Assert in einem Komponententest zu haben?] (Http://stackoverflow.com/questions/762512/is-it-bad-practice-to-have-more-than -Asssert-in-a-unit-test) –

Ich glaube nicht, dass dies ein Duplikat ist, wenn man es aus der Perspektive des Validierens von Test-Fixture-Setup im Vergleich zu mehreren Asserts zum Validieren von Ergebnissen ansieht. Es kann hilfreich sein, die Frage umzubenennen, um dies zu berücksichtigen. – Jay

Ich werde umbenennen, um den Vorschlag zu reflektieren. @Carl Manaster: Super Bart Typ! – Buzzer

Wie gesagt here, ich denke, vielleicht unsere beste Praxis sollte sein, nicht Arrange-Act-Assert, sondern Arrange-Angenommen -Act-Assert. Wir behaupten vor Acting, dass das gewünschte Ergebnis der Aktion noch nicht in Kraft ist. Dies ist nicht genau das gleiche wie das, was Sie fragen; Generell halte ich es nicht für wichtig, das Setup zu verifizieren, da sich Setup-Fehler ohnehin eher "laut" manifestieren; aber es ist ein guter Grund, eine zweite Behauptung im Test zu haben.

Quelle

2010-08-31 13:55:32

Ich denke, Assert zu verwenden, um das Setup zu validieren ist suboptimal, da es die Ergebnisse matschig macht (es könnte schwierig sein herauszufinden, was Sie testen, wenn Sie nur die Ausgabe betrachten).

Ich erkenne, dass es Zeiten gibt, in denen das nötig ist, oder du einfach nur sicherstellen willst, dass alles so getestet wird, wie du es vorhast.

Meine Praxis ist, zu diesem Zweck Debug.Assert (in C#) zu verwenden, damit die Setup-Validierung nicht Teil der Testausgabe wird.

Sie könnten dasselbe in anderen Sprachen erreichen, indem Sie eine Ausnahme auslösen, wenn das Setup das System nicht in einen erwarteten Zustand versetzt.

Verschiedene Testläufer können dies anders handhaben, daher sollten Sie sicherstellen, dass dieser Ansatz den gewünschten Effekt hat (Tests fehlschlagen, aber keine zusätzliche Berichtausgabe, solange Debug.Assert bestanden oder keine Ausnahme ausgelöst wird).

Quelle

2010-08-31 13:36:10 Jay

All dies sind großartige Antworten. Allerdings wähle ich Jay's, weil ich mag, wie Debug.Assert im Test liest. Danke noch einmal. – Buzzer

Ich würde nicht eine Vanille "Assert" dafür verwenden, sondern Assert.Inconclusive (MSTest) ¹. Der Test ist nicht fehlgeschlagen, daher möchten Sie den Testlauf nicht abbrechen.

1) Assume in JUnit und NUnit glaube ich.

Quelle

2010-09-01 12:51:31

Link zu [Assert.Inconclusive] (http://msdn.microsoft.com/en-us/library/ms243750.aspx) –

Vielen Dank Derek, aktualisiert die Antwort. –

Asserting Setup und Vorbedingungen in Unit Tests

Antwort

Verwandte Themen