Unit Testing NHibernate DALs – What Are You *Really* Testing?

Someone new to NHibernate recently asked me how to unit test their data access layer which uses NHibernate.  I’ve already sent him my thoughts on it, but figured it may make for a good blog post to get some of the community’s reaction. 

What Are You *Really* Testing?

From my perspective, there are (at least) a couple questions you should always be asking yourself when practicing TDD or just testing in general:

  1. What am I really testing here?  My code or 3rd party/framework code? 
    • At some point you need to trust the frameworks your using or else you’ll end up testing the whole .NET framework…   Not good!
  2. How much value is really being gained from this test that I am writing?  A quick quiz…
    • Which test do you think would bring the most value?
      • a) A unit test which uses a mocked ISession to verify that when Save(entity) is called that NHibernate does what it’s supposed to do?
      • b) A unit test to make sure NHibernate is generating the correct sql for an HQL query or Criteria call which it’s supposed to do?
      • c) An integration test which verifies that the mapping files you’ve written are configured correctly to map your domain objects to your database tables?
    • Answer?  More than likely, C is probably the best answer to this question.  If all you have are unit tests with no state-based integration tests, that’s probably a bad sign.  At some point you’ve got to write integration tests to make sure all your components work together, especially in your data access/persistence layer.

Exceptions

Now, if for some reason you have another layer of abstraction in there like PersonRepository -> IPersistenceFacade -> NHibernate, then driving out the interaction between your PersonRepository and IPersistenceFacade is probably a good idea.  But that’s probably as far down as I’d go for unit tests.

Also, if you’re not using an ORM and have to use vanilla ADO.NET to hand roll your own data access/mapping layers, then I would most definitely recommend driving that out using TDD and unit tests.  But hopefully this is not something you’re having to do for the most part.

Final Thoughts

So far in my current project, I’m only using integration tests for my persistence layer (aka DAL) to verify that my mapping files are correct.  The nice thing is that NH makes this really easy with its SchemaExport tool to very easily generate your database schema from your mapping files.  So I’m using that along with a couple hand-rolled utilities and factories for generating and inserting sample data to use for integration testing purposes.

Of course, having automated unit tests for as much of your application as possible is still a great goal, but sometimes it needs to be weighed against how much business value it’s going to help you deliver in terms of increasing the maintainability and testability of your code.  However, when in doubt, write a test!

Your Thoughts?

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

This entry was posted in nhibernate, patterns, tdd, tools. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

3 Responses to Unit Testing NHibernate DALs – What Are You *Really* Testing?

  1. Great post. Often this is a difficult thing to grasp when combining NHibernate and Unit Tests.

    I generally separate the tests into 2 namespaces (or assemblies) so that TDD.NET can run them independently.

    I have my Unit Tests that just test the behavior of my constructors, collections, and business rules. Then I have my integration tests that actually test to see if I can save and load a customer, for example.

    The problem that I face is that while it is easy to to TDD to drive out your mapping in this way, later on when you make a mapping change it will make ALL of your integration tests fail. This goes against one of the core concepts of unit testing. We should be able to identify EXACTLY what went wrong from (hopefully) a single failing test.

    But since an invalid mapping will render the session factory creation broken, most of the integration tests will break as well.

    Ideas?

  2. joeyDotNet says:

    Hey Ben,
    Yeah, I definitely know what you mean about dealing with broken session factories. I’m actually almost done with a new blog post on various ways to validate NHibernate mapping files that may help.

    Hopefully I’ll get that posted in the next day or two.

  3. Ben says:

    I know this is an old post, but I’m dealing with these questions now.