We have been using NHibernate for most of our apps here in our company and having persistence tests for each business object in your integration test suite in my opinion is definitely a must.

My current project which has minimal number of tests, most of them are just persistence tests who were able to capture breaking changes in DB schema or the NHibernate mapping files.

My only dilemma in writing persistence tests is how to effectively/properly write one.  Most of our database scripts contain some default data script which ships with the application.  Majority of the data in this script are reference tables. 

Before, i just depended on this default data script.  Test cases assumed that the default data is not altered by other test cases, and if ever they changed any data, they should revert it back to its previous state.  

It's a team environment and you can't be sure that every test cases written by the team members reverts altered data to its previous state.  And when it hits you, you'll soon encounter a failing test run which previously is working.  I don't really know the order of test execution of test cases with NUnit or MbUnit test runners (yet) but its always safe to assume that it is random and there should be no dependencies in the order of test execution.  Not to mention scenarios where you'll encounter conflicting test execution result between TD.NET and your xUnit console runner, or between your development pc and the build server.  It's a pain in the ass trying to pinpoint the test case which caused a failing test run because one test case had altered the dependent data of another.

From then on, my principle became "test cases need to be independent and therefore should not depend on our default data if it needs one".  Which means, he's the one responsible to setup the data it needs.  For instance, if business object A depends on business object B, a test case which tests for saving business object A needs to setup first business object B (it has to make sure business object B values is existing in the DB).  To avoid redundancies, i exposed something like CreateReferenceBusinessObjectB method from the test fixture of business object B which is ran and called by the test fixtures of its dependent business object.

There was a point that i thought this procedure is tedious, maybe i should revert back to my previous principle and give MbUnit's Rollback feature a shot.