I agree that testing the mapping is very important. My goal has been to test my querying logic separate from the mapping so I can leverage PersistenceSpecification (from FluentNHibernate.Framework) utility to do mapping tests.
A developer on Stackverflow.com had a good idea: http://stackoverflow.com/questions/448405/nhibernate-testing-mocking-isession#448775 His approach of exposing IQueryable is really what I was looking for. I don't have to implement IQueryable myself. And my repository/mapping code gets reduced to: [Test] public void Should_get_customer_by_customer_number4() { var repository = MockRepository.GenerateStub<IRepository>(); repository.Expect(x => x.FindBy<Customer>()) .Return(_customers.AsQueryable()); Customer actualCustomer = _custRepository.FindByCustomerNumber("100313"); Assert.... code here } Where _customers is my list of test data in a IList<T>. And my mapping (integration) tests look like: [Test] public void Should_persist_Customer_to_db_and_read_back() { new PersistenceSpecification<Customer>(Session) .CheckProperty(x => x.CustomerNumber, "11111") .CheckProperty(x => x.Name, "Jones Inc.") .VerifyTheMappings(); } For my team, I think this approach will mean elimination of a ton of setup/teardown test code. And it appeals to my Seperation of Concerns sensibilities. Isn't the whole point of LINQ and LINQNHibernate to have a consistent query language/mechanism? If I do a good job of seperating the concerns of my repositories, mappings, and NH itself, then my query code in my repository should have no knowledge of SQL or relational database structures. It should be concerned with filtering or querying a list of objects for the domain. So why not arrange the test code in the same way (seperating concerns)? I do want to look at NDBUnit though, so thanks for the tip and the other feedback! Troy On Thu, Jan 15, 2009 at 7:36 PM, Stefan Sedich <[email protected]>wrote: > > How is this testing your queries though? How is an in memory > collection going to mimic your relational DB and validate your mapping > files are correct? Cascades work etc etc. > > I still think NDBUnit is the way to go when testing your repository layer. > > > > Cheers > Stefan > > On Fri, Jan 16, 2009 at 10:31 AM, Troy Tuttle <[email protected]> > wrote: > > Yes, by itself it is very similar. But when we get to a full suite of > > integration tests, I have to manage cleanup so the db is in a good state > > before the next test runs. But an in-memory collection will be cleaned > up > > for me automatically by the garbage collector (or at least I don't have > to > > worry about it). > > > > > > On Thu, Jan 15, 2009 at 4:36 PM, Roger Kratz <[email protected]> > > wrote: > >> > >> <<It's a lot easier to create an in-memory list of customers to query > >> against than setup records in the db.>> > >> Why? Maybe I'm missing something but... > >> inMemList.Add() vs repository.Add() is pretty similar? > >> > >> > >> ________________________________ > >> Från: [email protected] [[email protected]] för Troy > Tuttle > >> [[email protected]] > >> Skickat: den 15 januari 2009 22:29 > >> Till: [email protected] > >> Ämne: [nhusers] Re: Testing NHibernate, Mocking ISession > >> > >> That's what we are currently doing now, but as the domain model grows, > the > >> integration tests can get huge when testing queries with multiple > criteria > >> (like a search screen). I'm finding most of the work is in getting the > >> database in the correct state for these kinds of respository/integration > >> testing. So, my thought is, just test the integration by using > >> PersistenceSpecification.VerifyTheMappings(), and test the queries in > >> isolation (mocked). It's a lot easier to create an in-memory list of > >> customers to query against than setup records in the db. > >> > >> Thanks for the feedback though. > >> > >> tt > >> > >> On Thu, Jan 15, 2009 at 2:47 PM, isaiah perumalla > >> <[email protected]<mailto:[email protected]>> > >> wrote: > >> > >> In my experience, i found it useful to simply write integration-tests > >> to test the repositories. > >> I generally avoid mocking 3rd party type such as ISession since the > >> interaction tests will most like be quite fragile > >> > >> On Jan 15, 1:22 pm, "John Teague" > >> <[email protected]<mailto:[email protected]>> wrote: > >> > Are you testing business logic that is using your repository, or are > you > >> > testing the repository itself? > >> > > >> > On Thu, Jan 15, 2009 at 1:23 PM, Troy T. > >> > <[email protected]<mailto:[email protected]>> wrote: > >> > > >> > > Hi, > >> > > I'm using Linq to NH in a project, and would like to test my > >> > > repository code without hitting the database. I have code in my > >> > > repository as: > >> > > >> > > public class Repository : IRepository > >> > > { > >> > > (... code snipped for brevity ...) > >> > > >> > > public T FindBy<T>(Expression<Func<T, bool>> where) > >> > > { > >> > > return _session.Linq<T>().Where(where).FirstOrDefault(); > >> > > } > >> > > >> > > } > >> > > >> > > Where _session is injected into the repository class as ISession. > >> > > Does anyone have some ideas on how to test this repository query > code > >> > > without hitting the database? I'm using Rhinomocks for mocking. > >> > > >> > > My idea is to create a List<T> of Customer objects in the unit test > >> > > code (my test data), and mock out ISession and have it return that > >> > > test data when .Linq<T> is called on the session. To do that I've > >> > > started creating my own test stub that implements IQueryable that > >> > > would be responsible for returning the test data, but I'm having > >> > > trouble making that work. > >> > > >> > > So, just wondering if anyone could suggest a better path to > accomplish > >> > > this? Or am I on the correct path? > >> > > >> > > Thanks! > >> > > Troy > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > -- > Stefan Sedich > Software Developer > http://weblogs.asp.net/stefansedich > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
