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);
Ayende @ Rahien
Ayende @ Rahien
Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by email or phone:
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by email or phone:
+972 52-548-6969
FUTURE POSTS
- Let the Merge Games begin! - 10 hours from now
- Keeping track on long running branches - about one day from now
- Error handling belongs at Layer 7 (policy) - 2 days from now
- Practice makes perfect - 5 days from now
- The cost of an extension point - 6 days from now
And 1 more posts are pending...
There are posts all the way to Aug 02, 2017
RECENT SERIES
-
Production postmortem
(17):
23 Aug 2016 - The insidious cost of managed memory -
Building a query parser over a weekend
(2):
25 Jul 2017 - Part II -
PR Review
(3):
21 Jul 2017 - Is your error handling required? -
Reviewing Resin
(6):
20 Jul 2017 - Part VI – Analyzing I/O and being unfair -
Inside RavenDB 4.0
(2):
17 Jul 2017 - Chapter 6 is done
RECENT COMMENTS
-
By Oren Eini on Building a query parser over a weekend: Part II
-
By Damien on Building a query parser over a weekend: Part II
-
By OmariO on Building a query parser over a weekend: Part I
-
By Sebastiaan Dammann on PR Review: Is your error handling required?
-
By Pascal on PR Review: Is your error handling required?
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