___ qstntxt ___
Ich habe versucht, mit einem einfachen Code mit %code% 2 Anwendungsfälle zu bestätigen. Im ersten Anwendungsfall gebe ich 2 ungleiche Werte an, die %code% korrekt sind.
Aber im zweiten Anwendungsfall, wenn ich 2 ungleiche Werte innerhalb des try-catch-Blocks bestätige, wird das Ergebnis immer als %code%
zurückgegeben
Mein Code ist wie folgt:
%Vor%
Das Ergebnis, das ich bekomme, ist:
%Vor%
Meine Frage ist:
- In test2 () obwohl die Assertion fehlschlägt, warum kommt die Ausführung nicht aus dieser %code% ?
- In test2 () scheint es, dass der try-Block fehlschlägt, also erreicht die Ausführung den catch-Block und %code% wird gedruckt. Warum sollte " %code% block" hier fehlschlagen, wenn der Assertionscode ausgeführt wird?
___ answer43718972 ___
Wenn Sie sich den Quellcode von %code% Methode ansehen, werden Sie sehen, dass alles auf %code% method läuft (wie viele andere Behauptungen).
%Vor%
Wie wir sehen können, gibt es %code% , das Sie in %code% fangen. Also JUnit hat keine Möglichkeit zu sagen, dass der Test fehlgeschlagen ist und erklärt, dass der Test bestanden wurde.
Wenn das Abfangen einer Ausnahme Teil Ihres Tests ist (Sie erwarten eine Ausnahme), schlage ich vor, dass Sie sich die JUnit-Dokumentation ansehen: Ausnahmetest
___ antwort43768842 ___
Wenn Sie den Quellcode von junit4 durchgehen, Ссылка
Sie werden verstehen, warum der test1 fehlschlägt
Teil 1:
%Vor%
%Vor%
Teil 2:
%Vor%
Teil 3:
%Vor%
Sie haben also die Rückmeldung von Teil # 3 als
erhalten
java.lang.AssertionError: erwartet [20] aber gefunden [12]
Um die JUnit-Regel für Ausnahmen vollständig zu verstehen, gehen Sie durch folgendes Tutorial :
Ausnahmen erwarten JUnit-Regel
Um eine Aussage zu machen, dass eine Ausnahme mit JUnit ausgelöst wurde, ist es ziemlich üblich, das try / fail / catch-Idiom oder das erwartete Element der @Test-Annotation zu verwenden. Obwohl es prägnanter ist als das erste, gibt es ein Argument, dass die Verwendung von "expected" nicht alle Fälle unterstützt, die Sie testen möchten. Das Beispiel besteht darin, nach der Ausnahmebedingung zusätzliche Tests durchzuführen oder mit der tatsächlichen Ausnahmebedingungsnachricht zu testen.
JUnit 4.7 führt die nächste Weiterentwicklung ein, eine @Rule, die das Beste aus beiden Welten bietet. Dieser Artikel wägt die Vor- und Nachteile jedes Ansatzes ab und betrachtet die Syntax jedes Ansatzes genauer.
Die Try / Fail / Catch Idiom
Das typische Muster besteht darin, eine Ausnahme abzufangen oder explizit fehlzuschlagen, wenn sie nie ausgelöst wurde.
%Vor%
was einen Fehler auf die folgende Art hervorheben würde.
%Vor%
Das Idiom hat potentielle Vorteile, indem es die Möglichkeit bietet, sich gegen die tatsächliche Ausnahme zu behaupten und zusätzliche Arbeit nach der Erwartung auszuführen. Abgesehen von dem Rauschen ist der große Nachteil, dass es sehr leicht ist, den Fail-Call zu vergessen. Wenn wir zuerst einen Test machen, wo wir den Test immer rot ausführen, wäre das kein Problem, aber allzu oft rutscht alles durch das Netz. In der Praxis habe ich viel zu viele Beispiele gesehen, bei denen fehlendes Fehlverhalten falsch positive Ergebnisse liefert.
@Test (erwartet = Exception.class)
Mit dem erwarteten Element können wir den Test wie folgt umschreiben.
%Vor%
was zu folgendem Fehler führt.
%Vor%
Ressourcenverknüpfung Was? überprüft genau assertEquals, wenn Listen aufgestellt werden?
___ tag123exceptionhandling ___ Bei der Ausnahmebehandlung handelt es sich um ein Programmiersprachenkonstrukt oder einen Computerhardwaremechanismus, der das Auftreten von Exceptions behandelt, spezielle Bedingungen, die den normalen Ablauf der Programmausführung ändern.
___ tag123trycatch ___ try-catch ist ein syntaktisches Konstrukt zum Abfangen von Ausnahmen, die von einem Codeabschnitt ausgelöst werden
___ tag123java ___ Java (nicht zu verwechseln mit JavaScript oder JScript oder JS) ist eine universelle objektorientierte Programmiersprache, die für die Verwendung in Verbindung mit der Java Virtual Machine (JVM) entwickelt wurde. "Java-Plattform" ist der Name für ein Computersystem, auf dem Tools zum Entwickeln und Ausführen von Java-Programmen installiert sind. Verwenden Sie dieses Tag für Fragen, die sich auf die Java-Programmiersprache oder Java-Plattform-Tools beziehen.
___ tag123testng ___ TestNG ist ein Testframework, das sich auf die Bereitstellung von Funktionen für das Testen von Einheiten und Funktionen in der Programmiersprache Java konzentriert. Es unterstützt parallele Tests, Datenprovider, Abhängigkeiten, Gruppen und andere Funktionen.
___ tag123assertions ___ Assertion ist eine Methode zur Überprüfung, ob der Code so funktioniert, wie er entworfen wurde. Zum Beispiel sollte das Ergebnis nach dem Lesen einer XML-Datei genau einen Wurzelknoten enthalten. Failed Assertion bedeutet, dass das Programm in einem instabilen Zustand ist und in diesem Fall wird die Ausführung normalerweise beendet.
___ answer43871918 ___
Ich hatte auch das ähnliche Problem, später, als ich Java verstand, dass, wenn die aufrufende Methode von der Ausnahme in ihrer aufgerufenen Methode wissen wollte, die aufgerufene Methode 'throw exception' enthalten sollte; Anweisung in seinem Catch-Block.
Auf diese Weise
%Vor%
TestNG wird erfahren, dass eine Ausnahme ausgelöst wird. Dann wird TestNG diese Methode fehlschlagen.
Bitte beachten Sie, e.printStackTrace (); Außerdem wird Ihr Testfall nicht funktionieren.
___ antwort43838993 ___
Ihr zweiter Fall ist voller Probleme, weshalb er sich so seltsam verhält. Schauen Sie sich die mit Zahlen markierten Zeilen an:
%Vor%
1 - Methodenaufrufe 'assert *' sollten nicht von try-catch-Block umschlossen werden. Sie sind entworfen, um Daten zu prüfen und ihre Ungültigkeit zu behandeln, indem sie Fehler (!) Werfen.
2 - Du versuchst alles zu fangen, kann in den Probierbereich geworfen werden. Geschäftslogik von Anwendungen in häufigen Fällen verwendet Ausnahmen, nicht Fehler. Ausnahmen zeigen, dass ein Problem aufgetreten ist, von dem Sie wiederherstellen können. Fehler zeigen meistens, dass ein ernstes Problem (Festplattenfehler usw.) aufgetreten ist und Sie lediglich die Anwendungsdaten behandeln müssen, bevor die App gestoppt wird. Ausnahme und Fehler erben von Throwable. 'assert *' - Methoden, um Fehler zu vermeiden, die nicht von "Fang" -Blöcken erfasst werden.
3 - Wenn Sie die gefangene Ausnahme nicht tun, ignorieren Sie sie einfach. Deshalb wird Ihre Methode immer mit Erfolg abgeschlossen sein.
Um den zweiten Test zu korrigieren, können Sie:
a) Entfernen Sie den try-catch-Abschnitt aus dem Körper der Methode
b) Ändern Sie den Typ des Parameters t von Throwable in Exception
c) füge 'throw t' am Ende des 'catch' Blocks hinzu
___ qstnhdr ___ Java - TestNG: Warum passiert meine Behauptung immer, wenn sie innerhalb des try-catch-Blocks geschrieben wird
___