My experience is from ibatis, but the same principles apply to hibernate.
when i work with ibatis to add a new method into an existing DAO, where in the xml file, I have a big mess of a complicated SQL query, and have the results mapped to a java bean, or list of java beans, and the output of this getX() method in the DAO class is fed to something else in the actual code, sometimes when I run it, the (also already existing) larger more complicated piece of code would not behave as expected. or worse the lack of expected data spit out from my new getX() method in the DAO causes a horrible train wreck of the database and I need to clean up the undesired state.
So when I create a new method in a DAO that does some query to getX() where the underlying SQL operations could be accidentally entered the wrong way, like I was missing a component in the where clause, not passing in all binding variables, or i have a misplaced ( ) around an or clause, I can run the DAO JUnit test case on its own to verify the new query i am running does in fact return the expected rows.
Now, for fresh applications where there is no existing systems to work with, and there is no need to test the incremental new method into the DAO could cause existing things to break, yes, its likely not as important then to go to the additional trouble of a DAO JUnit test for each and every method. clearly you could just debug the system as a whole and work to debug it there. In my separate "tests" source tree, there are only a pile of DAO JUnit test cases for the things that were added to the DAOs functionality after the application went to production
Error: Keyboard not attached. Press F1 to continue.