Weird overloads on the Assert class.
"Wayne Hartell" <[email protected]>
| Newsgroups | gmane.comp.windows.dotnet.nunit.user |
|---|---|
| Message-ID | <005601c82c30$b60eba50$0277150a@whar9150> |
We've recently upgraded from NUnit 2.2 to 2.4 and have fallen into a bit of a trap with the deperecated methods on the Assertion class from 2.2.
For example if we had the following code previously...
Assertion.AssertNotNull("myObject was null.", myObject);
Which was using this method signature:
void Assertion.AssertNotNull(string, object);
We have now been presented with the following alternatives on the Assert class.
void Assert.IsNotNull(object anObject);
void Assert.IsNotNull(object anObject, string message);
void Assert.IsNotNull(object anObject, string message, params object[] args);
void Assert.IsNotNull(string message, object anObject, params object[] args);
A number of developers in my company have lept forward with find/replace changing "Assertion.AssertNotNull(" to "Assert.IsNotNull(", but this results in our code unexpectedly (unless paying close attention) using the following overload unexpectedly.
void Assert.IsNotNull(string message, object anObject, params object[] args);
What we really wanted to use was:
void Assert.IsNotNull(object anObject, string message);
But this means we have to reverse the string and object arguments.
This seems to be a dubious design decision and I was wondering what the basis of it was and if there is any impact to us ending up using the unintended overload.
Furthermore, it seems that some methods on Assert, like Assert.IsNull did not get lucky enough to get that fourth sneaky signature overload, and in this case a trigger happy developer will find themselves ending up with code that won't even compile after their find/replace operation.
Personally, I prefer the doesn't compile situation since it alerts the developer to the difference, but I'm now just even even more confused as to why some Assert methods got the sneaky overload and why some did not and what the basis of it was.
Kind Regards,
Wayne.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Nunit-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nunit-users