JUnit 4 und Suspend-on-Exception

8

Wenn eine nicht abgefangene Ausnahme in meinem Code ausgelöst wird, bin ich es gewohnt, den Debugger bei der Anweisung werfen zu lassen, damit ich die lokalen Variablen und die Mitglieder aller beteiligten Objekte in dem Moment untersuchen kann, in dem die Ausnahme ausgelöst wurde. Mit IntelliJ Idea kann dies erreicht werden, indem Sie zu Ausführen , Haltepunkte anzeigen gehen und die Registerkarte Ausnahmen-Haltepunkte auswählen Jede Ausnahme und sicherstellen, dass das Kontrollkästchen Caught exception deaktiviert ist, während das Kontrollkästchen Uncaught exception aktiviert ist. Mit Eclipse und mit Visual Studio (für C #) ist es etwas anderes, aber in gleicher Weise.

Die Möglichkeit, dass der Debugger sich so verhält, ist sehr nützlich. so nützlich in der Tat, dass ich die Hauptschleife meiner Programme entsprechend strukturiere: In der Release-Version ist die Hauptschleife natürlich in einen try-catch-all eingebettet; Aber in der Debug-Version gibt es keinen try-catch-Block in der Hauptschleife, so dass alle Ausnahmen, die nirgends in meinem Programm abgefangen werden, nicht abgefangen werden, so dass der Debugger mein Programm in dem Moment, in dem sie geworfen werden, aussetzt.

Beim Testen meiner Java-Klassen mit JUnit habe ich jedoch ein Problem: Der Debugger stoppt bei keiner Ausnahme. Was passiert, ist, dass nicht nur erwartete, sondern auch unerwartete Ausnahmen automatisch abgefangen werden und dass ich eine Post-Mortem-Ausnahme-Stack-Trace bekomme, um zu versuchen, Sinn zu machen. Das ist nicht sehr cool.

Ich dachte, dass dies passiert, weil JUnit java.lang.reflect.Method.invoke() verwendet, alle Ausnahmen abfängt und sie in TargetInvocationExceptions umwandelt, aber dann habe ich meinen eigenen benutzerdefinierten JUnit-Runner geschrieben, der meine Testklasse persönlich und direkt kennt ruft seine Methoden ohne Method.invoke() auf und das Problem bleibt bestehen. Dies bedeutet, dass das Problem innerhalb von JUnit Core liegt.

Hat also jemand anderes das gleiche Problem? Kennt jemand eine Lösung, damit der Debugger während des Tests mit JUnit die Programmausführung bei unerwarteten Ausnahmen anhalten kann?

Related (unbeantwortete) Frage: Suspend auf Uncaught Laufzeitausnahmen in Eclipse Junit Test Runner

Related (unbeantwortete) Frage: Wie zu brechen in Debugger innerhalb eines jUnit-Testfalls?

Verwandte (teilweise beantwortete) Frage: Break on Exception in Eclipse mit jUnit (Die akzeptierte Antwort besagt, dass "wenn Sie eine einzelne Methode in jUnit debuggen, die Haltepunkte zu arbeiten. Wenn eine gesamte Klasse oder ein Paket in jUnit debuggt wird, funktioniert der Debugger nicht.")

    
Mike Nakis 28.11.2012, 18:12
quelle

2 Antworten

1

Ich hoffe, ich verstehe die Frage richtig, also korrigiere mich, wenn ich falsch liege, aber:

  • Sie haben einen Test, der eine Ausnahme auslöst, die Sie selbst nicht fangen (also in diesem Sinne nicht gefunden wird)
  • Wenn Sie diesen Test mit dem JUnit4 testrunner debuggen, zeigt Ihnen JUnit, dass der Test fehlschlägt (es wurde die Ausnahme ausgelöst)
  • aber der Thread ist nicht ausgesetzt, was Sie erreichen möchten
  • obwohl Sie preferences | java | debug | suspend execution on uncaught exceptions enabled
  • haben

In diesem Fall glaube ich, dass dies das beabsichtigte Verhalten ist, JUnit fängt und schluckt Ihre Exception, so dass es nicht unbeeinflusst ist, was Eklipse betrifft, wie hier beschrieben Ссылка

Sie können festlegen, dass eclipse auf keinen Fall unterbrochen werden darf, indem Sie Ihre eigenen Regeln für das Aussetzen eingehender Ausnahmen festlegen. Debug perspective | breakpoint view | J! icon | check suspend on caught exception

    
Hirle 11.06.2015 14:28
quelle
0

Als Workaround zur Untersuchung eines Testfehlers können Sie eine Instanz der problematischen Testklasse in der main-Methode erstellen und die Testmethode von Hand mit Ihrer Exception-Breakpoints-Methode aufrufen (was übrigens sehr cool ist, danke für die Frage). Auf diese Weise wird die Methode nicht reflektiv aufgerufen.

    
artbristol 28.11.2012 19:34
quelle