In Visual Studio 2010, ho una serie di unit test. Quando eseguo più test contemporaneamente utilizzando elenchi di test, a volte ricevo il seguente errore per uno o più test:

Il processo dell'agente è stato interrotto durante l'esecuzione del test.

Non è mai lo stesso test che fallisce e se provo a eseguire di nuovo il test, ha successo.

Ho trovato questa segnalazione di bug su Connect , che sembra essere lo stesso problema, ma non offre una soluzione.

Qualcun altro ha visto questo comportamento? Come posso evitarlo?

modificare

Sto ancora riscontrando questo bug, così come molti dei miei colleghi sulla stessa configurazione software / hardware. Finora ho valutato le risposte, ma non risolvono il problema. Sto iniziando una taglia per una soluzione a questo problema.

Ho appena riscontrato il problema simile: alcuni test falliscono e sono diversi in diverse esecuzioni di test. Non so esattamente il motivo per cui accade, ma ha iniziato a verificarsi quando ho aggiunto un finalizzatore a una delle mie classi. Quando disattivo il finalizzatore, il problema scompare. Quando accendo il finalizzatore, il problema si ripresenta.

In questo momento non so come superarlo.

Questo messaggio è causato da un'eccezione su un thread diverso dal thread di test in esecuzione . Tutte le risposte finora si riducono a questa semplice spiegazione. È un bug noto in Visual Studio non visualizzare alcuna informazione sensibile in quel caso.

Il test runner di Visual Studio si strozza completamente se un thread diverso dal thread di test in esecuzione genera un'eccezione: viene inghiottito e non c'è output, nessuna possibilità di intercettare ed eseguire il debug e niente altro tranne un pasticcio fumante bruciato che avrebbe dovuto essere la tua unità test.

Stavo riscontrando questo problema e si è rivelato essere un problema nel mio codice che il Test Framework non rilevava correttamente. Un piccolo refactoring accidentale mi aveva lasciato con questo codice:

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

Questa è ovviamente una ricorsione infinita e ha causato un'eccezione StackOverflowException (immagino). Ciò che ha causato è stato il temuto: "Il processo dell'agente è stato interrotto durante l'esecuzione del test."

Una rapida ispezione del codice mi ha mostrato il problema e ora i miei test funzionano correttamente. Spero che questo aiuti: potrebbe valere la pena ispezionare il codice alla ricerca di problemi o magari estrarne un po 'in un'app console e verificarne il corretto funzionamento lì.

Sono stato in grado di trovare l'origine del mio problema cercando nel file dei risultati del test (/TestResults/*.trx) Forniva tutti i dettagli dell'eccezione che si è verificata nel thread in background e, una volta risolta l'eccezione, l'agente "ha elaborato interrotto ... "l'errore è andato via.

Nel mio caso stavo avviando involontariamente la GUI nel mio unit test, che alla fine ha causato il lancio di un'eccezione System.ComponentModel.InvalidAsynchronousStateException.

Quindi il mio file .trx conteneva:

   <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>

Questo non ha fornito alcuna informazione su quale test ha causato l'errore, ma mi ha mostrato dove si trovava l'eccezione, il che è stato molto utile.

Questo messaggio viene in genere generato quando il processo di test si arresta in modo anomalo e può verificarsi quando è presente un'eccezione non gestita su un thread in background, si verifica un overflow dello stack o una chiamata esplicita a Process.GetCurrentProcess().Kill()o Environment.Exit. Un'altra possibile causa è una violazione di accesso nel codice non gestito.

Qualcosa che nessuno ha menzionato è che potrebbero esserci informazioni aggiuntive nel registro eventi. Di solito non si ottengono molte informazioni sul motivo per cui il test si è arrestato in modo anomalo nei risultati, tuttavia in caso di un'eccezione non gestita su un thread in background, il framework di test scrive i dettagli nel registro degli eventi dell'applicazione con VSTTExecution di origine. Se non ci sono informazioni scritte nel registro eventi, è probabile che sia una delle altre cause elencate sopra.

Nel mio caso la soluzione è stata risolta controllando la finestra di output .

"QTAgent32.exe" (gestito (v4.0.30319)): caricati "C: \ TestResults \ bdewey_XXXXXX072 2011-01-11 17_00_40 \ Out \ MyCode.dll", simboli caricati. E, 9024, 9, 2011/01/11, 17: 00: 46.827, XXXXX072 \ QTAgent32.exe, Rilevata eccezione non gestita, segnalazione tramite Watson: [Messaggio di eccezione]

Nel mio caso avevo un FileSystemWatcher che generava un errore su un thread separato.

Ho riscontrato lo stesso problema e l'ho risolto durante la rimozione

Environment.Exit(0);

Quindi sono abbastanza sicuro che questo errore si verifica mentre il test o il metodo sottoposto a test sta causando il termine del processo di esecuzione.

Grazie per aver postato la domanda. Ho appena riscontrato questo problema e ho scoperto una causa in cui potresti incappare.

Potrebbe essersi verificata un'eccezione asincrona

Durante la configurazione del test, creo un oggetto che accoda un thread di lavoro nel pool di thread. Se eseguo il debug abbastanza velocemente, il mio codice passa.

Se il thread di lavoro inizia e presenta un errore PRIMA del completamento della configurazione del test, ottengo il risultato di Interrotto senza ragionamento.

Se il thread di lavoro si avvia e presenta un errore DOPO l'inizio del test, viene visualizzato il risultato di: Errore: il processo dell'agente è stato interrotto durante l'esecuzione del test.

Importante da notare: questo è un componente che utilizzo durante molti dei miei test. Se il framework di test rileva troppi di questi errori, interrompe il resto dei test.

Spero che questo ti aiuti

Ho aggiunto blocchi try / catch al descructor ~ ClassName () {} che sono stati definiti in qualsiasi classe coinvolta nei miei test. Questo ha risolto il problema per me.

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

Per scoprire dove è stata generata l'eccezione, fare clic sul collegamento ipertestuale "Errore di esecuzione del test" accanto all'icona del punto esclamativo nella finestra Risultati del test. Si apre una finestra con la traccia dello stack.

Questo aiuta molto a rintracciare l'errore!

Ho avuto lo stesso problema ed è stato causato da un finalizzatore per una risorsa non gestita (un programma di scrittura di file che non veniva smaltito correttamente per qualche motivo).

Dopo aver avvolto il codice del finalizzatore in un try-catch che ingoia l'eccezione, il problema è scomparso. Non consiglio di ingoiare eccezioni del genere, quindi sarebbe ovviamente saggio scoprire perché l'eccezione si sta verificando in primo luogo.

Ho avuto questo accadere in una strana occasione e il colpevole si rivela quasi sempre essere il threading.

Stranamente, tutti i test funzionerebbero bene sulle macchine di sviluppo, quindi fallirebbero casualmente sui server di compilazione.

A un esame più attento è emerso che, sebbene i test fossero elencati come superati nelle caselle di sviluppo, c'erano delle eccezioni. Le eccezioni venivano lanciate su un thread separato che non veniva rilevato come errore.

I dettagli dell'eccezione venivano registrati rispetto alla traccia di test, quindi siamo stati in grado di identificare quale codice / test dovevano essere modificati.

Spero che questo aiuti qualcuno.

Nel mio caso ho eseguito alcuni test unitari per un servizio WCF. Questo servizio WCF stava avviando 2 timer.
Quei timer hanno causato effetti collaterali.
-> Disabilito questi timer per impostazione predefinita e va tutto bene!

A proposito: uso WCFMock per falsificare il servizio WCF, quindi ho test unitari "reali" sul mio servizio WCF

Questo errore è stato causato anche da un Finalizer per me.
Finalizer stava effettivamente chiamando un codice DB che non è stato deriso. Mi ci è voluto un po 'per trovarlo perché non era una classe che ho scritto e il riferimento ad esso è stato approfondito parecchie lezioni.

Ho riscontrato un problema simile in cui un test non riesce in TestInitialize e sta anche eseguendo codice da un ddl da un altro dei miei progetti. Ricevo il messaggio di errore come descritto sopra e se provo a eseguire il debug del test, il test viene semplicemente interrotto senza alcun dettaglio di eccezione.

Sospetto che il problema possa essere che le DLL del mio altro progetto provengono da un progetto Visual Studio 2012 e sto eseguendo i miei test in un progetto VS2010, e / o forse che le versioni dll UnitTestFramwork dei 2 progetti non corrispondono.

Il problema può anche essere innescato da un'eccezione o Stackoverflow nel costruttore di un TestClass.

Poiché questo errore può avere molte cause diverse, vorrei aggiungerne un altro per completezza di questo thread.

Se tutti i test vengono interrotti come descritto dall'OP, la causa potrebbe essere una configurazione del progetto errata. Nel mio caso il framework di destinazione era impostato su .NET Framework 3.5. L'impostazione di una versione successiva tramite la pagina delle proprietà del progetto (scheda Applicazione ) ha risolto il problema.

Sono stato in grado di determinare quale fosse la causa del mio problema guardando nei registri di Windows > voci del registro dell'applicazione nel Visualizzatore eventi di Windows . Cerca le voci nel momento in cui il test è esploso. Ho ricevuto una voce di errore simile alla seguente:

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

Era effettivamente un'eccezione di riferimento nullo all'interno di un metodo chiamato da un finalizzatore di classe.

Per chiunque si trovi su questa vecchia domanda e si chieda cosa viene lanciato dai thread, ecco un suggerimento. L'uso di Task.Run (al contrario di, diciamo, Thread.Start) segnalerà le eccezioni dei thread secondari in modo molto più affidabile. In breve, invece di questo:

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

Fai questo:

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

E i tuoi log degli errori dovrebbero essere molto più utili.