Click here to Skip to main content
13,045,228 members (44,696 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


Posted 11 Oct 2009

Testing NHibernate Projects

, 11 Oct 2009
Rate this:
Please Sign up or sign in to vote.
Testing NHibernate Projects

Based on my previous article Artem Smirnov[^] posted a question about how to test a Repository(DAL) method in a project using Nhibernate as ORM. Here is his question:

"I wanted to unit test a similar, but more common, problem: a Repository method. I.e., create a test Order for a particular date, and test that the FetchOrdersByDate method returns this order if the date matches. My guess was that I could just create an Order, attach it to the session without saving it to the database, then somehow stub the database and make NH fetch it from the cache. After doing a lot of search, I discovered that this is impossible, so I had to hit the database for every test. Given that NH looks extremely flexible, i.e., Interfaces everywhere, this is kind of strange.."

Here is my answer:

The problem related to testing a Repository method is a very common one and people suggest different solutions to this problem. Here are some of them:

  • Mock your Repository method by using a Mocking library or by hand. But this suggestion is not valid all of the time. If you have native SQL or use NH Transformers to produce DTO's mocking is not an option.
  • Use an in-memory database like SQLite for your tests. But if you have native SQL or develop against a legacy database or use part of a legacy database, you cannot follow this approach.
  • Take script of your production database and create an empty test database. Run your tests against the test database. This method also has some drawbacks, to name a few, tests take longer to run, you have to keep your test database up to date with the live one, you have to deal with some phantom objects not directly managed by your domain (for example your domain contains Instructor class just for integrity reasons and you do not have code to deal with Instructor instantiation because you do not actually need this piece of function. But somehow you have to create Instructor objects for testing). You can solve the first two problems with Continuous Integration, but the later can be tricky to solve. However this last approach has one big outcome, that is, you will likely have failing tests if something goes wrong with your database.

I personally tend to follow the last approach for NH specific testing and write pure unit tests otherwise.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Ali Ozgur
Team Leader PragmaTouch
Turkey Turkey
- Software developer
- Has BS degree in Computer Engineering
- Has MBA degree
- Programmed with C, C++, Delphi, T-SQL and recently C#
- Little educational experience with Prolog
- Feel enthusiasm about NHibernate and LINQ
- Love to develop on Cuyahoga Web Framework
- Developer of PragmaSQL Editor
(Code Project Members Choice Winner for 2009 and 2010)
- Developed JiraTouch and MoodleTouch for iPhone
- PragmaTouch Lead (

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.170713.1 | Last Updated 12 Oct 2009
Article Copyright 2009 by Ali Ozgur
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid