studio - see cref c#

La prueba en Visual Studio tiene éxito individualmente, falla en un conjunto

Question

Cuando ejecuto mis pruebas en Visual Studio individualmente, todas pasan sin problemas. Sin embargo, cuando los ejecuto todos a la vez, algunos pasan y otros fallan. Traté de poner una pausa de 1 segundo entre cada método de prueba sin éxito.

¿Algunas ideas? Gracias de antemano por tu ayuda...

Answer 1

Es muy posible que algunas modificaciones / instancias realizadas en una prueba afecten a las otras. Eso indica un diseño de prueba deficiente y la falta de aislamiento adecuado.

Answer 2

Es posible que tenga algunos datos compartidos. Verifique las variables de miembros estáticos en las clases en uso, lo que significa que una prueba establece un valor que hace que una prueba subsiguiente falle.

También puede depurar pruebas unitarias. Según el marco que esté utilizando, debería poder ejecutar la herramienta de marco como una aplicación de inicio de depuración que pasa la ruta al conjunto compilado como parámetro.

Answer 3

Probablemente todo el mundo tenga razón, alguna fecha compartida se está modificando entre pruebas. Pero tenga en cuenta el orden de ejecución de la prueba MS . Simplemente pausar entre las pruebas no es una solución. Cada prueba se ejecuta en su propia instancia de la clase de prueba en un hilo separado.

Answer 4

según las otras respuestas. Parece que tiene una variable única o global que está causando la interacción.

Answer 5

Otros marcos de pruebas unitarias que he utilizado trabajan arduamente para garantizar que una prueba produzca resultados idénticos, ya sea que la prueba se ejecute individualmente o se ejecute como parte de la opción "ejecutarlos a todos". El objetivo es evitar que una prueba tenga un efecto en otra debido a los efectos secundarios, como (por ejemplo) que una prueba deje el estado estático de una clase en una configuración que otra prueba no espera. El marco de prueba de la unidad VS no parece proporcionar este aislamiento. Tengo 2 sugerencias para minimizar los tipos de problemas que implica la pregunta. Primero, use una clase no estática de preferencia a una clase estática si la clase tiene estado (tiene algo más que métodos estáticos). Cree una instancia única de esta clase y pídales que guarden la información de estado que se guardaba en la clase estática. En segundo lugar, si elige tener clases estáticas con estado estático, tenga un método estático que restablezca el estado estático a ''vacío'' (por ejemplo, un método que establezca todas las propiedades estáticas en nulo / cero / etc.). Llámalo al final de cada prueba unitaria para deshacer cualquier efecto que la prueba haya impuesto sobre el estado estático. (Esto es ciertamente menos que elegante, pero puede ser viable si se hace con moderación). O haga lo que planeo hacer: encuentre un marco de prueba de unidad que proporcione aislamiento entre pruebas.

Answer 6

También encontré este problema aunque mi problema terminó siendo un problema de subprocesos. En mi caso estaba fingiendo el objeto HttpContext ya que las pruebas se basaban en su existencia. Sin embargo, estaba estableciendo esto en el método ClassInitialize pensando que esto se usaría para cada método como se muestra a continuación:

[ClassInitialize]
public static void ClassInit(TestContext testContext)
{
    HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
}

Sin embargo, resulta que cada método de prueba en la clase se ejecuta en un hilo separado. Así que tuve que agregar este código a cada método de prueba que dependía de él para solucionar el problema.

[TestMethod]
public void TestMethod1()
{
    HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
    ...
}

[TestMethod]
public void TestMethod2()
{
    HttpContext.Current = new HttpContext(new HttpRequest(null, "http://tempuri.org", null), new HttpResponse(null));
    ...
}

Ver enlace para más información sobre esto. http://blogs.msdn.com/b/nnaderi/archive/2007/02/17/explaining-execution-order.aspx