One line of thought involves creating a test database to use with your JUnit tests. In a professional environment this may mean that you will have the following databases to maintain:
Production database
Local development
Shared development
Deployment/Integration
Some people believe that this is too many databases to create/maintain, and it is not worth the effort. Fortunately scripts can be used to alleviate much of this pain, so this point is debatable.
A second concern is that unit tests for database code take much longer to run. This appears to be true, but there are also great ways around this.
Pro's:
You can build real objects from a real database and test them against expected results.
You will catch a lot of routine JDBC/RDBMS coding errors.
While testing against a real database can be slow, with JUnit you don't have to run your database tests all the time. You can run them just once or twice a day, as needed.
Con's:
You may have 3-4 databases to maintain.
It may be difficult to maintain test/development databases.
If this is true then there may be other problems. :)
Scripts can be used to automate database maintenance activities.
This is easily worked around in JUnit.
Tests running against a real database can be slow.