利用HSQLDB來進行Hibernate的單元測試

動機

曾經使用許多方法在數據庫和目標代碼之間傳輸數據。從手動編碼的SQL到JDO，然后再到EJB，從未找到一種特別喜歡的方法。自從采用測試驅動開發（TDD）作為指導原則以來，這種不滿情緒變得更加強烈。

單元測試的障礙應盡可能少。在關系數據庫中，障礙的范圍從外部依賴（數據庫在運行嗎？）到保持關系模型和對象模型同步的速度。由于這些原因，保持數據庫訪問代碼與核心對象模型分離且無需涉及真實數據庫而進行盡可能多的測試是很重要的。

通常這會導致我們進入下面兩種模式之一。第一種是具體化所有訪問域對象的數據以及數據與單獨類或接口之間的關系。這就是典型的能夠檢索、編輯、刪除和添加域實體的數據存儲對象。這在單元測試中是最容易模擬出來的，但趨向于把域模型對象作為不帶有任何關系行為的純數據對象。直接從父對象訪問子記錄是最理想的，而不是將父對象處理為第三方類來決定子記錄。

其他方法已經使訪問接口的域對象進入數據映射層（一種la Martin Fowler的數據映象模式）。這具有推動域模型中的對象關系的優點，在域模型中，對象關系型接口只需表達一次即可。使用域模型的類不支持持久性機制，因為它本身內在化到域模型中。這使代碼集中在設法解決的業務問題，而很少關注對象關系型映射機制。

我的當前項目涉及到處理大量的棒球統計數據，并使用這些數據進行模擬。因為數據已經在關系數據庫中，所以對于我來說，有機會開發Hibernate對象關系型映射系統。我曾對Hibernate有很深刻的印象，但我遇到的一個問題是，在使用Hibernate進行單元測試的數據映射時，設法插入一個間接層。該附加層非常脆弱，編寫起來感到非常困難。實際部署版本簡單地通過了特定于Hibernate的實現。更壞的情況是，模擬版本比真正的“產品級”版本更復雜，只因為模擬版本里沒有基本對象存儲器和帶有Hibernate的映射。

我也使用很多復雜的Hibernate查詢，想要對應用程序的重要部分進行單元測試。然而，對活動的數據庫進行測試不是好主意，因為這幾乎總是產生維護問題。另外，由于測試最好互相獨立，在測試上下文數據中使用相同的主鍵意味著必須在每次測試前創建代碼來清理數據庫，當涉及到大量關系時就成為一個實際問題。

通過使用HSQLDB和Hibernate強大的模式生成工具，能夠對應用程序映射層進行單元測試，并在對象查詢中找到不計其數的bug，這在以前手工測試時是做不到的。利用下面的技術概述，可以在開發過程中對整個應用程序進行測試，并且在測試有效區域內沒有損害。

設置HSQLDB

以前使用HSQLDB 1.7.3.0 版。為了使用數據庫的內存版本，需要激活org.hsqldb.jdbcDriver的靜態加載程序。當獲得JDBC連接時，就可以使用JDBC url例如jdbc:hspldb:mem:yourdb，這里’yourdb’就是想要使用的內存數據庫的名稱。

因為使用Hibernate (3.0 beta 4)，所以我幾乎無需接觸實際活動的JDBC對象。相反,我可以讓Hibernate完成很多繁重的任務，包括從Hibernate映射文件中自動創建數據庫模式。因為Hibernate創建自身專有的連接池，所以它會基于TestSchema類中的配置代碼自動加載HSQLDB JDBC驅動程序。下面就是該類的靜態的初始化程序。

public class TestSchema { static { Configuration config = new Configuration(). setProperty("hibernate.dialect", "org.hibernate.dialect.HSQLDialect"). setProperty("hibernate.connection.driver_class", "org.hsqldb.jdbcDriver"). setProperty("hibernate.connection.url", "jdbc:hsqldb:mem:baseball"). setProperty("hibernate.connection.username", "sa"). setProperty("hibernate.connection.password", ""). setProperty("hibernate.connection.pool_size", "1"). setProperty("hibernate.connection.autocommit", "true"). setProperty("hibernate.cache.provider_class", "org.hibernate.cache.HashtableCacheProvider"). setProperty("hibernate.hbm2ddl.auto", "create-drop"). setProperty("hibernate.show_sql", "true"). addClass(Player.class). addClass(BattingStint.class). addClass(FieldingStint.class). addClass(PitchingStint.class); HibernateUtil.setSessionFactory(config.buildSessionFactory()); }

Hibernate提供了許多不同的方式來配置該框架，包括程序方面的配置。上述代碼設置了連接池。注意，使用HSQLDB的內存數據庫需要用戶名'sa’。還樣要確保指定一個空格作為口令。為了啟動Hibernate的自動模式生成功能，需設置hibernate.hbm2ddl.auto屬性為’creat-drop’。

實際測試 我的項目是處理將大量的棒球數據，所以我添加了四個進行映射的類（Player、PintchingStint、,BattingSint和FieldStint）。最后創建Hibernate的會話工廠，并將其插入HibernateUtil類，該類只為Hibernate會話的整個應用程序提供一個訪問方法。HibernateUtil的代碼如下：

import org.hibernate.*;
import org.hibernate.cfg.Configuration;
public class HibernateUtil {
private static SessionFactory factory;
public static synchronized Session getSession() {
if (factory == null) {
factory = new Configuration().configure().buildSessionFactory();
}
return factory.openSession();
}
public static void setSessionFactory(SessionFactory factory) {
HibernateUtil.factory = factory;
}
}

因為所有代碼（經過單元測試的產品級代碼）都是從HibernateUtil獲取Hibernate會話，所以能在同一個位置對其進行配置。為了對代碼的第一位進行單元測試而訪問TestSchema類將會激活靜態初始化程序，該程序將安裝Hibernate并且將測試SessionFactory插入到HibernateUtil中。對于產品級代碼，可以使用標準hibernate.cfg.xml配置機制來初始化 SessionFactory。

那么單元測試中的外部特征是什么？下面的測試代碼片段是用來檢查邏輯的，決定運動員在棒球聯盟比賽中是哪個位置的人選：

public void testGetEligiblePositions() throws Exception {
Player player = new Player("playerId");
TestSchema.addPlayer(player);
FieldingStint stint1 = new FieldingStint("playerId", 2004, "SEA", Position.CATCHER);
stint1.setGames(20);
TestSchema.addFieldingStint(stint1);
Set

positions = player.getEligiblePositions(2004);
assertEquals(1, positions.size());
assertTrue(positions.contains(Position.CATCHER));
}

第一次創建新Player實例并通過addPlayer()方法添加到TestSchema中。必須首先完成此步驟，因為FidldStint類和Player類之間有外鍵關系。如果不首先添加該實例，在設法添加FieldingStint時將會出現外鍵約束違例。一旦測試上下文就位，就可以測試getEligiblePositions()方法來檢索校正數據。下面是在TsetSchema中addPlayer()方法的代碼。您將注意到使用Hibernate而不是bare-metal JDBC代碼：

public static void addPlayer(Player player) {
if (player.getPlayerId() == null) {
throw new IllegalArgumentException("No primary key specified");
}
Session session = HibernateUtil.getSession();
Transaction transaction = session.beginTransaction();
try {
session.save(player, player.getPlayerId());
transaction.commit();
}
finally {
session.close();
}
}

在單元測試中最重要的就是要保持測試實例是獨立的。因為該方法仍然涉及數據庫，所以需要一種方法在每個測試實例之前清理數據庫。在我的數據庫架構中有四個表，所以我在TestSchemaz上編寫了reset()方法，該方法從使用JDBC的表中刪除所有行。注意，因為HSQLDB能識別外鍵，刪除表的順序是很重要的，下面是代碼：

public static void reset() throws SchemaException {
Session session = HibernateUtil.getSession();
try {
Connection connection = session.connection();
try {
Statement statement = connection.createStatement();
try {
statement.executeUpdate("delete from Batting");
statement.executeUpdate("delete from Fielding");
statement.executeUpdate("delete from Pitching");
statement.executeUpdate("delete from Player");
connection.commit();
}
finally {
statement.close();
}
}
catch (HibernateException e) {
connection.rollback();
throw new SchemaException(e);
}
catch (SQLException e) {
connection.rollback();
throw new SchemaException(e);
}
}
catch (SQLException e) {
throw new SchemaException(e);
}
finally {
session.close();
}
}

當確定在Hibernate 3.0中進行大量刪除操作時，應該能從應用程序中刪除直接JDBC的最后一位。到此時為止，必須獲取數據庫連接并向數據庫直接提交SQL。 在確保沒有關閉連接的情況下，為了釋放資源，只關閉會話就足夠了。出于手工編寫許多JCBC代碼來進行開發的習慣，第一個版本關閉了JDBC連接。因為通過配置Hibernate創建的連接池只帶有一個鏈接，在第一個之后就完全破壞了測試。一定要注意這種情況！ 既然在測試類運行時（設想運行所有的測試實例）不能確定數據庫的狀態，應該在setUp()方法中包含數據庫清除，如下所示:

public void setUp() throws Exception {
TestSchema.reset();
}

結束語

在使用像Hibernate這種復雜的O/R映射程序時，必須能夠測試實際存在（real-live）的RDBMS，而不會發生任何針對已部署數據庫的爭論。雖然Hibernate有內置模式生成工具，讓此類測試特別簡單，但是在這里展示的例子并不排除Hibernate，并且可能與JDO或TopLink一起運行。使用上面描述的設置，您不必離開舒適的IDE環境，但仍然可以對代碼進行大量測試。