The short answer is no.
The long answer involves looking at the actual source code. I retrieved this using a decompiler, so some of it may look a little weird. The comments are added by me.
// The IsNotNull overload that takes only "value" calls this one internally
public static void IsNotNull(object value, string message, params object[] parameters)
{
if (value != null)
return;
Assert.HandleFail("Assert.IsNotNull", message, parameters);
}
// The AreNotEqual that takes only "notExpected" and "actual" calls this one internally
public static void AreNotEqual<T>(T notExpected, T actual, string message, params object[] parameters)
{
if (!object.Equals((object) notExpected, (object) actual))
return;
Assert.HandleFail("Assert.AreNotEqual", (string) FrameworkMessages.AreNotEqualFailMsg(message == null ? (object) string.Empty : (object) Assert.ReplaceNulls((object) message), (object) Assert.ReplaceNulls((object) notExpected), (object) Assert.ReplaceNulls((object) actual)), parameters);
}
It's true that there's a difference between comparing with ==
and Equals
, but it shouldn't make a difference when you're comparing to null. As you can see, AreNotEqual
casts the input values to object
and uses the standard static Equals
implementation on the object
class, which is implemented as follows:
public static bool Equals(Object objA, Object objB)
{
if (objA==objB) {
return true;
}
if (objA==null || objB==null) {
return false;
}
return objA.Equals(objB);
}
In my opinion, IsNotNull
is clearer than AreNotEqual
, and the error message if gives when the assert fails is probably easier to understand at a glance.