You want to test business logic that normally depends on a database, but mocking out the low-level SQL is far too complex.
Organize your server-side code using business objects and database access objects (DAOs). Place all business logic in your business objects, and all database access in your DAOs. Use a factory to create mock implementations of your DAOs when testing your business objects.
We showed how to write mock objects to simulate low-level SQL code earlier in this chapter. It is a useful technique for testing the data access tier of your application, but tends to be far too complex for business logic tests. For business objects, you should strive to create mock implementations of the entire data access tier, rather than mock implementations of the JDBC interfaces.
Figure 6-1 illustrates a common design pattern for
server-side Java code. In this diagram, either an EJB or a servlet
dispatches method calls to
CustomerBO, a business
object that contains server-side business logic. The business object
is what we would like to test.
Figure 6-1. Business object and DAO pattern
The first box in Figure 6-1 shows either an EJB or a servlet. This pattern works well with either approach, although the EJB approach allows you to easily invoke many different business objects under the umbrella of a single transaction. Regarding ...