be careful though with the transaction roll back approach, it can hide some subtle bugs, which may only be found by committing to a db. I seen a project where they had a all their repositories tested by executing queries and then rolling back the transaction, but when they went to production there were quite a few bugs. In the end they had to write integration tests to flush these out. IMO at some point you still need to test the integration/functional parts, to ensure things are working, and there is little benefit in testing the queries alone
On Jan 16, 8:46 am, "Troy Tuttle" <[email protected]> wrote: > I've heard others using the transaction approach as well. It would > definitely help streamline the setup/teardown code. > > Thanks. > > On Fri, Jan 16, 2009 at 3:06 AM, Roger Kratz <[email protected]>wrote: > > > There are many different approaches for this, I prefer (I'm using naked > > nunit, don't know much about nDbUnit)… > > > * Create the db-schema (and some must-have-data in db) in setupfixture, > > using SchemaExport > > > * Run every test in a tran that's rollbacked after the test > > > Works in 95% of the cases for me. > > > *From:* [email protected] [mailto:[email protected]] *On > > Behalf Of *Troy Tuttle > > *Sent:* den 16 januari 2009 02:32 > > *To:* [email protected] > > *Subject:* [nhusers] Re: Testing NHibernate, Mocking ISession > > > 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
