Overview of persisting a domain model - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 138

provide an API to generate a SQL script that adds the missing tables and columns
to the database schema. It is extremely easy to write a test that generates the script
and fails if it contains SQL commands to add tables or columns.

Using an in-memory database
A great way to speed up database-level tests is to use an in-memory SQL database
such as HSQLDB [ HSQLDB ]. An in-memory database runs in the application's JVM
and is a lot faster than a regular database because there is no network traffic or
disk access. Because the ORM framework insulates application code from many
aspects of the database, some aspects of using an in-memory database are very
straightforward. To configure the ORM framework to use the in-memory database,
you typically have to specify the appropriate JDBC driver and other settings. Once
you have done this, the ORM framework will automatically generate the correct
SQL statements.
One challenge when using an in-memory database is ensuring that its schema is
identical to the production database's schema. This isn't a problem if the ORM
framework generates the database schema. However, if the production database
schema is maintained separately, then its definition might not be compatible with
the in-memory database. It could, for example, use vendor-specific data types and
other features. In order to use an in-memory database, you will need to use a dif-
ferent schema definition or generate its schema from the ORM . In either case,
there is no guarantee that the in-memory database has the same schema as the pro-
duction database. As a result, an in-memory database is only useful for certain kinds
of tests. You could, for example, use an in-memory database to test the queries.
Another issue with using an in-memory database is that although it is faster
than a regular database, the tests can still be much slower than simple object tests.
This is because calling the ORM framework and accessing the database simply
involves a lot of overhead. In addition, initializing the database to the correct state
at the start of a test and verifying its state at the end can make the tests more com-
plicated. Consequently, in order to minimize test execution time and complexity
it is important to test as much as possible without the database.

4.5.3 Testing without the database

Testing against the database is certainly important, but a lot of testing can be done
without the database. We can verify that the O/R mapping correctly maps classes
and fields to tables and columns without even opening a database connection. We
can also test the repositories using mock objects. Let's take a closer look.