Right, the reason I refer to them as a unit test is because live interaction with a database is the only way to test a DAO that makes any sense in my opinion. I don't think there is any value to mocking out an entity manager in order to eliminate the database (in JPA it's prob not HSQL, but regardless of it's name you get the idea) because then you are testing virtually nothing. If you passed a string to createQuery on a mocked out entitymanager, there is no way, other than determining that the method actually calls createQuery, to verify that the passed in string does anything useful or is even an actual query. Obviously there are many sides to that whole debate, but I guess my opinion stems from the fact that if you can avoid using mock objects then you should avoid it. I've been using EasyMock over the last couple months to try to mock out DAOs and JBPM logic but I find it takes me 2 to 3 times longer than it has for similar tests that I didn't use mock objects (not scientific I know). I find those libraries so completely unintuitive because they do so much stuff behind the scenes and then give you ambigious errors when something goes wrong. I'd rather my unit tests just write some dummy data into the database and then remove it when it's done. I'd rather deal with the meaningless data than deal with trying to mock it out.
I think this means I'm probably better off with HSQL then. :) On Dec 1, 2007 11:35 AM, Steve Ebersole <[EMAIL PROTECTED]> wrote: > On Saturday 01 December 2007 09:53:30 am Ryan Moquin wrote: > > I think my main concern with this (hence why I'm asking general advice) > is > > that sometimes a unit test might work against HSQL and fail against > another > > database such as MSSQL? Or am I worrying about something I shouldn't? > > > > I did make some progress finally though, I kept connection pooling on in > my > > unit tests since I don't think it's possible for me to run my build > without > > it, and then I stopped using the maven-sql-plugin and went back to the > > hibernate ddl create-drop method of recreating my schema (which I ran > into > > problems with, which caused me to go to maven-sql-plugin previously). > That > > alleviates the database in use when the plugin tries to drop and > recreate > > it. > > > > Of course, this doesn't answer whether or not I should be using an inmem > > database like HSQL ... I think depending on people's experiences on the > > pros and cons will be what will cause me to switch. I'm just worried > that > > I might lose some accuracy in my unit tests going to that approach? > > Speaking theoretically, a *unit test* for your application should not be > concerned with the specific database being used under the covers. That > responsibility would fall under the unit tests of the code actually > communicating with the database (Hibernate). > > I stressed the term unit test above, because it has a very specific > meaning > that is actually not strictly adhered to alot of times; not saying this is > good or bad, just saying it is the case. So really it just comes down to > personal choice. The usual (productive) middle ground between theory and > pragmatism in this realm is to use an in memory database (I actually > prefer > H2 over HSQLDB) > > -- > Steve Ebersole > > Hibernate Project Lead > http://hibernate.org > > Principal Software Engineer > http://redhat.com > http://jboss.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
