Il test dell'unità passa nel debug, ma si blocca quando viene eseguito

Question

Ho un problema strano. Ho un test unitario che continua a rimanere bloccato in modalità di esecuzione. Quando eseguo lo stesso test nel debug, senza punti di interruzione, il test passa ogni volta.

Fondamentalmente, è un test di connessione socket. Per prima cosa scollega una presa, e poi prova a riconnettersi e sto cercando di controllare se la riconnessione ha avuto successo.

Da qualche parte nel codice Connect, controllo se ci fosse un'eccezione socket. Quando ciò accade, l'utente è presentato con alcune scelte in una finestra di dialogo, mentre il codice di connessione si blocca tramite un autoresetevent, in attesa di una decisione.

È questo autoresetevent che appende il sistema. Deve essere fornito dal codice nel test dell'unità. Ma la mia domanda è, come mai questo passa in modalità Debug? C'è qualcosa di speciale in merito alla modalità di debug in base a cui gli autoresetevents vengono automaticamente impostati da Visual Studio?

Modifica

È stata davvero una condizione di gara. Ho aggiunto un ritardo nel codice dopo il mio codice di disconnessione, e funziona ora. Ma mi colpisce ancora così strano che ci sia una condizione di gara per cominciare. Lasciatemi elaborare incollando un po 'del codice.

Questo è il codice di prova:

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 ragione per cui questo mi colpisce, è che sto aspettando un ritorno sul codice Diconnect, prima di chiamare il codice Connect. L'ultima parte del codice di disconnessione è simile a questa:

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

.

è perché il socket.shutdown () e / o il socket.Close () i metodi eseguono i thread It Threads? Quindi, anche se sto restituendo un valore dal mio codice di disconnessione, la presa non è in realtà veramente disconnessa?

Answer 1

Sembra una condizione di gara.Il codice di debug di solito gestisce un sacco di cose extra 'sotto il cofano ", e quella differenza nei tempi probabilmente sta lanciando i tuoi test.

Naturalmente senza codice del codice, non possiamo davvero aiutarti molto.

Answer 2

Molto probabilmente a causa di una corsa di threading.Sono molto sensibili ai tempi e i tempi nella build di debug saranno diversi.Puoi usare uno strumento come gli scacchi per esercitare bug come quello.

Ma usa gli strumenti + allegati per prima elaborare.Debug + Break tutto, Debug + Windows + Threads e guarda le pile di chiamata filettatura.Potresti essere in grado di vedere la causa della gara o del deadlock.

Answer 3

Aveva un problema simile una volta dove ho confrontato due date e previsto una data dopo l'altra, ma poiché è stata giustiziata in fretta, hanno ricevuto lo stesso timestamp.

Answer 4

Questo test ti sta dicendo che il tuo codice non è isolato correttamente dalla libreria socket che stai utilizzando.Il codice che stai provando non dovrebbe essere necessario dipendere da determinati artefatti con-in questa libreria.È necessario aggiungere un'astrazione tra la libreria socket che prende i manufatti in acount.

La ragione per cui dico questo è, è se la presa non disconnette effettivamente 123.251 volte <100 MSEC, ma la disconnessione di 123.252 ° tempo prende 101 MSECS.

Consigliamo vivamente che quasi tutto il codice di test dell'unità non utilizzare il threading.Guardo le chiamate di threading di qualsiasi tipo nei miei test unitari come odore di codice.Di solito dove voglio vedere i problemi di filettatura è a livello di integrazione.