Re: mock DB, was: Spring / IoC, unit-testing
Phillip Rhodes <[email protected]>
| Newsgroups | gmane.org.user-groups.trijug.juglist |
|---|---|
| Message-ID | <[email protected]> |
On 12/28/05, Thomas L Roche <tlroche-r/[email protected] > wrote: > > working out how to unit-test DAOs which encapsulate Hibernate > > operations is still kinda tricky for the same reason that all DB > > related unit-testing is. Mock Object still apply I suppose, but it > > seems like a lot of hassleto write mocks to stand in for the actual > > database. > So why do it? Good question. I wasn't really suggesting that approach, I was just "thinking out loud." Forget the mocks and just use a test DB. That's the way I lean, mainly because of how complex it would be to simulate the low-level database stuff using mock objects. > Why not just have a test DB? Unless you're really > paranoid/careless you can have a test DB on the same server as > production, so setup is not much work (though keeping schema in sync > might be). The arguments I've heard in opposition to doing the db testing against a real test db generally involve the time taken to run the tests. I can see how that might become an issue in some situations, but it's not currently an issue for me. The other potential advantage I could see, would concern making tests idempotent. As it stands now, if I want to test a query / finder method, I need to "know" something about what I expect to find in the database. Assuming I want a result other than an empty set, I need to put something in the db before running the query test. The "easy" way (if we're talking about using a real db) would be to use an insert method on the same DAO that's under test. But that isn't considered good test form, since the test is now really testing two methods. And of course the same thing applies in inverse... to prove that my insert method really worked, I have to rely on a query method. The other option is to manage the state of the db "out of band," but that is even more extra work to do. If you had to do it by all by hand, using direct JDBC calls, you'd basically be duplicating work that you eliminated by using something like Hibernate in the first place. And of course, as soon as you do that, you have to question the sanity of all that plumbing code used in the test. Fortunately there is dbUnit <http://dbunit.sourceforge.net/> which seems to be a solution to that issue. TTYL, Phil _______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org