IMO:

• If a test requires DB, it is not the unit test. It is either integration or acceptance test.
• To avoid the need of using DB in a test I should follow inversion of control principle by using dependency injection (or service locator).
• If I need to test something with DB, I should create a VM with actual database (with fake or real data, depending on the task). Vagrant is a great tool for the job.
• Mocking the DB is a bad practice. It is the same as doing it wrong (mocking DB) and then redoing it right (macking it work with real DB).
• It is OK for proof-of-concept projects, but still it is then followed by redoing (if concept is proved).
• It is perfectly fine to use HSQLDB (or whatever) by itself if it is a proper tool for the job.

IMO:

• If a test requires DB, it is not the unit test. It is either integration or acceptance test.
• To avoid the need of using DB in a test I should follow inversion of control principle by using dependency injection (or service locator).
• If I need to test something with DB, I should create a VM with actual database (with fake or real data, depending on the task). Vagrant and Docker are great tools for the job.
• Mocking the DB is a bad practice. It is the same as doing it wrong (mocking DB) and then redoing it right (making it work with real DB).
• It is OK for proof-of-concept projects, but still it is then followed by redoing (if concept is proved).
• It is perfectly fine to use HSQLDB (or whatever) by itself if it is a proper tool for the job.