[Digression] This post has been sitting in a somewhat unfinished state for a long time. It feels good to finally post it!
In rewriting my baseball game, CSFBL, I made the decision to use Castle ActiveRecord (built on top of NHibernate) to handle the persistence of my domain model. As a result, I needed to find a simple but effective way to unit test this implementation.
The unit tests needed to accomplish the following:
- Test the initialization of ActiveRecord (which validates the database schema against the object mappings).
- Test object validation (since I am using Castle’s Validation component and the
ActiveRecordValidationBase<T> base class).
- Ensure that a domain object can be persisted to the database.
- Ensure that a domain object can be retrieved from the database.
- Ensure that multiple instances of an object with the same persisted primary key are equal.
How, then, do we do this? Continue reading
A while back, I wrote a blog post, A quick introduction to Nant, which gave, well, a quick introduction to building C# libraries using NAnt.
Since then, I’ve been using NAnt to do a lot more — notably, to run unit tests and to report on test coverage (using NCover and NCoverExplorer). The usage is pretty straightforward, and I think you’ll see how each step builds on the previous step.
- To run a default build (excluding unit tests):
- To build all projects and unit tests (but don’t run :
- To build all projects and unit tests, and run tests using NUnit:
- To build all projects and unit tests, and run tests using NCover to generate coverage reports:
- To build all projects and unit tests, run tests using NCover to generate coverage reports, and open those reports in NCoverExplorer:
The sample below is my NAnt build file. A few notes first.
- There are only two projects referenced: Project1 and Project1.Tests. Repeat the appropriate sections to build against additional projects.
- nunit-console.exe is expected to be in the system path.
- nunit-console.exe, ncover.console.exe, and ncoverexplorer.exe are expected to be in the system path. I recommend you download and install TestDriven.Net to have all of these in a convenient place.
Now, on to the build file. It should be self-explanatory, but I added some XML comments for your convenience.