La prueba de unidad pasa en depuración, pero cuelga cuando se ejecuta

Question

Tengo un problema extraño. Tengo una prueba de unidad que sigue siendo atascada en el modo de ejecución. Cuando ejecuto la misma prueba en la depuración, sin puntos de interrupción, la prueba pasa cada vez.

Básicamente, es una prueba de conexión de zócalo. Primero desconecto un socket, y luego intento volver a conectarme, y estoy tratando de verificar si la reconexión fue exitosa.

En algún lugar del código Conectar, verifico si hubo una excepción de socket. Cuando esto sucede, el usuario se le presenta algunas opciones en un diálogo, mientras que el código de conexión se cuelga a través de un AutoresEleVent, esperando una decisión.

Es este AutoresElevento que cuelga el sistema. Debe ser proporcionado por código en la prueba de la unidad. Pero mi pregunta es, ¿por qué sucede esto pasa en el modo de depuración? ¿Hay algo especial sobre el modo de depuración por el cual Visual Studio se configura automáticamente por Visual Studio?

editar

Fue hecho una condición de raza. Añadí un retraso en el código después de mi código de desconexión, y funciona ahora. Pero todavía me sorprende como extraño que haya una condición de carrera para comenzar. Déjame elaborar pegando algo del código.

Este es el código de prueba:

MySystem.FindEquipment(new List<string>(1) { "192.1.1.243:28000" });
MySystem.ConstructSystem();
MySystem.IsConstructedFlag.WaitOne();
Assert.AreEqual(1, MySystem.CommunicationController.HardwareIPList.Count);

PFFrame frame1 = MySystem.Frames["0.x.x"];

Assert.IsTrue(frame1.Disconnect());
Thread.Sleep(100);
Assert.IsTrue(frame1.Connect());

La razón por la que esto me sorprende, es que estoy esperando una devolución en el código DICONNECT, antes de llamar al código de conexión. La última parte del código de desconexión se ve así:

lclSocket.Shutdown(SocketShutdown.Both);
lclSocket.Close();
OnSocketDisconnected(new PFSocketConnectionEventArgs(ipEp));
return true;

¿Se debe a que socket.shutdown (), y / o socket.close () los métodos ejecutan los hilos? Por lo tanto, aunque estoy devolviendo un valor desde mi código de desconexión, ¡el socket no está realmente desconectado realmente?

Answer 1

Suena como una condición de carrera.El código de depuración generalmente funciona con muchas cosas adicionales 'debajo de la capucha', y esa diferencia en el tiempo probablemente está lanzando sus pruebas.

Por supuesto sin ver código, realmente no podemos ayudarlo mucho.

Answer 2

más probable debido a una carrera de roscado.Son muy sensibles al tiempo y el tiempo en la construcción de depuración será diferente.Puede usar una herramienta como el ajedrez para ejercer errores como ese.

Pero use herramientas + adjuntar al proceso primero.DEBUG + BREAK TODOS, DEBUG + Windows + Hilos y mira las pilas de llamada de hilo.Es posible que pueda ver la causa de la carrera o el punto muerto.

Answer 3

tuvo un problema similar una vez donde comparé dos fechas, y esperaba una fecha tras otra, pero debido a que se ejecutó eso rápido, recibieron la misma marca de tiempo.

Answer 4

Esta prueba le está diciendo que su código no está correctamente aislado de la biblioteca de socket que está utilizando.El código que está probando no debe tener que depender de ciertos artefactos con, en esta biblioteca.Necesitas agregar una abstracción entre la biblioteca de zócalo que toma los artefactos en Acount.

La razón por la que digo que es, es qué, si el socket realmente desconecta 123,251 veces <100 ms, pero la desconexión de tiempo 123,252ª vez lleva 101 ms.

Recomiendo encarecidamente que casi todo su código de prueba de unidad no utilice el roscado.Miro las llamadas de roscado de cualquier tipo en mis pruebas de unidad como un olor a código.Por lo general, donde quiero ver los problemas de roscado, se encuentra en el nivel de integración.