2008-12-30 9 views

Respuesta

8

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 ensamblado compilado como parámetro.

2

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.

0

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

2

Probablemente todo el mundo tenga razón, alguna fecha compartida se está modificando entre pruebas. Pero tenga en cuenta el order of MS Test execution. 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.

0

Otros marcos de pruebas unitarias que he utilizado trabajan duro para asegurar 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 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.

0

También encontré este problema aunque mi problema terminó siendo un problema de subprocesamiento. En mi caso estaba fingiendo el objeto HttpContext ya que las pruebas se basaban en su existencia. Sin embargo, yo estaba sentado en el método de este ClassInitialize pensando que esto sería utilizado para cada método, como 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 obtener más información al respecto. http://blogs.msdn.com/b/nnaderi/archive/2007/02/17/explaining-execution-order.aspx

Cuestiones relacionadas