En Visual Studio 2010, tengo una serie de pruebas unitarias. Cuando ejecuto varias pruebas a la vez usando listas de pruebas, a veces veo el siguiente error para una o más de las pruebas:

El proceso del agente se detuvo mientras se ejecutaba la prueba.

Nunca es la misma prueba fallando, y si intento ejecutar la prueba nuevamente, tiene éxito.

Encontré este informe de error en Connect , que parece ser el mismo problema, pero no ofrece una solución.

¿Alguien más ha visto este comportamiento? ¿Cómo puedo evitarlo?

Editar

Todavía estoy experimentando este error, al igual que muchos de mis colegas en la misma configuración de software / hardware. He evaluado las respuestas hasta ahora, pero no resuelven el problema. Estoy comenzando una recompensa por una solución a este problema.

Acabo de experimentar un problema similar: algunas pruebas fallan y son diferentes en diferentes ejecuciones de prueba. No sé exactamente la razón por la que sucede, pero comenzó a ocurrir cuando agregué un finalizador a una de mis clases. Cuando desactivo el finalizador, el problema desaparece. Cuando enciendo el finalizador, el problema vuelve.

Ahora mismo no sé cómo superar esto.

Este mensaje es causado por una excepción en un hilo diferente del hilo de prueba en ejecución . Todas las respuestas hasta ahora se reducen a esta simple explicación. Es un error conocido en Visual Studio no mostrar ninguna información sensible en ese caso.

El ejecutor de pruebas de Visual Studio se ahoga totalmente si un subproceso que no sea el subproceso de prueba en ejecución arroja una excepción: se traga y no hay salida, no hay posibilidad de interceptar y depurar y nada, excepto un desorden ardiente quemado que se suponía que era su unidad prueba.

Estaba teniendo este problema y resultó ser un problema en mi código que el Marco de prueba no estaba detectando correctamente. Una pequeña refactorización accidental me había dejado con este código:

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

Esto, por supuesto, es una recursividad infinita y provocó una StackOverflowException (supongo). Lo que esto causó fue lo temido: "El proceso del agente se detuvo mientras se ejecutaba la prueba".

Una inspección rápida del código me mostró el problema y mis pruebas ahora están funcionando bien. Espero que esto ayude; valdría la pena inspeccionar el código en busca de problemas, o tal vez extraer un poco en una aplicación de consola y verificar que funcione correctamente allí.

Pude encontrar el origen de mi problema mirando en el archivo de resultados de la prueba (/TestResults/*.trx). Proporcionó los detalles completos de la excepción que ocurrió en el hilo de fondo, y una vez que resolví esa excepción, el "agente procesó detenido ... "el error desapareció.

En mi caso, estaba iniciando involuntariamente la GUI en mi prueba unitaria, lo que finalmente provocó que se lanzara una System.ComponentModel.InvalidAsynchronousStateException.

Entonces mi archivo .trx contenía:

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

Esto no proporcionó ninguna información sobre qué prueba causó el error, pero me mostró dónde estaba la excepción, lo cual fue muy útil.

Este mensaje generalmente se genera cuando el proceso de prueba falla y puede ocurrir cuando hay una excepción no controlada en un hilo en segundo plano, ocurre un desbordamiento de pila o una llamada explícita a Process.GetCurrentProcess().Kill()o Environment.Exit. Otra posible causa es una infracción de acceso en código no administrado.

Algo que nadie ha mencionado es que puede haber información adicional en el registro de eventos. Por lo general, no obtendrá mucha información sobre por qué la prueba falló en los resultados; sin embargo, en el caso de una excepción no controlada en un subproceso en segundo plano, el marco de prueba escribe los detalles en el registro de eventos de la aplicación con la ejecución de VSTTE de origen. Si no hay información escrita en el registro de eventos, es probable que sea una de las otras causas enumeradas anteriormente.

En mi caso, la solución se resolvió al verificar la Ventana de salida .

'QTAgent32.exe' (Administrado (v4.0.30319)): Cargado 'C: \ TestResults \ bdewey_XXXXXX072 2011-01-11 17_00_40 \ Out \ MyCode.dll', Símbolos cargados. E, 9024, 9, 2011/01/11, 17: 00: 46.827, XXXXX072 \ QTAgent32.exe, excepción no controlada detectada, informe a través de Watson: [mensaje de excepción]

En mi caso, tuve un FileSystemWatcher que arrojaba un error en un hilo separado.

Encontré el mismo problema y lo resolví mientras eliminaba

Environment.Exit(0);

Así que estoy bastante seguro de que este error ocurre mientras su prueba o método bajo prueba está causando que finalice el proceso de ejecución.

Gracias por publicar la pregunta. Me acabo de encontrar con este problema y descubrí una causa con la que te puedes estar encontrando.

Puede que se haya producido una excepción asincrónica

Durante mi configuración de prueba, creo un objeto que pone en cola un hilo de trabajo en el grupo de hilos. Si ejecuto la depuración lo suficientemente rápido, mi código pasa.

Si el hilo de trabajo comienza y tiene un error ANTES de que se complete la configuración de la prueba, obtengo un resultado de Abortado sin razonamiento.

Si el hilo de trabajo comienza y tiene un error DESPUÉS de que la prueba ha comenzado, obtengo un resultado de: Error: el proceso del agente se detuvo mientras se ejecutaba la prueba.

Importante tener en cuenta: este es un componente que utilizo en varias de mis pruebas. Si el marco de prueba encuentra muchos de estos errores, aborta el resto de las pruebas.

Espero que esto ayude

Agregué bloques try / catch al descructor ~ ClassName () {} que se definieron en cualquier clase involucrada en mis pruebas. Esto me solucionó el problema.

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

Para averiguar dónde se lanzó la excepción, haga clic en el hipervínculo "Error de ejecución de prueba" junto al icono de exclamación en la ventana Resultados de la prueba. Se abre una ventana con el seguimiento de la pila.

¡Esto ayuda mucho a localizar el error!

Tuve el mismo problema y fue causado por un finalizador de un recurso no administrado (un escritor de archivos que no se estaba eliminando correctamente por alguna razón).

Después de envolver el código del finalizador en un try-catch que se traga la excepción, el problema desapareció. No recomiendo tragar excepciones como esa, por lo que, obviamente, sería prudente averiguar por qué ocurre la excepción en primer lugar.

He tenido esto sucediendo en alguna que otra ocasión, y el culpable casi siempre resulta ser el hilo.

Por extraño que parezca, todas las pruebas funcionarían bien en las máquinas de desarrollo y luego fallarían aleatoriamente en los servidores de compilación.

En una inspección más cercana, resultó que, aunque las pruebas se enumeraban como aprobadas en las cajas de desarrollo, se lanzaron excepciones. Las excepciones se lanzaron en un hilo separado que no fue detectado como un error.

Los detalles de la excepción se registraron en el seguimiento de la prueba, por lo que pudimos identificar qué código / pruebas debían modificarse.

Espero que esto ayude a alguien.

En mi caso, tuve algunas pruebas unitarias para un servicio WCF. Este servicio WCF estaba iniciando 2 temporizadores.
Esos temporizadores provocaron efectos secundarios.
-> ¡Desactive estos temporizadores por defecto y todo está bien!

Por cierto: uso WCFMock para falsificar el servicio WCF, por lo que tengo pruebas unitarias "reales" en torno a mi servicio WCF

Este error también fue causado por un finalizador para mí.
El Finalizador realmente estaba llamando a un código de base de datos que no se burló. Me tomó un tiempo encontrarlo, ya que no era una clase que escribí y la referencia a ella se profundizó en varias clases.

Me he encontrado con un problema similar en el que una prueba falla en TestInitialize y también está ejecutando código desde un ddl de otro de mis proyectos. Recibo el mensaje de error como se describe arriba y si trato de depurar la prueba, la prueba simplemente se cancela sin ningún detalle de excepción.

Sospecho que el problema puede ser que las dlls de mi otro proyecto son de un proyecto de Visual Studio 2012 y estoy ejecutando mis pruebas en un proyecto VS2010, y / o posiblemente que las versiones de UnitTestFramwork dll de los 2 proyectos no coinciden.

El problema también puede desencadenarse por una excepción o Stackoverflow en el constructor de una clase de prueba.

Como este error puede tener muchas causas diferentes, me gustaría agregar otro para completar este hilo.

Si todas sus pruebas se cancelan según lo descrito por el OP, la causa podría ser una configuración de proyecto incorrecta. En mi caso, el marco de destino se configuró en .NET Framework 3.5. Configurarlo en una versión superior a través de la página de propiedades del proyecto (pestaña Aplicación ) resolvió el problema.

Pude determinar qué estaba causando mi problema mirando en Registros de Windows > Entradas de registro de aplicaciones dentro del Visor de eventos de Windows . Busque entradas en el momento en que la prueba falló. Tuve una entrada de error similar a la siguiente:

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

De hecho, fue una excepción de referencia nula dentro de un método llamado desde un finalizador de clase.

Para cualquiera que esté pasando por esta vieja pregunta y se pregunte qué se está lanzando de su (s) hilo (s), aquí hay un consejo. El uso de Task.Run (a diferencia de, por ejemplo, Thread.Start) informará las excepciones de subprocesos secundarios de manera mucho más confiable. En resumen, en lugar de esto:

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

Hacer esto:

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

Y sus registros de errores deberían ser mucho más útiles.