Java Reference
In-Depth Information
We call these issues the database unit testing impedance mismatch, in reference to
the object-relational impedance mismatch (which describes the difficulties of using
a relational database to persist data when an application is written using an object-
oriented language).
The database-testing mismatch can be minimized using specialized tools, one of
them being DbUnit. In this chapter, we show how DbUnit can be used to test database
code, and we not only describe its basic concepts but also present techniques that
make its usage more productive and the resulting code easier to maintain.
17.1
The database unit testing impedance mismatch
Let's take a deeper look at the three issues that compose the database unit testing
impedance mismatch.
17.1.1
Unit tests must exercise code in isolation
From a purist point of view, tests that exercise database access code can't be con-
sidered unit tests because they depend on an external entity, the almighty data-
base. What should they be called then? Integration tests? Functional tests? Non-
unit unit tests?
Well, the answer is, there is no secret formula! In other words, database tests can fit
into many categories, depending on the context.
Pragmatically speaking, though, database access code can be exercised by both
unit and integration tests:
Unit tests are used to test classes that interact directly with the database (like
DAO
s). Such tests guarantee that these classes execute the proper
SQL
state-
ments, assemble the right objects, and so on. Although these tests depend on
external entities (such as the database and/or persistence frameworks), they
exercise classes that are building blocks in a bigger application (and hence
are units).
■
Similarly, unit tests can be written to test the upper layers (like façades), without
the need to access the database. In these tests, the persistence layer can be emu-
lated by mocks or stubs.
■
Even with both layers (persistence and upper) unit tested aside, it's still neces-
sary to write integration tests that access the database, because some situations
can arise only in end-to-end scenarios (like the dreaded lazy-initialization
exception that frequently haunts
JPA
applications).
1
■
Despite the theoretical part of the issue, there's still a practical question: can't the data
present in the database get in the way of the tests?
1
If you don't have a clue as to what we're talking about, don't panic! JPA testing and its issues will be explained
in detail in the next chapter.
