Wir haben NUnit & amp; VisualStudio zum Schreiben von C # .NET-Code für eine Weile. Das Testen von Ausnahmen wurde im Stil von
durchgeführtalte Syntax:
%Vor% Nun hat NUnit die Version 2.5.2 veröffentlicht, die Assert.Throws( Type expectedExceptionType, TestDelegate code ); einführte. Dies macht das Testen von Ausnahmen sehr viel flexibler. Unsere Ausnahmetests sehen jetzt so aus:
neue Syntax:
%Vor%Unser Problem ist, dass Visual Studio, wenn Assert.Throws verwendet wird, ein Fenster mit einer nicht behandelten Ausnahme aushusten wird, wenn NUnit (entweder Konsole oder GUI-Runner) zum Debuggen des Programms verwendet wird.
um dies zu verdeutlichen: Wir haben das VS-Projekt, das die Komponententests enthält, zum Ausführen von nunit-x86.exe beim Debuggen festgelegt. (Siehe Projekteigenschaften, Debugging-Registerkarte, Start-Aktion ist so eingestellt, dass sie nunit-x86.exe ausführt)
Dies hält NUnit davon ab, die Tests fortzusetzen. Es ist möglich, das Debugging / Komponententest durch Drücken von F5 fortzusetzen, aber dies ist keine praktikable Lösung.
Gibt es eine Möglichkeit, dies zu vermeiden? Probieren Sie es aus ... catch Block um die Assert.Throws tut nichts, da die Ausnahme im Delegate-Code passiert.
Ich hoffe, dass jemand etwas Licht in diese Sache bringen kann.
Das Problem selbst erscheint, weil Sie wahrscheinlich die Option Nur aktivierten Code einschalten aktiviert haben (Extras- & gt; Optionen- & gt; Debugging- & gt; Allgemein- & gt; Nur Code aktivieren).
"Wenn diese Funktion aktiviert ist, zeigt der Debugger nur den Benutzercode (" Mein Code ") an und geht in ihn über, ignoriert Systemcode und anderen Code, der optimiert ist oder keine Debugging-Symbole hat (siehe" Allgemein, Debugging, Dialogfeld Optionen ")
Normalerweise haben Sie eine Release-Version von nunit.framework.dll, die keine entsprechende Datei nunit.framework.pdb hat.
Also gibt es 2 Möglichkeiten:
Deaktivieren Sie die Funktion "Nur meinen Code"
Download Quellen von Nunit (aus Ссылка ), bauen sie im Debug-Modus, setzen all nunit.framework. * (dll, pdb, xml) in lib oder ein anderes Verzeichnis in Ihrer Lösung und verweisen Sie auf die nunit.framework.dll in Ihrem Testprojekt.
Hoffe, das hilft.
Dasselbe Problem hat mich auch eine ganze Weile gestört, ich habe ein paar Tests gemacht und folgendes gefunden:
Wenn eine Bibliothek (in diesem Fall nunit) kompiliert wird und debug info auf 'none' gesetzt ist, dann löst VS, wenn ein Konstrukt, das dem folgenden ähnelt, mit der Bibliothek und dem Code des Delegierten eine Ausnahme aus, nicht mehr über die nicht bearbeitete Ausnahme durch den Benutzercode.
Bibliothekscode:
%Vor%Kundencode:
%Vor%Wenn Debug-Informationen eines Bibliotheksprojekts auf eine andere Option als "none" gesetzt werden, wird das Problem gelöst, d. h. der Debugger stoppt nicht mehr bei diesen "unbehandelten" Ausnahmen. Ich testete es mit Nunit und meiner eigenen handgerollten Bibliothek mit dem obigen Code (nahm einen Ausschnitt aus der Methode von Nunits Wirrwarr). Ich nehme an, es ist ein Feature oder ein "Feature" von VS.
Es gibt uns nicht so viele Möglichkeiten:
Filterausnahme wie zuvor vorgeschlagen
Kompiliere nunit.framework.dll für den lokalen Gebrauch neu, um diese lästigen Stops zu vermeiden
Andere Optionen könnten sein, entweder MS- oder NUnit-Teams oder beide zu kontaktieren und sie aufzufordern, das Problem zu untersuchen / zu klären und NUnit mit minimaler Debug-Information zu kompilieren.
Bearbeiten:
Eine weitere Option gefunden.
Ich denke, Sie werden von der NUnit-Behauptung geblendet. Sie könnten das gleiche mit einem einfachen Versuch / Fang erreichen.
%Vor%Jetzt haben Sie alles, was Sie brauchen. Sie schlagen fehl, wenn die Ausnahme nicht ausgelöst wird und Ihr regulärer Code Ausnahmen wie erwartet verarbeiten kann.
Könnte es erreichbar sein, indem Sie die Ausnahme deaktivieren. Öffnen Sie das Debug / Exceptions-Menü und suchen Sie nach Ihrer Exception.
Tags und Links c# visual-studio nunit-2.5 exception assert