New Assertions for MbUnit v3

[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);

Gallio v3.0.4

Gallio v3.0.4 is finally there! Download it and enjoy!

Rhino.Mocks 3.5: The new generic list constraint.

Oren Eini has finally released Rhino.Mocks 3.5 RTM. As written in Oren's article (many thanks to him for the credits), I had submitted some time ago a patch, which adds a new useful constraint for generic collections. Some explanations are perhaps needed:

Suppose that you are setting up some expectation on a method that takes a collection as parameter: a list of strings, for example.

public interface IFoo
{
  bool DoSomething(List<string> values);
}

With Rhino.Mocks 3.4, you can specify a constraint on the input collection. For instance, you can verify that the fifth element of the collection has the value "Hello".

Expect.Call<bool>(mockFoo.DoSomething(null))
  .IgnoreArguments()
  .Constraints(List.Element(4, Is.Equal("Hello"))
  .Return(true);

Unfortunately, the List.Element method can only take an Int32 as first parameter. Thus, it makes the constraint only usable with Int32-indexed collections, such as lists and arrays. It is a shame if your parameter is a dictionary.

That's why I have written a new abstract constraint (KeyedListElement) and overriden the List.Element with a new generic method. The usage is very similar. It is actually a kind of generalization of the former method.

public interface IFoo
{
  bool DoSomething(Dictionary<string, string> values);
}

Expect.Call<bool>(mockFoo.DoSomething(null))
  .IgnoreArguments()
  .Constraints(List.Element<string>("Value1", Is.Equal("Hello"))
  .Return(true);

The example above defines a constraint on the parameter (a dictionary of strings keyed by strings). The value at index "Value1" must be equal to "Hello". Note the generic signature of the method, which specifies the type of the key.

Hope it helps!