Unit Test Synchroncode hat eine Race Condition?

Question

Ich habe einen Code auf Git Hub, der hier gefunden werden kann: https://github.com/Shaunus87/SyncTest, die meinen Prototyp-Code und meine Einheit Tests dafür enthält.

ich meine Synchroncode im Wesentlichen erklären, ein Ereignis, Haken, eine Methode aufrufen, die schließlich das Ereignis nennen, und behaupten, ob das Ereignis aufgerufen wurde oder nicht:

 bool called = false; 

     var testBinsToVend = GetRoboBins(); 
     var vendHelper = new VendingHelper(null, testBinsToVend, VendType.Issue); 

     vendHelper.Complete += delegate() { 
      called = true; 
     }; 

     vendHelper.DoVending(); 

     Assert.IsTrue(called); 

der gesamte Code synchron ist (wie Soweit ich weiß), aber wenn ich den Test ausführen, schlägt es fehl, wenn ich durch es debuggen, es passiert ...

Ich habe ein paar Dinge ausprobiert und es scheint entweder a) mein Code ist heimlich async und Ich habe eine Race-Bedingung oder b) wenn ich den Code ausführe, beschließt er, die Hälfte der Events nicht auszuführen?

Was zur Hölle?

Edit: ich auch versucht habe, wie unten ein manuelles Reset-Ereignis Einstellung:

 bool called = false; 
     var done = new ManualResetEvent(false); 

     var testBinsToVend = GetRoboBins(); 
     var vendHelper = new VendingHelper(null, testBinsToVend, VendType.Issue); 

     vendHelper.Complete += delegate() { 
      called = true; 
      done.Set(); 
     }; 

     vendHelper.DoVending(); 

     done.WaitOne(); 
     Assert.IsTrue(called); 
     //was complete called? 
     Assert.AreEqual(true, vendHelper.Bins.All(x => x.State != VendState.Pending)); 

aber da es eine Zeile der Ausführung, wenn done.WaitOne(); getroffen wird der Test nie die Assert.IsTrue(called); Linie erreicht.

Answer 1

Es gibt ein Problem in der Business-Logik:

private CommCommand GetLastCommand(List<CommCommand> cmds, DateTime since) { 
return cmds.Where(x => x.DateTime > since) 
      .OrderByDescending(x => x.DateTime) 
      .FirstOrDefault(); 
} 

DateTime.Now hat nur eine Auflösung von etwa 20 ms oder so voreingestellt. Was bedeutet, dass Ihre Nachricht empfangen wird, lange bevor DateTime > since wahr wäre. Wenn Sie durch den Code gehen, wird das Timing angepasst - das Send passiert viel länger nach dem ursprünglichen Empfang.

Sie können sich nicht auf DateTime.Now für die Nachrichtenreihenfolge verlassen. Es hat einfach nicht genug Genauigkeit. Wenn Sie wirklich glauben, dass Sie sich auf die Reihenfolge von Senden und Empfangen für die Bestellung verlassen können (das heißt, die Maschine antwortet niemals, bevor sie dazu aufgefordert wird), ersetzen Sie sie stattdessen durch einen einfachen Zähler.