This project is read-only.

AssertEx.That:

The reason that the assertions in existing unit testing frameworks break the expected and actual value into two separate parameters is so you can get a worthwhile failure message. For example if you did an Assert.IsTrue(x == 5) and it failed you would just be told that it was false. When you do Assert.AreEqual(5, x), you get a failure message telling you that 5 is not equal to 99 (if x's value was 99).

Now that we have lambda expressions in .Net, we can write the code like this: AssertEx.That(() => x == 5). The x==5 expression tree can be processed and converted into something like Assert.AreEqual(5, x).

Lambda expression / Expression trees are a bit of work to build and therefore can cause performance issues. If you need assertions to be evaluated extremely fast, use the standard Assert statements or better yet use if statements. The performance issue isn't a problem for 99.999% of tests. The only time I reverted to the original Assert statements was when I was comparing two bitmaps pixel by pixel.

Following is a list of the "transalation" done by AssertEx.

Boolean expressions:
AssertEx.That(() => bool) is similar to Assert.IsTrue(bool).
AssertEx.That(() => bool == true) is similar to Assert.IsTrue(bool).
AssertEx.That(() => bool != false) is similar to Assert.IsTrue(bool).
AssertEx.That(() => !bool) is similar to Assert.IsFalse(bool).
AssertEx.That(() => bool == false) is similar to Assert.IsFalse(bool).
AssertEx.That(() => bool != true) is similar to Assert.IsFalse(bool).
AssertEx.That(() => complexBooleanExpression) is similar to Assert.IsTrue(complexBooleanExpression). This is a fallback if the expression is too complex.

Binary comparisons:
AssertEx.That(() => actual == expected) is similar to Assert.AreEqual(expected, actual).
AssertEx.That(() => actual != expected) is similar to Assert.AreNotEqual(expected, actual).
AssertEx.That(() => object == null) is similar to Assert.IsNull(object).
AssertEx.That(() => object != null) is similar to Assert.IsNotNull(object).

Type comparisons:
AssertEx.That(() => instance is type) is similar to Assert.IsInstanceOfType(instance, type).
AssertEx.That(() => !(instance is type)) is similar to Assert.IsNotInstanceOfType(instance, type).

String comparisons:
AssertEx.That(() =>
AssertEx.That(() => value.EndsWith("xxx"))
AssertEx.That(() => value.EndsWith("xxx", true, CultureInfo.InvariantCulture))
AssertEx.That(() => value.EndsWith("xxx", StringComparison.OrdinalIgnoreCase))
AssertEx.That(() => value.StartsWith("xxx"))
AssertEx.That(() => value.StartsWith("xxx", true, CultureInfo.InvariantCulture))
AssertEx.That(() => value.StartsWith("xxx", StringComparison.OrdinalIgnoreCase))

AssertEx.Inconclusive:

This is exactly the same as AssertEx.That but marks the test as inconclusive instead of failed. Your unit tests should only test one thing. If a unit test has multiple assertions then it is probably that they should be broken into multiple tests. Convert the AssertEx.That's into AssertEx.Inconclusive for the parts that are tested in the other unit tests.

AssertEx.Throws:

This is common in other unit test frameworks, but not MSTest. It is better to use Throws than to use the ExpectedException attribute since Throws can be narrowed down to the line of code that should throw the exception. There are three overloads that can be used based on what you are checking for:

overload 1:
var exception = AssertEx.Throws(() => code);

overload 2:
AssertEx.Throws(
() => code,
"message");

overload 3:
AssertEx.Throws(
() => code,
exception => testException);

Last edited Jun 14, 2009 at 8:49 PM by JeffLeBert, version 3

Comments

No comments yet.