This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I'm using JUnit attaching to an in-memory instance of Derby.
The production system uses DB2, and there are a few cases where the difference between DB2 and Derby cannot be unit-tested, but overall it works well.
JUnit can also roll back changes after a test so even if you use a permanent database for testing, the tests can be made to run from a consistent baseline instead of continuously polluting the test database.
An IDE is no substitute for an Intelligent Developer.
Well, the database unit testing that I do is testing individual DAOs at the lower level and individual business services at the higher level, so I'd consider them as units.
The fact that they need to invoke (or mock) external services is sort of beside the point, since I'm not testing the services themselves, which are tested as units at lower levels.
I'm VERY keen on DAO unit-testing, though, since SQL is an interpreted language and thus isn't validated at compile-time, but I don't want to set up a complex framework for testing the database layers, since not only is it more work, it has a higher risk of having unrelated problems obscure or interfering with what I'm actually attempting to test. So I use the database to serve as the validator.