Project Description
Extensible fluent API for unit test assertions.

Why?

Why another assertion library? Aren't the assertion APIs that come with the various unit test frameworks good enough? Is this just a lame syntax change using the latest buzz word "fluent API"?

The purpose of Specificity is actually to make assertions more discoverable and extensible. Most assertion APIs use static methods, segmented on multiple static classes based on the type of object you'll be making the assertion on. A generic Assert class holds assertions for Object types. A StringAssert holds assertions for String types. A CollectionAssert holds assertions for ICollection types. While reasonable in the .NET 2.0 era, this approach isn't overly discoverable. Without documentation, would you have expected to find assertions for a List<int> in the CollectionAssert class, or would your first instinct have been to look for a ListAssert class? More important is how this design impacts extensibility. No assertion API is ever going to cover all of the assertions you want to use. There will always be a need to extend or add your own assertions. Imagine, for instance, you have some burning need for an assertion to check that a string contains no vowels, and there's no such assertion in the StringAssert class. Because StringAssert is third-party, you can't really modify it. So, you have to create your own class. But what in the heck would you name it? OK, let's just not care and use something like MyStringAssert. That's certainly no longer discoverable.

With Specificity, the available assertions are discoverable through intellisense. You type "Specify.That(foo)." and all of the assertions that are relevant to the type of "foo", and only the assertions relevant to the type of "foo", show up in the intellisense menu. Extending the assertions is easy. You still have to create a static class, but the name is less important because we use extension methods for the assertions.

The fact that a fluent API is used by Specificiyt is a side effect of the goals, actually.

Specificity isn't tied to any unit test framework. It should work as a drop in replacement for the assertion APIs in any unit test framework you want to use.

   [TestMethod]
   public void Specifity_ShouldWork()
   {
      bool specificityIsGreat = true;
      Specify.That(specificityIsGreat).ShouldBeTrue();
   }

Last edited Feb 19, 2009 at 3:57 PM by wekempf, version 2