It is often argued whether tests that need a database should be called “unit tests”. Most often the answer is “No, these are database integration tests”. My opinion is – “Yes”.
The whole problem is routed in the fact that service methods depend on data access. If an application is designed properly the data access is abstracted in the DAO layer, so the code is testable.
So why is it proper to call these tests “unit tests”. Because service methods (units) are tested. These methods have a dependency on the Data Access layer, which in turn depends on a database. Now, a purely unit-testing approach would be to mock the dependency – the DAO in this case. This mock should be fairly complex in order to behave as expected. So why creating a complex mock, if you can instead use an in-memory database (HSQLDB/Derby/JavaDB), which can be realized as a mock of the runtime setup.
Here’s why this is not a database integration testing – you are not testing whether your application integrates with a real database. You test the business operations that rely on database operations. But the way these operations are performed is practically mocked (though not in the standard sense)
In regard to build speed concerns – in-memory databases are (logically) very fast. This alone can reduce the amount of time for running the tests to levels low enough.Google+