Integration Testing with SQL Server Express 2008, NHibernate, and MSTEST

When dealing with NHibernate, I find that it’s important to write tests to make sure that I’ve created my mapping files correctly–that is, that properties actually are mapped correctly, that I remembered to specify an IUserType where appropriate, that I remembered to make my properties virtual, that I remembered to add a parameterless constructor, that I set the right cascade option on an association, and so on.

It would be nice if I could run an automated test that would “exercise” my NHibernate mapping file against an actual database to see if it all worked. It’s not really a unit test–I’m not testing NHibernate itself, I’m testing my configuration of NHIbernate–but it’s still appropriate as an integration test.

Ayende Rahien has a spiffy implementation of an in-memory database test that uses NHibernate’s SchemaExport to build up an empty, in-memory SQLite database at the start of each NUnit test. His implementation serves as the inspiration for my example.

In my case, I’m working on a little moonlighting project that uses some database-specific features of SQL Server Express 2008, in particular the GEOGRAPHY type and SPATIAL indexes. SQLite wouldn’t help me here–unless I just didn’t want to use it for those particular tests–but I figure that if I’m bothering to write an integration test, then it should actually test the integration against the database that I’m actually using. Additionally, unlike Ayende’s example, I’m using MSTest instead of nUnit because it’s built into Visual Studio and I am a masochist.

Understanding SQL Server Express User Instances

SQL Server Express has the concept of a “user instance” that allows a non-administrator user to attach and detach an *.mdf file to the local SQL Server Express instance. I thought this was what I needed. But there are some things to understand about user instances that confused me and probably confuse other people as well:

• They’re not the same thing as an in-memory database or even a “file-based” database like SQLite. It’s a regular SQL Server database file.
• The file has to exist. Unlike SQLite, if you tell SQL Server Express to attach to an *.mdf that isn’t there, you’ll get an error instead of having the database created for you just in time.
• To access the database, it has to be attached to a SQL Server instance. This means downloading SQL Server Express and installing the service on the machine. It’s not as if your application can just directly access the *.mdf file through some special DLL or anything like that. It really is still client/server.
• Permissions can still be an issue. The SQL Server instance will need to be able to read the *.mdf file, so the NTFS permissions need to be set appropriately; in most cases, this means that NETWORK SERVICE will need to be able to read and write to it.

After spending a few hours learning such things the hard way, I realized that user instances were not necessary for me (VS already runs as administrator, can’t debug in IIS without it). Instead I’ll just use SQL Server Management Objects (SMO) to programmatically set up the database at the start of each test. (More on this later.)

Understanding MSTest Execution Order

On my first attempt, I put my database and NHibernate set-up and tear-down code in methods decorated with the MSTest [TestInitialize] and [TestCleanup] attributes. And this does indeed work well when a single [TestMethod] is executed in isolation. But if I executed more than one test in a single test run, all hell would break loose because the [TestInitialize] for a test that is scheduled to execute might get executed before the [TestCleanup] from a test that has already run.

This seemed like astonishing behavior to me and seems to be just a quirk of Microsoft’s design of MSTest. In nUnit and pretty much any other xUnit framework I’ve tried, the initialize/test/cleanup triumvirate is guaranteed to execute “atomically” before any part of any other test triumvirate is executed. In other words, if you’re running a test run with two tests A and B, then you might see this behavior in the two testing frameworks:

• nUnit: Initialize A > Test A > Cleanup A > Initialize B > Test B > Cleanup B
• MSTest: Initialize A > Test A > Initialize B > Cleanup A > Test B > Cleanup B

That’s because MSTest executes tests in multiple threads, and while for a particular test method you’re guaranteed that its [TestInitialize] and [TestCleanup] methods will be called before and after the test itself executes, respectively, there is no guarantee about its relationship with the other simultaneously executing test methods.

This causes a problem when the test method is assuming exclusive access to a shared system resource, like a test SQL Server Express database that has just been set up for that test method’s exclusive use. My brute force workaround is to use Monitor.Enter() and Monitor.Exit() in the [TestInitialize] and [TestCleanup] methods to force MSTest to execute them in the correct order:

private static readonly object lockObject = new object();
 
[TestInitialize]
public void TestInitialize()
{
	Monitor.Enter(lockObject);
 
	try
	{
		// TODO: Delete any pre-existing SQL Server Express Instance
		// TODO: Set up the SQL Server Express Instance
		// TODO: Set up NHibernate
	}
	catch
	{
		// If something went horribly wrong, release the lock
		// or else MSTest will never finish the test run!
		Monitor.Exit(lockObject);
 
		throw;
	}
}
 
[TestCleanup]
public void TestCleanup()
{
	// TODO: Delete the SQL Server Express instance
	Monitor.Exit(lockObject);
}

Using SMO to Bind It All Together

All that was left was to fill in those TODOs.

Deleting an Existing Database

First up is deleting an existing instance, which is pretty trivial with SMO (just add a reference to Microsoft.SqlServer.Smo.dll, which is available after you installing SQL Server Express, and you’re set):

private static readonly string serverInstance = @"(local)\SQLEXPRESS";
 
private static readonly string databaseName = "EquineTest";
 
private string dataFilePath;
 
private string logFilePath;
 
private void DeleteDatabaseIfExists()
{
	var server = new Server(serverInstance);
 
	if (server.Databases.Contains(databaseName))
	{
		// Something might be caching an open connection, so tell everyone
		// to screw off by forcing their connections shut. If we don't do this,
		// the DetachDatabase() call could faile.
		var sql = string.Format(
			CultureInfo.InvariantCulture,
			"ALTER DATABASE {0} SET SINGLE_USER WITH ROLLBACK IMMEDIATE",
			databaseName);
		server.Databases[databaseName].ExecuteNonQuery(sql);
 
		server.DetachDatabase(databaseName, true);
 
		File.Delete(this.dataFilePath);
		File.Delete(this.logFilePath);
	}
}

Why check for an delete an existing database at the start of a test? In case a previous test failed. Shockingly, MSTest won’t call [TestCleanup] if a test method explodes with an exception. I know, I’m in total agreement with you, what were they thinking?

Figuring Out Where to Put the Files

Simple enough, but you’ll notice that my dataFilePath and logFilePath variables, which should be pointing to my *.mdf and *.ldf database files, respectively, aren’t initialized in my above example. Prior to calling this function, I make sure that my InitializePaths() method is called:

private string GetExecutingDirectory()
{
	var path = Assembly.GetExecutingAssembly().GetName().CodeBase;
	return Path.GetDirectoryName(new Uri(path).LocalPath);
}
 
private void InitializePaths()
{
	var directoryPath = this.GetExecutingDirectory();
 
	this.dataFilePath = Path.Combine(directoryPath, databaseName + ".mdf");
	this.logFilePath = Path.Combine(directoryPath, databaseName + "_log.ldf");
}

This is convoluted way of determining the directory that MSTest created for the current test run. (MSTest sets the working directory to some nonsense in Program Files, so no help there. And [DeploymentItem()] is an absolute nightmare!)

Creating the Test Database

The code for creating the database via SMO is similarly straightforward:

private void CreateDatabase()
{
	var server = new Server(serverInstance);
	var database = new Database(server, databaseName);
 
	var fileGroup = new FileGroup(database, "PRIMARY");
	database.FileGroups.Add(fileGroup);
 
	var dataFile = new DataFile(fileGroup, databaseName, this.dataFilePath);
	dataFile.Growth = 10;
	dataFile.GrowthType = FileGrowthType.Percent;
	fileGroup.Files.Add(dataFile);
 
	var logFile = new LogFile(database, databaseName + "_log", this.logFilePath);
	logFile.Growth = 10;
	logFile.GrowthType = FileGrowthType.Percent;
	database.LogFiles.Add(logFile);
 
	database.Create();
}

The only quirk is that I explicitly set the Growth and GrowthType because on some machines it was defaulting to None causing the integration tests to fail when lots of data is inserted under some circumstances. It seems to be a per-server default setting, but I haven’t bothered to figure out why the default behavior is different among the multiple machines that I own; setting it here guarantees the tests will work consistently.

Initializing the Database and Configuring NHibernate

The last piece of the puzzle is to configure NHibernate and set up the freshly-minted database’s schema. I use the NHibernate’s SchemaExport tool to create the schema for me based on my mapping files. The only caveat is that when using SQL SCHEMAs, the SchemaExport tool won’t create those for you, so they have to be handled explicitly:

[TestInitialize]
public void TestInitialize()
{
	Monitor.Enter(lockObject);
 
	try
	{
		this.InitializePaths();
		this.DeleteDatabaseIfExists();
		this.CreateDatabase();
 
		// The configuration is a static variable, I don't care if the
		// configuration is shared among test methods
		if (configuration == null)
		{
			// Disabling connection pooling is important
			var connectionString = string.Format(
				CultureInfo.InvariantCulture,
				@"Data Source={0}; Integrated Security=true; Initial Catalog={1}; Connection Timeout=120; Pooling=false;",
				serverInstance,
				databaseName);
 
			configuration = new Configuration()
				.SetProperty(Environment.ReleaseConnections, "on_close")
				.SetProperty(Environment.Dialect, typeof(MsSql2008Dialect).AssemblyQualifiedName)
				.SetProperty(Environment.ConnectionDriver, typeof(SqlClientDriver).AssemblyQualifiedName)
				.SetProperty(Environment.ConnectionString, connectionString)
				.SetProperty(Environment.ProxyFactoryFactoryClass, typeof(ProxyFactoryFactory).AssemblyQualifiedName)
				.AddAssembly("EquineBusinessBureau.Model");
 
			sessionFactory = configuration.BuildSessionFactory();
		}
 
		// We definitely need a new session for each test method, though
		this.session = sessionFactory.OpenSession();
 
		// SchemaExport won't create the database schemas for us
		foreach (string schema in schemas)
		{
			var sql = string.Format(CultureInfo.InvariantCulture, "CREATE SCHEMA {0}", schema);
			this.session.CreateSQLQuery(sql).ExecuteUpdate();
		}
 
		new SchemaExport(configuration).Execute(
			true,
			true,
			false,
			session.Connection,
			Console.Out);
	}
	catch
	{
 
		Monitor.Exit(lockObject);
 
		throw;
	}
}

Conclusions and Delusions

Wrap all of this up in an abstract class called IntegrationTestBase, and you’ve got an easy way to write integration tests in a style that’s similar to what Ayende originally posted:

[TestClass]
public class RoleTest : InMemoryDatabaseTestBase
{
    [TestMethod]
    public void CanSaveAndLoadRole()
    {
        object identity;
 
        using (var tx = this.session.BeginTransaction())
        {
            identity = session.Save(new Role(EquineRoles.Administrator, "Administrator"));
 
            tx.Commit();
        }
 
        session.Clear();
 
        using (var tx = this.session.BeginTransaction())
        {
            var role = session.Get<role>(identity);
 
            Assert.AreEqual<string>(EquineRoles.Administrator, role.RoleEnum);
            Assert.AreEqual<string>("Administrator", role.RoleName);
 
            tx.Commit();
        }
    }
}

The first test in a test run takes a while to run, on the order of 6 – 8 seconds. Painful, but this is also an integration test, so it’s not like I’m running them every five minutes, and it’s faster than spinning up the Web site and seeing if it crashed. Subsequent tests, since the NHibernate configuration is already initialized in the static variable, execute much more quickly, about one second per test.

Hope this saves someone a few hours of putting the puzzle pieces together.

Download the IntegrationTestBase example source file.