Re: Weird overloads on the Assert class.

Hi Wayne,


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);  // Invalid 
 
Assert.IsNotNull has only the first three overloads.
 
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);
 
Can you track down where this overload is defined?
 
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.
 
Yes, it would be. :-)
 
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.
 
Every Assert has a third or fourth overload specifying optional replacement
arguments for the message. If you find that one is missing, please report it
as a bug.
 
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.
 
As unlikely as it seems, I'm wondering if you may be using a modified copy
of NUnit. Another possibility is that you have a locally defined Assert
class that extends ours - but I imagine you would know if you did.
 
FWIW, I'm doubtful at the possibility of solving this problem using simple
replace. Do you use a refactoring tool? I suggest the following, or
something like it:
1) Create your own Assertion class - just copy NUnit's - so you can refactor
it.
2) Refactor methods one at a time until the signatures match Assert.
3) Remove your class and change Assertion to Assert globally.
 
Please, let us know how this turns out.
 
Charlie
 
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