Bug of the day... previous: Looking for something new next: Challenge: What is wrong with this code Using MbUnit 2.4, this test pass: Guid g = Guid.Empty; Assert.AreEqual(Guid.Empty, g); Assert.AreNotEqual(Guid.Empty, g); Comments 07/01/2008 09:02 PM by josh well that's helpful 07/01/2008 10:00 PM by Oran Yep, ran into that one a while ago... http://code.google.com/p/mb-unit/issues/detail?id=114 07/01/2008 10:01 PM by Andrey Shchekin It's funny that I have stumbled in the exactly same bug today. Well, seems almost no one is actually using AreNotEqual if this lived to the 2.4. 07/01/2008 10:02 PM by Andy Stopford Thanks Oren, I'll need to investigate this more but I think in the absence of an assert for Guid that MbUnit is casting to object and then equating as a null. The AreNotEqual has this gem. if (expected == null ^ actual == null) return; As both become null in the cast it passes. Thats a complete guess at the moment until I can investigate more. Always fun. Andy 07/02/2008 12:46 AM by James Curran Maybe it been updated since the version I'm running (1.0.2700) but the real problem I see is that AreEqual(object, object) uses the object's Equals() methods (via ObjectsEqual) which is customized to the class, while AreNotEqual just uses !(obj==obj) which ultimately just Object.ReferenceEquals. 07/02/2008 09:19 AM by Stefan Wenig That's because GUIDs are so unique that even two identical GUIDs are not quite equal. Duh. 07/02/2008 02:28 PM by arielr That's nothing compared to my bug of the day: try running this piece of code in the immediate window and then in the body of a funcion. bool a = object.ReferenceEquals("A","A") 07/03/2008 10:37 AM by AndyKernahan That's nothing compared to my bug of the day: try running this piece of code in the immediate window and then in the body of a funcion. bool a = object.ReferenceEquals("A","A") a would be true as the compiler would have inturned the string "A" Comments have been closed on this topic.