Proteus: Unit Test Utility and Domain Foundation code goes OSS!

Many viewers of one or more of my screencast series, Summer of NHibernate or Autumn of Agile, have seen me make use of several utility and base class libraries that I have developed over the years.  Some have expressed interest in using some of these libraries in their own work projects.  Some have asked permission to do so (granted!).  Still others have even de-compiled some of these and attempted to pass them off as their own work smile_angry

Some have asked if the source for these libraries could be made available as open-source, either out of a curiosity as to how they work or as a precursor to the adoption of these libraries in their own work (e.g., if you can get your hands on the source, then using such libraries inherently carries less risk since you can bug-fix, maintain, and otherwise support yourselves were I to disappear from the world tomorrow or decide not to update these libraries when .NET 7.0 is released in 2015).

I am pleased to announce that I have decided to do exactly that: after some minor code-cleaning and additional commenting to improve the auto-generated API reference documentation, I’m happy to report that these libraries have now been released as a single open-source-software project I have dubbed Proteus.

From our good friends at Wikipedia (source of all knowledge in the Internets), the name Proteus connotes “first”, “primordial”, or “firstborn” as well as forming the root of the word protean carrying further connotations of “flexibility”, “versatility”, and “adaptability”.  All of these adjectives describe aspects of what I was trying to accomplish with these libraries and so I have co-opted the name of the Greek god for this project (hopefully Zeus won’t strike me down for it).


Providing a set of base classes from which to derive your unit test fixtures, this library ensures consistency of test categorization, offers many conventions that help effectively drive the use of the NDbUnit tool to support database state management during integration tests, and offers several convenience methods to further assist in unit-test-writing.


Containing a series of base classes to support persistence in Domain Model objects, this library offers a set of core classes and interfaces that simplify the definition of persistent entities as well as offering an implementation of a collection of Specification pattern base classes to simplify the coding of specification classes in your solutions.

Namespace Change

Part of preparing this code for release involved changing the namespace and assembly names from their prior root to the new Proteus namespaces and assembly names.  Otherwise these libraries (at least in this initial release) are identical (API-compatible) to their prior unreleased counterparts in every way.

This means that to migrate to these new versions from the prior versions that were previously only available ‘unofficially’ in the code sample downloads that accompany some of my screencasts all one needs to do is to follow these steps:

  1. delete the prior binaries from your solutions (*.Common.Utility.UnitTest.dll and/or  *.Domain.Foundation.dll)
  2. download the new binaries and reference them into your solution(s) as needed
  3. do a solution-wide search-and-replace to substitute the prior namespace instances with the new Proteus namespaces (e.g., using Proteus.UnitTest and using Proteus.Domain.Foundation)
  4. you’re done

ONE BREAKING CHANGE: Rhino.Mocks Dependency Eliminated

A source of continuing challenge for me with this codebase was the Proteus.Utility.UnitTest library’s dependency on the Rhino.Mocks.dll assembly.  I (reluctantly) took this dependency from the beginning with this library so that the UnitTestBase class could provide an instance field of type Rhino.Mocks.MockRepository as a convenience for test-authors to avoid the need to constantly new-up an instance of the MockRepository class just to create mock objects for their tests.

For a time this approach worked just fine for my library.  But then things got really messy for me when Ayende (cleverly) actually released two functionally-compatible but syntactically-incompatible instances of RhinoMocks 3.5.  One was .NET 2.0-compatible and didn’t support lambda statements and the other supported .NET 3.5 and introduced a very succinct statement syntax heavily leveraging lambda expressions.

While this was great for users of RhinoMocks (myself included, of course), for the Proteus.Utility.UnitTest library it meant that I needed to compile two instances of this library as well, one for .NET 2.0 and another for .NET 3.5.  Not the end of the world, but annoying all the same both for me as a library author and for users of the library to keep straight too.  Begrudgingly, I did so however as I saw no other choice in the matter as like Ayende I also wanted to support .NET 2.0 scenarios with my library.

With the moving of the code to the Proteus.Utility.UnitTest library, I am hereby taking this opportunity to once and for all eliminate the dependency on RhinoMocks — not because I don’t like RhinoMocks (it continues to be my favorite .NET mock objects tool) but because the instance of the MockRepository class is just no longer needed for RhinoMocks.  With the support Ayende has introduced for the so-called AAA (Arrange, Act, Assert) pattern with the framework, most if not all mock object creation can now be performed on the static MockRepository class without requiring an instance of the class to do the work for you.  This has reduced (if not eliminated) the value of having an instance field in the test fixture base class that holds a MockRepository instance and so I have herewith factored it completely away for good.

The benefit of this to me (and to you!) is that there is once again just one version of the Proteus.Utility.UnitTest library regardless of your target .NET framework version.  Hallelujah!  Simplicity is achieved once again and order returns to the universe!

Hosted on Google Code

If you’re interested in the code, its now hosted on Google Code at

If all you want are the updated binaries, you can find those on the downloads tab of the same Google Code site.  Note that there are two downloads, one each for each of the libraries but both ZIP archive files contain the single entire API reference document (chm format) for both libraries (e.g. there are two libraries but only one common API reference document).

NDbUnit Version Integration

If you are using the Proteus.Utility.UnitTest library for its integrated support of the NDbUnit tooling, then you are advised that the binary of NDbUnit that is supported by the Proteus.Utility.UnitTest library is included in the download for this library from the above-referenced Google Code site.  I cannot be responsible for attempts to integrate any other NDbUnit release with this code (which is why there is a NDbUnit.Core.dll included with this download)!

Since I am the primary active maintainer of the NDbUnit project, I think its safe to say that this collection of software libraries will mature pretty much in sync with each other but to avoid any confusion about what version of the NDbUnit library is supported by what version of the Proteus.Utility.UnitTest library, users are strongly encouraged to use the NDbUnit binary in the Proteus.Utility.UnitTest library archive download at all times just to be safe smile_tongue

Happy coding~!