I recently started working with a new team that uses NUnit as their testing framework. While I think NUnit is a solid framework, I don’t think the default API and style lead to effective tests.
As an advocate of Test-Driven Development, I’ve always appreciated how context/specification-style frameworks such as Machine.Specifications (MSpec) allow for the expression of executable specifications which model how a system is expected to be used rather than the typical unit-test style of testing which tends to obscure the overall purpose of the system.
To facilitate a context/specification-style API, I created a base class which makes use of the hooks provided by the NUnit testing framework to emulate MSpec. I’ve published this code under the project name NUnit.Specifications.
The following is an example NUnit test written using the ContextSpecification based class from NUnit.Specifications using the Should assertion library:
One nice benefit of building on top of NUnit is the wide-spread tool support available. Here is the test as seen through various test runners:
Resharper Test Runner:
TestDriven.Net: (see notes below)
NUnit Test Runner:
NUnit Test Adaptor for Visual Studio:
One caveat I discovered with the TestDriven.Net runner is it’s failure to recognize tests without the specification referencing types from the NUnit.Framework namespace (e.g. TestFixtureAttribute, CategoryAttribute, use of Assert, etc.). That is to say, it didn’t seem to be enough that the spec inherited from a base type with NUnit attributes, but something in the derived class had to reference a type from the NUnit.Framework namespace for the test to be recognized. Therefore, the TestDriven.Net results shown above were actually achieved by annotating the class with [Category(“component”)] explicitly.
As a convenience, NUnit.Specifications also provides attributes for denoting categories of Unit, Component, Integration, Acceptance, and Subcutaneous as well as a Catch class (as provided by the MSpec library) for working with exceptions.