**[Update 11/12/2008: As explained in a comment below, Jeff has restored the delta equality assertion with a set of methods named**.]

*Assert.AreApproximatelyEqual*The latest version of

**MbUnit v3**which comes with Gallio v3.0.4, has a completely new set of assertions methods. It has been entirely re-written by Jeff and Vadim. The new MbUnit.Framework.Assert class is indeed more consistent. It makes an intensive use of generics and lambda expressions too.

Of course, it comes at the cost of some breaking changes, because many methods have been removed or renamed. But the new assertion methods are very powerful and much more flexible than before; so those breaking changes are easy to fix.

For example, the following method has been discarded:

Assert.AreEqual(double expected, double actual, double delta)

The delta parameter specified the maximum acceptable difference between the expected and the actual values. That assertion was useful when comparing the result of a calculation involving potential rounding issues. The following assertion was passing because 3.14 and 3.14159 differs less than 0.01.

Assert.AreEqual(3.14, 3.14159, 0.01);

The latest version of MbUnit proposes to use that new generic assertion method instead.

`Assert.AreEqual<T>(T expectedValue, T actualValue, Func<T, T, bool> comparer)`

The signature of the method seems much more complicated, especially if you are not familiar with generics. However, thanks to the C# 3.0 type inference, you do not need to specify explicitely any type parameter. So in fact, you can write the following line, which has the same effect has the example above.

Assert.AreEqual(3.14, 3.14159, (x, y) => Math.Abs(x - y) <= 0.01);

## 3 comments:

Hehe, actually the AreEqual for doubles with a delta was an oversight on our part.

You can still use OldAssert.AreEqual in MbUnit.Compatibility.dll for this function for now. I've opened a bug.

http://code.google.com/p/mb-unit/issues/detail?id=326

Do you think this assert should still be called AreEqual?

Do you mean AreRoundEqual or something? I think it would only make sense if we provide a complete dedicated set a similar methods with several overloads for all sorts of rounding engines. Otherwise, it is yet another equality assertion and overloading AreEqual is fine.

We now have Assert.AreApproximatelyEqual.

It works for any type that defines a suitable subtraction operator and implements IComparable{T}.

This includes Single, Double, Decimal, Int32, DateTime, TimeSpan, etc...

Enjoy!

Post a Comment