In Visual Studio 2010 habe ich eine Reihe von Komponententests. Wenn ich mehrere Tests gleichzeitig mit Testlisten ausführe, wird manchmal der folgende Fehler für einen oder mehrere der Tests angezeigt:

Der Agentenprozess wurde gestoppt, während der Test ausgeführt wurde.

Es ist nie derselbe Test, der fehlschlägt, und wenn ich versuche, den Test erneut auszuführen, ist er erfolgreich.

Ich habe diesen Fehlerbericht auf Connect gefunden , der das gleiche Problem zu sein scheint, aber keine Lösung bietet.

Hat jemand dieses Verhalten gesehen? Wie kann ich das vermeiden?

Bearbeiten

Ich habe immer noch diesen Fehler, und viele meiner Kollegen haben das gleiche Software- / Hardware-Setup. Ich habe die Antworten bisher ausgewertet, aber sie lösen das Problem nicht. Ich beginne ein Kopfgeld für eine Lösung für dieses Problem.

Ich habe gerade ein ähnliches Problem festgestellt: Einige Tests schlagen fehl und unterscheiden sich in verschiedenen Testläufen. Ich weiß nicht genau, warum es passiert, aber es begann, als ich einer meiner Klassen einen Finalizer hinzufügte. Wenn ich den Finalizer deaktiviere, verschwindet das Problem. Wenn ich den Finalizer einschalte, tritt das Problem wieder auf.

Im Moment weiß ich nicht, wie ich das überwinden soll.

Diese Nachricht wird durch eine Ausnahme in einem Thread verursacht, der sich vom ausführenden Testthread unterscheidet . Alle bisherigen Antworten beschränken sich auf diese einfache Erklärung. Es ist ein bekannter Fehler in Visual Studio, in diesem Fall keine sinnvollen Informationen anzuzeigen.

Der Testläufer von Visual Studio verschluckt sich völlig, wenn ein anderer Thread als der ausführende Test-Thread eine Ausnahme auslöst: Er wird verschluckt und es gibt keine Ausgabe, keine Möglichkeit zum Abfangen und Debuggen und nichts außer einem niedergebrannten, schwelenden Durcheinander, das Ihre Einheit sein sollte Prüfung.

Ich hatte dieses Problem und es stellte sich als Problem in meinem Code heraus, das das Test Framework nicht richtig abfing. Ein kleines versehentliches Refactoring hatte mir diesen Code hinterlassen:

public void GetThingy()
{
    this.GetThingy();
}

Dies ist natürlich eine unendliche Rekursion und hat eine StackOverflowException verursacht (denke ich). Was dies verursachte, war die gefürchtete: "Der Agentenprozess wurde gestoppt, während der Test lief."

Eine schnelle Codeüberprüfung hat mir das Problem gezeigt, und meine Tests laufen jetzt einwandfrei. Ich hoffe, dies hilft - es könnte sich lohnen, den Code auf Probleme zu untersuchen oder ein wenig in eine Konsolen-App zu extrahieren und zu überprüfen, ob er dort ordnungsgemäß funktioniert.

Ich konnte die Ursache meines Problems anhand der Testergebnisdatei (/TestResults/*.trx) ermitteln. Dort wurden die vollständigen Details der im Hintergrundthread aufgetretenen Ausnahme angegeben. Nachdem ich diese Ausnahme behoben hatte, verarbeitete der Agent sie gestoppt ... "Fehler ging weg.

In meinem Fall habe ich die GUI in meinem Komponententest unbeabsichtigt gestartet, was schließlich dazu führte, dass eine System.ComponentModel.InvalidAsynchronousStateException ausgelöst wurde.

Meine .trx-Datei enthielt also:

   <RunInfo computerName="DT-1202" outcome="Error" timestamp="2013-07-29T13:52:11.2647907-04:00">
    <Text>One of the background threads threw exception: 
System.ComponentModel.InvalidAsynchronousStateException: An error occurred invoking the method.  The destination thread no longer exists.
at System.Windows.Forms.Control.WaitForWaitHandle(WaitHandle waitHandle)
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
...
</Text>
  </RunInfo>

Dies lieferte keine Informationen darüber, welcher Test den Fehler verursachte, aber es zeigte mir, wo die Ausnahme war, was sehr nützlich war.

Diese Nachricht wird normalerweise generiert, wenn der Testprozess abstürzt, und kann auftreten, wenn in einem Hintergrundthread eine nicht behandelte Ausnahme vorliegt, ein Stapelüberlauf auftritt oder ein expliziter Aufruf von Process.GetCurrentProcess().Kill()oder erfolgt Environment.Exit. Eine weitere mögliche Ursache ist eine Zugriffsverletzung in nicht verwaltetem Code.

Niemand hat erwähnt, dass das Ereignisprotokoll möglicherweise zusätzliche Informationen enthält. Normalerweise erhalten Sie nicht viele Informationen darüber, warum der Test in den Ergebnissen abgestürzt ist. Im Falle einer nicht behandelten Ausnahme in einem Hintergrundthread schreibt das Testframework jedoch Details mit der Quell-VSTTExecution in das Anwendungsereignisprotokoll. Wenn keine Informationen in das Ereignisprotokoll geschrieben wurden, ist dies wahrscheinlich eine der anderen oben aufgeführten Ursachen.

In meinem Fall wurde die Lösung durch Überprüfen des Ausgabefensters gelöst .

'QTAgent32.exe' (verwaltet (v4.0.30319)): Geladene 'C: \ TestResults \ bdewey_XXXXXX072 2011-01-11 17_00_40 \ Out \ MyCode.dll', geladene Symbole. E, 9024, 9, 2011/01/11, 17: 00: 46.827, XXXXX072 \ QTAgent32.exe, Unhandled Exception Caught, Berichterstattung über Watson: [Exception message]

In meinem Fall hatte ich einen FileSystemWatcher, der einen Fehler in einem separaten Thread auslöste.

Ich bin auf dasselbe Problem gestoßen und habe es beim Entfernen gelöst

Environment.Exit(0);

Ich bin mir also ziemlich sicher, dass dieser Fehler auftritt, während Ihr Test oder Ihre zu testende Methode dazu führt, dass der Ausführungsprozess beendet wird.

Vielen Dank für die Veröffentlichung der Frage. Ich bin gerade auf dieses Problem gestoßen und habe eine Ursache herausgefunden, auf die Sie möglicherweise stoßen.

Möglicherweise ist eine asynchrone Ausnahme aufgetreten

Während meines Testaufbaus erstelle ich ein Objekt, das einen Arbeitsthread im Thread-Pool in die Warteschlange stellt. Wenn ich das Debuggen schnell genug durchlaufe, wird mein Code übergeben.

Wenn der Worker-Thread startet und ein Fehler auftritt, BEVOR das Test-Setup abgeschlossen ist, erhalte ich das Ergebnis Abgebrochen ohne Begründung.

Wenn der Worker-Thread startet und nach Beginn des Tests ein Fehler auftritt, wird Folgendes angezeigt: Fehler - Der Agentenprozess wurde gestoppt, während der Test ausgeführt wurde.

Wichtig zu beachten: Dies ist eine Komponente, die ich in mehreren meiner Tests verwende. Wenn das Testframework auf zu viele dieser Fehler stößt, werden die restlichen Tests abgebrochen.

Hoffe das hilft

Ich habe dem Deskonstruktor ~ ClassName () {} Try / Catch-Blöcke hinzugefügt, die in jeder Klasse definiert wurden, die an meinen Tests beteiligt war. Dies hat das Problem für mich behoben.

~MyClass()
{
    try
    {
        // Some Code
    }
    catch (Exception e)
    {
        // Log the exception so it's not totally hidden
        // Console.WriteLine(e.ToString());
    }
}

Um herauszufinden, wo die Ausnahme ausgelöst wurde, klicken Sie auf den Hyperlink "Testlauffehler" neben dem Ausrufezeichen im Fenster "Testergebnisse". Ein Fenster mit der Stapelverfolgung wird geöffnet.

Dies hilft sehr, den Fehler aufzuspüren!

Ich hatte das gleiche Problem und es wurde durch einen Finalizer für eine nicht verwaltete Ressource verursacht (ein Dateischreiber, der aus irgendeinem Grund nicht ordnungsgemäß entsorgt wurde).

Nachdem der Finalizer-Code in einen Try-Catch eingeschlossen wurde, der die Ausnahme verschluckt, verschwand das Problem. Ich empfehle nicht, solche Ausnahmen zu schlucken, daher wäre es natürlich ratsam herauszufinden, warum die Ausnahme überhaupt auftritt.

Ich habe dies gelegentlich erlebt, und der Täter stellt sich fast immer als Faden heraus.

Seltsamerweise würden alle Tests auf den Entwicklungsmaschinen gut funktionieren und dann auf den Build-Servern zufällig fehlschlagen.

Bei näherer Betrachtung stellte sich heraus, dass, obwohl die Tests als bestanden auf den Entwicklungsboxen aufgeführt wurden, Ausnahmen geworfen wurden. Die Ausnahmen wurden auf einen separaten Thread geworfen, der nicht als Fehler erkannt wurde.

Die Ausnahmedetails wurden anhand des Test-Trace protokolliert, sodass wir feststellen konnten, welcher Code / welche Tests geändert werden mussten.

Hoffe das hilft jemandem.

In meinem Fall hatte ich einige Unit-Tests für einen WCF-Service. Dieser WCF-Dienst startete 2 Timer.
Diese Timer verursachten Nebenwirkungen.
-> Ich deaktiviere diese Timer standardmäßig und alles ist in Ordnung!

Übrigens: Ich verwende WCFMock , um den WCF-Dienst zu fälschen, daher habe ich "echte" Komponententests rund um meinen WCF-Dienst

Dieser Fehler wurde auch von einem Finalizer für mich verursacht.
Der Finalizer rief tatsächlich einen DB-Code auf, der nicht verspottet war. Ich habe eine Weile gebraucht, um es zu finden, da es keine Klasse war, die ich geschrieben habe, und der Verweis darauf war einige Klassen tief verwurzelt.

Ich bin auf ein ähnliches Problem gestoßen, bei dem ein Test in TestInitialize fehlschlägt und auch Code von einer ddl aus einem anderen meiner Projekte ausführt. Ich erhalte die oben beschriebene Fehlermeldung und wenn ich versuche, den Test zu debuggen, wird der Test nur ohne Ausnahmedetails abgebrochen.

Ich vermute, dass das Problem darin besteht, dass die DLLs aus meinem anderen Projekt aus einem Visual Studio 2012-Projekt stammen und ich meine Tests in einem VS2010-Projekt ausführe und / oder dass die UnitTestFramwork-DLL-Versionen aus den beiden Projekten möglicherweise nicht übereinstimmen.

Das Problem kann auch durch eine Ausnahme oder einen Stapelüberlauf im Konstruktor einer Testklasse ausgelöst werden.

Da dieser Fehler viele verschiedene Ursachen haben kann, möchte ich der Vollständigkeit dieses Threads einen weiteren hinzufügen.

Wenn alle Ihre Tests wie vom OP beschrieben abgebrochen werden, liegt möglicherweise eine falsche Projektkonfiguration vor. In meinem Fall wurde das Zielframework auf .NET Framework 3.5 festgelegt. Durch Festlegen einer höheren Version über die Projekteigenschaftenseite (Registerkarte Anwendung ) wurde das Problem behoben.

Ich konnte anhand der Windows-Protokolle > Anwendungsprotokolleinträge in der Windows-Ereignisanzeige feststellen, was mein Problem verursacht hat . Suchen Sie nach Einträgen zu dem Zeitpunkt, als der Test ausgebombt wurde. Ich hatte einen Fehlereintrag ähnlich dem folgenden:

QTAgent32_40.exe, PID 10432, Thread 2) AgentProcess:CurrentDomain_UnhandledException: IsTerminating : System.NullReferenceException: Object reference not set to an instance of an object.
   at XXX.YYY.ZZZ.cs:line 660
   at XXX.YYY.AAA.Finalize() in C:\JenkinsSlave\workspace\XXX.YYY.AAA.cs:line 180

Es war in der Tat eine Nullreferenzausnahme innerhalb einer Methode, die von einem Klassenfinalisierer aufgerufen wurde.

Für alle, die sich mit dieser alten Frage beschäftigen und sich fragen, was aus ihren Threads geworfen wird, hier ein Tipp. Wenn Sie Task.Run verwenden (im Gegensatz beispielsweise zu Thread.Start), werden untergeordnete Thread-Ausnahmen viel zuverlässiger gemeldet. Kurz gesagt, stattdessen:

Thread t = new Thread(FunctionThatThrows);
t.Start();
t.Join();

Mach das:

Task t = Task.Run(() => FunctionThatThrows());
t.Wait();

Und Ihre Fehlerprotokolle sollten viel nützlicher sein.