I am using NUnit to unit test my NHibernate code. In each test class I have a setup and teardown function which begins a transaction and rolls back the transaction respectively. This is so that none of my test data hits the database as I don't want it full of unit test data.

I then want to write tests to test various areas of functionality such as creating updating etc. I want all of these tests to be pretty much self contained however I am finding it extremely frustrating that I can't, for example create a record and then read it back within the same session without flushing and evicting the object (e.g. session.Flush(); session.Evict(rec);). When a record has children and grand children etc, this becomes even more frustrating, equally frustrating is when I try and test code in higher levels which calls the NHibernate and I seem to have to do the same thing.

I'm sure I must have missed something wit this - please help.

That's because you are basically trying to work against NHibernate's built-in caching mechanism.

Do you really need to test NHibernate? We have a pretty good test suite ourselves :) If you just need to test stuff like cascades, you can use session.Contains().

Sergey,
I don't think that I agree with you here.
I do want to test the persistence. Not so much to verify that NHibernate works, but to verify that I am mapping all the properties that I think I should, that I can get assoication correctly, that the mapping is valid, etc.

Additionally, there is an issue when I want to use NHibernate for queries that contains business logic.

GetAllOutstandingLoads() - for instance, is something that you really should test, especially since most of the time it just construct a query and execute it.

s1mm0t,
There are several ways to test NHiberante:

Here is a favorite of mine:
http://www.ayende.com/Blog/archive/7183.aspx

Because of issues with SQLite data/time handling, and sharing several session on the same database, I moved to using SQL Server CE (embedded SQL).
Which still has the same properties as the previous test, even though it touches the filesystem

Sergey / Ayende thanks for your speedy responses.

Sergey I'm sure NHibernate doesn't need testing - if I thought it did I probably wouldn't be using it ;). I don't however have as much faith in my ability to set up the mappings etc correctly which is what I really want to test.

Ayende, your blog entry was very interesting but I don't think that gets me round my problem of not wanting to have to keep on flushing and evicting objects.

To be quite honest I see not being able to read the same data into memory within the same session as quite a big restriction. I fail to see why this is necessary, if NHibernate is clever enough to determine that I have already read the data in once, why can't it just return that reference rather than throwing an exception? This basically forces me to manage references to objects in such a way that is inconvenient and becomes overly complicated especially when you start abstracting your application into multiple layers.

Again I just feel as though I have missed something obvious.

Throwing exception??
Can you clarify?

It will return the same reference that you gave it.

Your post got me thinking, and it made me realise what I was doing wrong.

I was doing the following to read records from the database:



Calling this code after just creating the contact I was trying to read caused a NonUniqueObjectException to be thrown.

I have now changed the code to the following:


This now seems to have sorted my problem.

Thanks for your help.

You can also use session.Clear() to clean-up the entire session and to give you a fresh start without committing data and creating a new session.

Another option would be to provide you own connection instance and to create as many session with it as you need.