I had successfuly adopted similar approach on my current project. First it's not unit, but mapping integration tests because external resource i.e. database is involved, test's execution time and typical technical issues:
It's much better not to use existed database schema, but create and export it every time from nHibernate using configuration with random schema name. This will eliminate possibility that two or more developers to run integration tests at same time on same schema:
var export = new SchemaExport(configuration); export.Execute(script: false, export: true, justDrop: false, connection: databaseConnection, exportOutput: null);
Remember to cleanup this schema after use. It easy to run out of disk space, etc in several days
Think about move this code from {[SetUp]} to {[FixtureSetUp]} to save test fixture execution time. Work with database takes a lot of time compare to usual in-memory unittests execution time
This kind of test could be triggered less frequently by develoeprs/CI server, compare to usual unittests, due of time and resource consumption. At my project they are scheduled only during night builds or manualy triggered builds.
You could generate nHibernate configuration in runtime, so "../../../Northwind.Web/NHibernate.config" is not required
Instead of using SQL Server you could use SQLite in many cases, but mapping is usually specific for each SQL engine