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

Many bugs are caused by the domain model, ORM documents, and the database
schema getting out of sync. For example, it is easy to change the domain model by
adding a new field or renaming an existing one and then forgetting to add or
update the O/R mapping for that field, which specifies how it is stored in the data-
base. Some ORM frameworks will generate an error message if the O/R mapping for
a field is undefined, but others (including Hibernate) will silently allow a field to be
nonpersistent, which can cause subtle and hard-to-find bugs. It is also quite easy to
forget to update the database schema when defining the mapping for a field.
Some bugs are easily caught, such as those detected by the ORM framework at
startup. For instance, Hibernate complains about missing fields, properties, or con-
structors when the application opens a SessionFactory . Other kinds of bugs require
a particular code path to be executed. An incorrect mapping for a collection field
can remain undetected, for example, until the application tries to access the col-
lection. Similarly, bugs in queries are often not detected until they are executed. In
order to catch these kinds of bugs, we must thoroughly test the application.
One way to test a persistence layer is to write tests that run against the data-
base. For example, we can write tests that create and update persistent objects and
call repository methods. Yet one problem with this kind of testing is that the tests
take a while to execute even when using an in-memory database such as HSQLDB .
Another problem is that they can fail to detect some bugs, such as a missing map-
ping for a field. And writing them can be a lot of work.
A more effective and faster approach is to use several kinds of tests that test
each part of the persistence layer separately. Some kinds of tests run against the
database and others run without the database. The tests that run against the data-
base are:

Test that create, update, and delete persistent objects

■

Tests for the queries that are used for the repositories

■

Tests that verify that the database schema matches the object/relational
mapping

■

There are also tests that don't use the database:

Mock object tests for the repositories

■

Tests that verify the O/R mapping by testing the XML mapping documents

■

Next we'll look at these different kinds of tests, beginning with those that run
against the database.