+972 52-548-6969
Bug of the day...
time to read 1 min | 13 words
Using MbUnit 2.4, this test pass:
Guid g = Guid.Empty; Assert.AreEqual(Guid.Empty, g); Assert.AreNotEqual(Guid.Empty, g);
FUTURE POSTS
- Partial writes, IO_Uring and safety - about one day from now
- Configuration values & Escape hatches - 4 days from now
- What happens when a sparse file allocation fails? - 6 days from now
- NTFS has an emergency stash of disk space - 8 days from now
- Challenge: Giving file system developer ulcer - 11 days from now
And 4 more posts are pending...
There are posts all the way to Feb 17, 2025
RECENT SERIES
-
Challenge
(77):
20 Jan 2025 - What does this code do? -
Answer
(13):
22 Jan 2025 - What does this code do? -
Production post-mortem
(2):
17 Jan 2025 - Inspecting ourselves to death -
Performance discovery
(2):
10 Jan 2025 - IOPS vs. IOPS
RECENT COMMENTS
-
By Pyth0n on Challenge: What does this code do?
-
By Oren Eini on Performance discovery: IOPS vs. IOPS
-
By kpvleeuwen on Performance discovery: IOPS vs. IOPS
-
By Oren Eini on Aggregating trees with RavenDB
-
By Nicholas Paldino on Aggregating trees with RavenDB
Syndication
| Main feed | |
| Comments feed |
Comments
well that's helpful
Yep, ran into that one a while ago...
http://code.google.com/p/mb-unit/issues/detail?id=114
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.
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
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.
That's because GUIDs are so unique that even two identical GUIDs are not quite equal. Duh.
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"
Comment preview