Re: Weird overloads on the Assert class.

Hi Charlie,

I've just awoken to find an e-mail from a developer on my team (I'm in Australia, my team is in Connecticut) saying they made this change (I also sent out an internal e-mail about the issue before going to bed), so you are right that this was modifiied internally, and the only sneaky dubious goings on are infact nothing to do with the NUnit project at all. The developer made the change to avoid us having to reverse a wad of arguments as we migrate our whole code base from VS.Net 2003 to VS.Net 2005.

Now I feel a bit silly for raising this in this users group given that it was a modification made by someone else. I guess by the time I can open both eyes and think straight again (don't worry I don't commute to work, just kind of crawl from my bed to my computer) I'll feel a bit better about it.

Sorry for the unecessary noise on the group.

Regards,
Wayne.
  ----- Original Message ----- 
  From: Charlie Poole 
  To: [email protected] 
  Sent: Thursday, November 22, 2007 4:44 AM
  Subject: Re: [Nunit-users] 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

-------------------------------------------------------------------------
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