your NHibernate assemblies were compiled against Castle 2.1.0.0 (you can tell from the version number listed in the exception message)

Yes i’ve tried with and without Castle.Core.. How do I check which version nhibernate requires? I downloaded the lastest DynamicProxy2 and the lastest Nhibernate releases..

sorry, missed the last comment

did you also include Castle.Core? are you sure that you have the correct versions? maybe your NHibernate.ByteCode.Castle.ProxyFactory was built against a different version of DynamicProxy2 than the one you included.

did you include a reference to Castle.DynamicProxy2 in your test project?

I’ve slightly modified your baseclasses, but whenever i try to run the tests, i get the following exception:

TypeInitializationException: The type initializer for ‘NHibernate.ByteCode.Castle.ProxyFactory’ threw an exception. Could not load file or assembly ‘Castle.DynamicProxy2, Version=2.1.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0×80131040)

Any ideas?

My changes mainly concerns the use of ISession directly instead of the ActiveSessionManager and UnitOfWork.. Also, I have a TestFixtureSetUp method that configures NHibernate and builds the sessionfactory (it is here i get the exception)..

i would test the add/remove methods in separate test methods and leave the base methods in this test fixture stricture for the entity itself, and many-to-ones

but one-to-many’s or many-to-many’s deserver their own test methods

as for what to check on => i’d go for the count plus an ID check if you also have specific tests for the orders, or if you don’t have those, i’d do a complete check

Say you have a CustomerTests class that inherits your baseclass.. Because customers have orders we need to test add/remove orders methods.. Would you then override the buildEntity etc. to also create orders so you can manipulate those or would you have the order creation logic separate (i.e. call BuildEntity() to get a customer, then create and add order to it)?

Also, when you reload your customer, how much detail would you go into to check that the order was there? Would you simply check that order count has increased by one or would you check the details of the order also?

Regards,
Morten

the class shown in this post is only useful to test the correctness of your mappings by making sure that CRUD operations work for all entities. and as mentioned in the previous post, we also write tests for each specific custom query that we write.

our higher level code (the one that indees communicates with repositories for all NH-related tasks) is always tested with mocked repositories.

Supposing that you follow the multi-layer approach to your project, this code would be used in testing persistence with NHibernate, right? So higher-level code which would normally interact with NH-backed repositories would actually interact with fake version of such, just so you can keep the different test types separate…Am I right??