Ayende @ Rahien

It's a girl

Bug of the day...

Using MbUnit 2.4, this test pass:

Guid g = Guid.Empty;
Assert.AreEqual(Guid.Empty, g);
Assert.AreNotEqual(Guid.Empty, g);

Comments

josh
07/01/2008 09:02 PM by
josh

well that's helpful

Oran
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

Andrey Shchekin
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.

Andy Stopford
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

James Curran
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.

Stefan Wenig
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.

arielr
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")

AndyKernahan
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.