Closed GoogleCodeExporter closed 9 years ago
I fixed this in my last commit to 2.4.1. The overloads were a little confused,
I
think this was either "late" coding or resharper madness.
Original comment by dave.gri...@gmail.com
on 3 Sep 2007 at 12:02
You fixed it by removing the overload though, and the bug report suggests that
at
least one customer is using that method. Also, for consistencies sake if nothing
else, we should provide the same overloads for all Assert methods.
Original comment by grahamr...@gmail.com
on 3 Sep 2007 at 1:04
There was a reason for removing the overload .. if you try adding one, the
compiler
will complain about an ambiguous overload with the other AreEqual() methods. I
did
try to add the consistent methods, but I could not find an easy solution to
this,
without removing bits and pieces all over the place. I'm guessing that is why
somebody put the "string me" parameter in there - to get around/prevent this
compiler error.
For anyone attempting to use this method, please use the following instead:
Assert.AreEqual(expected, actual, delta, String.Format(message, args[]))
Original comment by d...@davegriffiths.net
on 3 Sep 2007 at 2:24
Hmm, strange. I get no problems with:
static public void AreEqual(double expected, double actual, double delta,
string format, params object[] args)
{
AreEqual(expected, actual, delta, String.Format(format, args));
}
Original comment by grahamr...@gmail.com
on 3 Sep 2007 at 3:01
Original comment by grahamr...@gmail.com
on 3 Dec 2007 at 3:12
Original issue reported on code.google.com by
astopf...@gmail.com
on 31 Aug 2007 at 2:00