c# - test - Depuración de prueba NUnit

nunit vs xunit

Question

Estoy trabajando en una biblioteca de geometría. Hay más de 200 pruebas de unidad.

Hay una prueba particularmente obstinada que falla cuando selecciono "Ejecutar todo", pero la prueba pasa cuando ejecuto esa prueba individualmente o uso el depurador en ella. Creo que el problema apareció cuando pasé del estudio visual ''13 a la edición ''15.

Ahora algunas notas sobre la biblioteca de geometría:

Los objetos son inmutables.

Las pruebas no tienen objetos compartidos entre ellos.

Entonces, mi pregunta: ¿Cuáles son las posibles causas de este extraño comportamiento?

Editar:

[Test()]
public void Plane_IntersectionWithPlane_IdenticalPlane()
{
     Plane testPlane = new Plane(new Direction(Point.MakePointWithInches(2, -1, 1)), 
                                               Point.MakePointWithInches(2, 1, 2));
     Line found = (testPlane.Intersection(testPlane));

     Line expected = new Line(new Direction(Point.MakePointWithInches(0, -1, -1)), 
                                            Point.MakePointWithInches(2, 1, 2));
     Assert.IsTrue(found.Equals(expected));
}

Answer 1

He encontrado problemas similares en el pasado, pero siempre resultó ser una interacción inesperada entre los elementos de código subyacentes o la forma en que se han escrito las pruebas. Algunos temas a revisar son:

• Construcción / destrucción de objetos estáticos
• Problemas de sincronización
• Problemas de configuración / limpieza simulada

He encontrado que el mejor enfoque para localizar el problema es seguir un enfoque similar al sugerido por @Matthew Strawbridge en los comentarios. Agrego los atributos Ignore a Pruebas / TestFixtures para eliminar pruebas hasta que el run-all comience a funcionar y luego comience a agregarlas nuevamente hasta que se rompa nuevamente, acortando el problema.

A veces también encontrará que ignorar la prueba que actualmente está fallando causará que otra prueba falle en su lugar. Esta es una buena indicación de que el problema en realidad está siendo causado por otra de sus pruebas que no se ha solucionado correctamente.

Mirar el código entre las pruebas que fallan / que parecen causar la falla puede ayudarlo a reducir la interacción. El motivo de error / falla de las pruebas también puede ayudar, por supuesto ...

Al seleccionar ''Ejecutar todo'' se ejecutan todas las pruebas en un orden predecible, por lo que las pruebas generalmente se ejecutarán de la misma manera cada vez. Si selecciona un lote de pruebas, es posible que el corredor pueda elegir ejecutarlas en un orden diferente, en función de su orden de selección, por lo que puede haber experimentado un comportamiento diferente al seleccionar pruebas, en lugar de utilizar la ejecución completa.

Answer 2

Intente lo siguiente:

Abra la GUI de Nunit Y antes de ejecutar la prueba, cambie lo anterior en la configuración:

Me ayudó una vez detectar mis problemas.

BTW: ¿Qué versión de NUNIT estás usando? Si no sabe qué es la GUI de Nunit, entonces probablemente no haya descargado Nunit por separado. Puede obtener la instalación desde aquí:

http://www.nunit.org/index.php?p=download

Answer 3

Por favor, compruebe si hay variables estáticas involucradas. Las variables estáticas están presentes en el nivel AppDomain, por lo que es posible que una variable estática establecida por un caso de prueba pueda causar efectos secundarios a otros casos de prueba.

Puede ejecutar este testcase en un dominio de aplicación separado primero para confirmar el comportamiento antes de iniciar la búsqueda de la variable estática. Lo siento, nunca intenté crear un nuevo appdomain en nunit. Pero una de las respuestas aquí da una pista sobre cómo crear un nuevo dominio de aplicaciones para un caso de prueba: ejecute pruebas unitarias en diferentes dominios de aplicaciones con NUnit

Answer 4

Por lo que veo en el testcase, un comportamiento divergente es extraño, pero el fallo de la prueba es un resultado perfectamente válido:

Un plano intersectado consigo mismo sería el plano, de modo que si el resultado se restringe a ser una línea, cualquier línea con 2 puntos distintos en el plano sería un resultado válido, pero la prueba de una línea en particular se parece a la ingeniería inversa de los resultados de ejecución en las expectativas de prueba.

Sería una historia diferente si el requisito / especificación es muy específico acerca de la dirección de las líneas resultantes de la intersección de la identidad, por lo que tal vez quiera proporcionar más información sobre esta área.

Lo siento por publicar esto como respuesta en lugar de un comentario - falta representante.

Answer 5

Si esta prueba pasa de forma aislada pero falla cuando se ejecuta junto con otras pruebas, es extremadamente probable que tenga algún estado compartido en sus clases.

Si dices que todos nuestros objetos son inmutables, mi primera suposición sería mirar la implementación de

Line Intersection (Plane plane);

Espera que este método devuelva una Línea que se considera la misma que su línea "esperada", por lo que probablemente Intersection devuelva una línea en función de algún estado compartido.

¿Podrías mostrarnos la implementación de Intersección?