Kürzlich wurde ein neues Konzept von Theorien zu JUnit hinzugefügt (seit v4.4).
Kurz gesagt, können Sie Ihre Testmethode mit @Theory annotation (anstelle von @Test ) markieren, Ihre Testmethode parametrisieren und ein Array von Parametern deklarieren, die mit @DataPoints annotation irgendwo in derselben Klasse markiert sind.
JUnit führt Ihre parametrisierte Testmethode nacheinander aus, wobei Parameter, die von @DataPoints abgerufen wurden, nacheinander übergeben werden. Aber nur bis der erste Aufruf fehlschlägt (aus irgendeinem Grund).
Das Konzept scheint sehr ähnlich zu @DataProviders von TestNG zu sein, aber wenn wir Datenprovider verwenden, werden alle Szenarien trotz ihrer Ausführungsergebnisse ausgeführt. Und es ist nützlich, weil Sie sehen können, wie viele Szenarios funktionieren / nicht funktionieren und Sie Ihr Programm effektiver reparieren können.
Also, ich frage mich, warum nicht @Theory -markierte Methode für jedes @DataPoint ausführen soll? (Es scheint nicht so schwer zu sein, von Theories Läufer zu erben und einen eigenen Runner zu erstellen, der Fehler ignoriert, aber warum haben wir kein solches Verhalten?)
UPD : Ich habe eine fehlertolerante Version von Theories runner erstellt und für einen öffentlichen Zugriff verfügbar gemacht: Ссылка
Um es mit dem standardmäßigen Theories Runner StandardTheoriesBehaviorDemo zu vergleichen, dann FaultTolerantTheoriesBehaviorDemo, die unter src/test/... Ordner liegen.
Das Melden mehrerer Fehler in einem einzelnen Test ist normalerweise ein Zeichen dafür der Test macht zu viel, verglichen mit dem, was ein Komponententest tun sollte. Normalerweise bedeutet das entweder, dass der Test wirklich ein ist Funktions- / Akzeptanz- / Kundentest oder, wenn es sich um einen Komponententest handelt, dann ist ein zu großer Unit-Test.
JUnit wurde entwickelt, um mit einer Reihe von kleinen Tests zu funktionieren. Es Führt jeden Test in einer separaten Instanz der Testklasse aus. Es meldet Fehler bei jedem Test. Freigegebener Setup-Code ist am natürlichsten, wenn Teilen zwischen den Tests. Dies ist eine Designentscheidung, die JUnit durchdringt, Wenn Sie sich dazu entscheiden, mehrere Fehler pro Test zu melden, beginnen Sie damit Kampf gegen JUnit. Dies wird nicht empfohlen.
Lange Tests sind ein Designgeruch und zeigen die Wahrscheinlichkeit eines Designs an Problem. Kent Beck sagt in diesem Fall gerne, dass "es ein Gelegenheit, etwas über Ihr Design zu erfahren. "Wir würden gerne Eine Mustersprache entwickelt sich um diese Probleme, hat sie aber nicht noch geschrieben worden. Quelle: Ссылка
Um Assertionsfehler zu ignorieren, können Sie auch eine JUnit-Fehlerkollektorregel verwenden:
Die ErrorCollector-Regel ermöglicht die Ausführung eines Tests, um danach fortzufahren das erste Problem wird gefunden (zum Beispiel, um alle falschen zu sammeln Zeilen in einer Tabelle, und melden Sie alle auf einmal)
Zum Beispiel können Sie einen solchen Test schreiben.
%Vor%Der Error Collector verwendet hanccrest Matchers. Abhängig von Ihren Vorlieben ist das positiv oder nicht.
AFAIK, die Idee ist die gleiche wie bei behauptet, der erste Fehler stoppt den Test. Dies ist der Unterschied zwischen parametrisierten & amp; Theorien.
Parametrisiert verwendet eine Reihe von Datenpunkten und führt mit ihnen eine Reihe von Testmethoden aus. Theories macht das gleiche, scheitert aber, wenn die erste Assert fehlschlägt.
Sehen Sie sich Parametrisiert an. Vielleicht bietet es, was Sie wollen.
Tags und Links java junit testng dataprovider