How do I do TDD efficiently with NHibernate?

问题:

It seems to me that most people write their tests against in-memory, in-process databases like SQLite when working with NHibernate. I have this up and running but my first test (that uses NHibernate) always takes between 3-4 seconds to execute. The next test runs much faster.

I am using FluentNhibernate to do the mapping but get roughly the same timings with XML mapping files. For me the 3-4 second delay seriously disrupts my flow.

What is the recomended way of working with TDD and NHibernate?

Is it possible to mock ISession to unit test the actual queries or can this only be done with in memory databases?

回答1:

I am using the Repository Pattern to perform Database operations, and whenever I run my Tests I just run the higher-level tests that simply Mock the Repository (with RhinoMocks).

I have a seperate suite of tests that explicitly tests the Repository layer and the NHibernate mappings. And those usually don't change as much as the business and gui logic above them.

That way I get very fast UnitTests that never hit the DB, and still a well tested DB Layer

回答2:

Unit testing data access is not possible, but you can integration test it. I create integration test for my data access in a seperate project from my unit tests. I only run the (slow) integration tests when I change something in the repositories, mapping or database schema. Because the integration tests are not mixed with the unit tests, I can still run the unit tests about 100 times a day without getting annoyed.

回答3:

See http://www.autumnofagile.net and http://www.summerofnhibernate.com

回答4:

Have you tried changing some of the defaults in the optional configuration properties? The slowdown is most likely related to certain optimizations nhibernate does with code generation.

http://nhibernate.info/doc/nh/en/index.html#configuration-optional

It seems like an in memory db is going to be the fastest way to test a your data layer. It also seems once you start testing your data layer you're moving a little beyond the realm of a unit test.