Dave Donaldson
Critical thinking in software development
Search
Advertisement
Subscribe
Technorati
View blog authorityView blog reactions
My Tweets
- @hkarthik GoW2 will support up to 10 in multiplayer. An improvement from 8, but I wish they would've doubled it.
- @hkarthik Weekly GoW2 matches work for me, but I already know I'll be on every night anyway.
- Played a couple hours of Gears of War co-op tonight with @fallenrogue. Trying to get back in form for Nov 7.
- Follow Me on Twitter
Please Use Assert.AreEqual Correctly
Thursday, December 20 2007
NUnit and MSTest both have an assertion method named AreEqual and it does what you'd expect: checks whether or not two values are equal. In both unit testing frameworks, the method signature looks like this:
public static void AreEqual<T>(T expected, T actual)
Notice that the first parameter is named "expected" and the second parameter is named "actual", not the other way around. For all that is holy and good, do not switch these around. Doing so can lead to unexpected test results: a test will fail (maybe not unexpected) with an output that shows the opposite of what you expect (that's the unexpected part), and then you're left wondering why and it's all because you didn't pay attention to details and switched the parameters.
So please get it right, and while you're at it, I'm gonna need you to send in your TPS report.
2 comment(s) so far
Dude, that is so funny because just a couple of weeks ago I had to go through and correct a bunch of unit tests that I had written where I had the params reversed. Having them reversed didn't bite me in the sense that you discussed, but it was just wrong and bothered me.
Yeah, I also like the AreEqual as opposed to the Assert.IsTrue(obj1 == obj2,"Objets are not equal");