[Hm][Ed]
[Ins][PU]
[De][PD]

(abbreviated, the actual buttons aren’t abbreviations, they actually have the words written out “Insert”, “Delete”, “Page Down”)

Often you develop something under tight deadlines and with no real specifications or design and then the code creep; developers were never involved in the selling process of non-existent features so you can’t go ask the customer what the specifications should be and the sales team has no idea. Lack of documentation means the developers then make best guess at interfaces and API’s and make assumptions about business processes. So, when with hindsight, you can revisit something you did under those conditions you can rebuild it with better understanding. I so infrequently get that opportunity.

public class UserRepositoryTests : DatabaseTest
{
[Test]
public void Test_Get_By_User_Id()
{
var userRepository = new UserRepository(session);

var user = userRepository.GetByUserId(1);

Assert.IsNotNull(user);
}
}

public class DatabaseTest
{
protected ISessionFactory sessionFactory;
protected ISession session;

public DatabaseTest()
{
sessionFactory = CreateSessionFactory();
}

public void SetUp()
{
session = sessionFactory.OpenSession();
}

public void TearDown()
{
if (session != null && session.IsOpen)
session.Close();
}
}

I have to manually call SetUp() and TearDown() from the setup/teardown routines in any classes that inherit from this (I ran into a problem using the SetUp and TearDown attributes in DatabaseTest because NUnit seemed to not call them if I also had functions in the child class with SetUp and TearDown attributes).

This ensures that before each test is run I have a clean ISession to use and that it’s properly disposed of after each test is run.

For unit tests on classes that utilize the data access layer, you won’t want to be connecting to a live database anyways so you can simply stub/mock out your repositories and not have to worry about creating NHibernate sessions.