"Any program is only as good as it is useful."
—Linus Torvalds
Enterprise applications store, retrieve, transmit, manipulate, and analyze data. Storing, processing, and analyzing data is very critical to any business. The Business Intelligence (BI) process transforms data into meaningful information for business. BI analyzes statistical data and helps with decision making and predictions for businesses, such as risk assessment, planning and forecasting, and analyzing buying trends. Information can be stored in a file or to a database. Querying and accessing data from a relational database is easier than the file system. This chapter covers the unit testing of the database layer. The following topics are covered in depth:
- Separation of concerns
- Unit testing the persistence layer
- Writing clean data access code using Spring JDBC
- Integration testing of JDBC code
- Integration testing of Spring JDBC
This section elaborates on the separation of concerns. Enterprise application information can be represented using the following building blocks:
- What: This represents the information to store. We cannot store everything; so, categorization of the data to be stored is very important.
- Who: This represents the actors. Information is a sensitive thing and it's important to control access across users; for example, an employee should not be able to access the salary information of another employee, but a manager or member of HR staff can access salary data of the staff.
- Data store: This represents information and its accessibility.
- Process: This represents the processing of data. Any information doesn't make any sense unless some action is performed on it.
The following diagram describes the key information blocks of an enterprise application:
This section covers the Store block and unit testing the data access layer.
The following diagram represents the components of a loosely coupled application:
The view component represents the JSPs, taglibs, widgets, and so on. Writing automated JUnit tests for the view components is not easy and requires manual effort. We'll skip the view components in this chapter.
We unit tested the controller logic component in Chapter 7, Unit Testing the Web Tier.
Controller logic component accesses the business logic component. The business logic component performs the business logic and delegates data access to the persistence logic component. We'll cover the unit testing of business logic in the forthcoming chapters. Mock objects are used to mimic the persistence or data access layer.
The persistence logic layer or database client layer is responsible for managing the database connection, retrieving data from a database, and storing data back in the database. Unit testing the data access layer is very important; if anything goes wrong in this layer, the application will fail. We can unit test the data access logic in isolation from the database, and perform the integration test to verify the application and database integrity.
You can have 100 percent test coverage of your database access code. However, if this code is misused by the controllers and/or the view layer, the whole application is useless. You need integration tests to verify the wiring, which will be covered later.
Databases represent a data store or a relational database.
Separating the data access layer from the business logic layer helps us to make changes to the database without affecting the business logic layer, and it allows us to unit test the business logic layer in isolation from the database. Suppose you are using the MySQL database and you want to migrate to SQL server. Then, in that case, you don't have to touch the business logic layer.