I've used lots of methods to transform data between databases and object code. From hand-coded SQL to JDO to EJB. I've never found a method I liked particularly well. This distaste has become especially acute since adopting test-driven development (TDD) as a guiding philosophy.
Unit-testing should have as few barriers as possible. For relational databases those barriers range from external dependencies (is the database running?) to speed to keeping the relational schema synchronized with your object model. For these reasons it is vital to keep database access code away from the core object model and to test as much as possible without touching a real database.
This has often led me to one of two patterns. The first is externalizing all data access to domain objects and their relationships to separate classes or interfaces. These are typically data store objects that can retrieve, edit, delete and add domain entities. This is the easiest to mock-out for unit-testing, but tends to leave your domain model objects as data-only objects with little or no related behavior. Ideally access to child records would be directly from the parent object rather than handing the parent object to some third-party class to determine the children.
The other method has been to have the domain objects have access to an interface into the data-mapping layer a la Martin Fowler’s Data Mapper pattern. This has the advantage of pushing object relationships inside the domain model where the object-relational interface can be expressed once. Classes that use the domain model are unaware of the persistence mechanism because it is internalized into the domain model itself. This keeps your code focused on the business problem you are trying to solve and less about the object-relational mapping mechanism.
My current project involves crunching a number of baseball statistics and running simulations with the data. Since the data was already in a relational database it was a chance for me to explore the Hibernate object-relational mapping system. I have been very impressed with Hibernate, but I ran into the problem was trying to insert a layer of indirection while using Hibernate as my data mapper for unit-testing. The extra layer was so flimsy that it felt embarrassing to write it. The real deployed version was simply a pass-through to a Hibernate-specific implementation. Even worse, the mock versions had more complexity in them than the real "production" version simply because they didn't have some of the basic object storage and mapping that came with Hibernate.
I also had enough complex Hibernate query usage that I wanted to unit-test this significat portion of the application. However, testing against a ‘live?database is a bad idea, because it almost invariably introduces a maintenance nightmare. In addition, since tests are best when they are independent from each other, using the same obvious primary keys in test fixture data means you have to create code to clean the database before each test case, which is a real problem when lots of relationships are involved
By using HSQLDB and Hibernate's powerful schema-generation tool I was able to unit-test the mapping layer of the application and find numerous bugs in my object queries I would not have found as easily by manual testing. With the techniques outlines below I was able unit-test my entire application during development with no compromises in test coverage.
Setting up HSQLDB
I used version 1.7.3.0 of HSQLDB. To use an in-memory version of the database you need to invoke the static loader for the org.hsqldb.jdbcDriver. Then when you get a JDBC connection you use JDBC url such as jdbc:hsqldb:mem:yourdb where 'yourdb' is the name of the in-memory database you want to use.
Since I'm using Hibernate (3.0 beta 4), I hardly ever need to touch real-live JDBC objects. Instead I can let Hibernate do the heavy lifting for me--including automatically creating the database schema from my Hibernate mapping files. Since Hibernate creates its own connection pool it will automatically load the HSQLDB JDBC driver based on the configuration code lives in a class called TestSchema. Below is the static initializer for the class.
2
3 static {
4 Configuration config = new Configuration().
5 setProperty("hibernate.dialect", "org.hibernate.dialect.HSQLDialect").
6 setProperty("hibernate.connection.driver_class", "org.hsqldb.jdbcDriver").
7 setProperty("hibernate.connection.url", "jdbc:hsqldb:mem:baseball").
8 setProperty("hibernate.connection.username", "sa").
9 setProperty("hibernate.connection.password", "").
10 setProperty("hibernate.connection.pool_size", "1").
11 setProperty("hibernate.connection.autocommit", "true").
12 setProperty("hibernate.cache.provider_class", "org.hibernate.cache.HashtableCacheProvider").
13 setProperty("hibernate.hbm2ddl.auto", "create-drop").
14 setProperty("hibernate.show_sql", "true").
15 addClass(Player.class).
16 addClass(BattingStint.class).
17 addClass(FieldingStint.class).
18 addClass(PitchingStint.class);
19
20 HibernateUtil.setSessionFactory(config.buildSessionFactory());
21 }
22
Hibernate provides a number of different ways to configure the framework, including programmatic configuration. The code above sets up the connection pool. Note that the user name 'sa' is required to use HSQLDB's in-memory database. Also be sure to specify a blank as the password. To enable Hibernate's automatic schema generation set the hibernate.hbm2ddl.auto property to 'create-drop'.
Testing In Practice
My project is crunching a bunch of baseball statistics so I add the four classes that I'm mapping ( Player, PitchingStint, BattingStint and FieldingStint). Finally I create a Hibernate SessionFactory and insert it into the HibernateUtil class which simply provides a single access method for my entire application for Hibernate sessions. The code for the HibernateUtil is below:
2 import org.hibernate.cfg.Configuration;
3
4 public class HibernateUtil {
5
6 private static SessionFactory factory;
7
8 public static synchronized Session getSession() {
9 if (factory == null) {
10 factory = new Configuration().configure().buildSessionFactory();
11 }
12 return factory.openSession();
13 }
14
15 public static void setSessionFactory(SessionFactory factory) {
16 HibernateUtil.factory = factory;
17 }
18 }
19
Since all of my code (production code as well as unit-tests) get their Hibernate sessions from the HibernateUtil I can configure it in one place. For unit-tests the first bit of code to access the TestSchema class will invoke the static initializer which will setup Hibernate and inject the test SessionFactory into the HibernateUtil. For production code the SessionFactory will be initialized lazily using the standard hibernate.cfg.xml configuration mechanism.
So what does this look like in the unit-tests? Below is a snippet of a test that checks the the logic for determining what positions a player is eligible to play at for a fantasy baseball league:
2 Player player = new Player("playerId");
3 TestSchema.addPlayer(player);
4
5 FieldingStint stint1 = new FieldingStint("playerId", 2004, "SEA", Position.CATCHER);
6 stint1.setGames(20);
7 TestSchema.addFieldingStint(stint1);
8
9 Set<Position> positions = player.getEligiblePositions(2004);
10 assertEquals(1, positions.size());
11 assertTrue(positions.contains(Position.CATCHER));
12 }
13
I first create a new Player instance and add it to the TestSchema via the addPlayer() method. This step must occur first because the FieldingStint class has a foreign-key relationship to the Player class. If I didn't add this instance first I would get a foreign-key constraint violation when I try to add the FieldingStint. Once the test-fixture is in place I can test the getEligiblePositions() method to see that it retrieves the correct data. Below is the code for the addPlayer() method in the TestSchema. You will notice that Hibernate is used instead of bare-metal JDBC code:
2 if (player.getPlayerId() == null) {
3 throw new IllegalArgumentException("No primary key specified");
4 }
5
6 Session session = HibernateUtil.getSession();
7 Transaction transaction = session.beginTransaction();
8 try {
9 session.save(player, player.getPlayerId());
10 transaction.commit();
11 }
12 finally {
13 session.close();
14 }
15 }
16
One of the most important things in unit-testing is to keep your test-cases isolated. Since this method still involves a database, you need a way to clean your database prior to each test case. I have four tables in my schema so I wrote a reset() method on the TestSchema that removes all rows from the tables using JDBC. Note because HSQLDB knows about foreign keys, the order in which the tables are deleted is important. Here is the code:
2 Session session = HibernateUtil.getSession();
3 try {
4 Connection connection = session.connection();
5 try {
6 Statement statement = connection.createStatement();
7 try {
8 statement.executeUpdate("delete from Batting");
9 statement.executeUpdate("delete from Fielding");
10 statement.executeUpdate("delete from Pitching");
11 statement.executeUpdate("delete from Player");
12 connection.commit();
13 }
14 finally {
15 statement.close();
16 }
17 }
18 catch (HibernateException e) {
19 connection.rollback();
20 throw new SchemaException(e);
21 }
22 catch (SQLException e) {
23 connection.rollback();
24 throw new SchemaException(e);
25 }
26 }
27 catch (SQLException e) {
28 throw new SchemaException(e);
29 }
30 finally {
31 session.close();
32 }
33 }
34
When bulk deletes become finalized in Hibernate 3.0 we should able to remove this last bit of direct JDBC from our application. Until then we have to get a Connection and issue direct SQL to the database.
Be sure not to close your Connection, closing the Session is sufficient for resource cleanup. Out of habits developed from writing lots of hand-crafted JDBC code, the first version closed the JDBC Connection. Since I configured Hibernate to create a connection pool with only one Connection I completely torpedoed any tests after the first one.Be sure to watch out for this!
Since you can never be sure what state the database may be in when your test class is running (imagine running all of your test cases), you should include database cleanup in your setUp() methods like so:
2 TestSchema.reset();
3 }
4
Conclusion
Being able to test against a real-live RDBMS without all of the hassles of trying to run tests against your deployed database is essential, even when working with sophisticated O/R mappers like Hibernate. The example I showed here is not exclusive to Hibernate and could probably be made to work with JDO or TopLink, though Hibernate makes this kind of testing particularly easy since it has a built-in schema generation tool. With a setup like the one described above you don't ever have to leave the comfort of your IDE and still have extensive test coverage over your code.
]]>
jdbc:hsqldb:c:\db\test
jdbc:hsqldb:http://websrv
jdbc:hsqldb:.
c1=DriverManager.getConnection("jdbc:hsqldb:.","sa","");
c2=DriverManager.getConnection("jdbc:hsqldb:test","sa","");
c3=DriverManager.getConnection("jdbc:hsqldb:http://dbserver","sa","");
c4=DriverManager.getConnection("jdbc:hsqldb:hsql://dbserver","sa","");
]]>
<?
xml version
=
'
1.0
'
encoding
=
'
utf-8
'
?>
<!
DOCTYPE hibernate
-
configuration PUBLIC
"
-//Hibernate/Hibernate Configuration DTD 3.0//EN
"
"
http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd
"
>
<
hibernate
-
configuration
>
<
session
-
factory
>
<!--
Database connection settings
-->
<
property name
=
"
connection.driver_class
"
>
com.mysql.jdbc.Driver
</
property
>
<
property name
=
"
connection.url
"
>
jdbc:mysql:
//
localhost:3306/eg</property>
<
property name
=
"
connection.username
"
>
root
</
property
>
<
property name
=
"
connection.password
"
>
4864452
</
property
>
<!--
JDBC connection pool (use the built
-
in)
-->
<
property name
=
"
connection.pool_size
"
>
1
</
property
>
<!--
SQL dialect
-->
<
property name
=
"
dialect
"
>
org.hibernate.dialect.MySQLInnoDBDialect
</
property
>
<!--
Enable Hibernate
'
s automatic session context management -->
<
property name
=
"
current_session_context_class
"
>
thread
</
property
>
<!--
Disable the second
-
level cache
-->
<
property name
=
"
cache.provider_class
"
>
org.hibernate.cache.NoCacheProvider
</
property
>
<!--
Echo all executed SQL to stdout
-->
<
property name
=
"
show_sql
"
>
true
</
property
>
<!--
Drop and re
-
create the database schema on startup
<
property name
=
"
hbm2ddl.auto
"
>
create
</
property
>
-->
<
mapping resource
=
"
eg/Message.hbm.xml
"
/>
</
session
-
factory
>
</
hibernate
-
configuration
>
2、源文gQ?/p>
package
eg;
public
class
Message
{
private
Long id;
private
String text;
private
Message nextMessage;
public
Message()
{}
public
Message(String text)
{
this
.text
=
text;
}
public
void
setId(Long id)
{
this
.id
=
id; }
public
void
setText(String text)
{
this
.text
=
text; }
public
void
setNextMessage(Message nextMessage)
{
this
.nextMessage
=
nextMessage; }
public
Long getId()
{
return
(
this
.id); }
public
String getText()
{
return
(
this
.text); }
public
Message getNextMessage()
{
return
(
this
.nextMessage); }
}
3、配|文ӞMesssage.hbm.xml
<?
xml version
=
"
1.0
"
encoding
=
"
utf-8
"
?>
<!
DOCTYPE hibernate
-
mapping PUBLIC
"
-//Hibernate/Hibernate Mapping DTD 3.0//EN
"
"
http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd
"
>
<
hibernate
-
mapping
>
<
class
name
="
eg.Message
"
table
=
"
MESSAGE
"
>
<
id name
=
"
id
"
column
=
"
MESSAGE_ID
"
type
=
"
java.lang.Long
"
>
<
generator
class
=
"
native
"
/>
</
id
>
<
property name
=
"
text
"
type
=
"
java.lang.String
"
update
=
"
true
"
insert
=
"
true
"
column
=
"
MESSAGE_TEXT
"
/>
<
many
-
to
-
one name
=
"
nextMessage
"
class
=
"
jmuse.eg.Message
"
cascade
=
"
all
"
outer
-
join
=
"
auto
"
update
=
"
true
"
insert
=
"
true
"
column
=
"
NEXT_MESSAGE_ID
"
/>
</
class
>
</
hibernate
-
mapping
>
4、最后的包结构：
+
lib antlr.jar cglib.jar asm.jar asm
-
attrs.jars commons
-
collections.jar commons
-
logging.jar hibernate3.jar jta.jar dom4j.jar log4j.jar Qsrc
+
eg Message.java Message.hbm.xml TestMessage.java hibernate.cfg.ml log4j.properties
5、测试：
session.beginTransaction(); Message m
=
new
Message(
"
hello,world
"
); session.save(m); session.getTransaction().commit(); session.close();
你会发现在数据库中有一条信息了Qid=1
Hibernate的对象识别是通过对象的Id 来识别的Q?br />如：
我们刚才在数据库中保存了一个Id?的Message对象?br />如果Q?br />session.beginTraction();Message m
=
new
Message();m.setId(
new
Long(
1
));m.setText(
"
This is another greeting
"
);session.saveOrUpdate(m);sesion.getTraction.commit();
]]>
package
jmuse.eg;
/** */
/**
*@hibernate.class table="MESSAGE" *
*/
public
class
Message
{
private
Long id;
private
String text;
private
String string;
public
void
setString(String s)
{ string
=
s; }
/** */
/**
*@hibernate.property *
*/
public
String getString()
{
return
this
.string; }
private
Message nextMessage;
public
Message()
{}
public
Message(String text)
{
this
.text
=
text; }
public
void
setId(Long id)
{
this
.id
=
id; }
public
void
setText(String text)
{
this
.text
=
text; }
public
void
setNextMessage(Message nextMessage)
{
this
.nextMessage
=
nextMessage; }
/** */
/**
*@hibernate.id column="MESSAGE_ID" generator-class="native" *
*/
public
Long getId()
{
return
(
this
.id); }
/** */
/**
*@hibernate.property column="MESSAGE_TEXT" *
*/
public
String getText()
{
return
(
this
.text); }
/** */
/**
*@hibernate.many-to-one column="NEXT_MESSAGE_ID" cascade="all" *
*/
public
Message getNextMessage()
{
return
(
this
.nextMessage); }
}
q样的类׃没有实现equals()和haseCode()Q所以如果用下面的代码我们可以看到如下输出：
Message m1
=
new
Message("Hello");Message m2
=
new
Message("Hello");
if
(!(m2.equals(m1))
)log.info(
"
m1 and m2 are not idential
"
);
else
log.info(
"
m1 and m2 are identical
"
);
//////////////
/out put
//////////////
m1 and m2 are not idential
但是我们加上如下代码Q?br />
public
boolean
equals(Object o)
{
if
(
this
==
o)
return
true
;
if
(
!
(o
instanceof
Message))
return
false
;
final
Message m
=
(Message)o;
return
this
.getText().equals(m.getText()); }
public
int
hashCode()
{
//
return text==null?System.identityHashCode(this):text.hashCode();
int
hase
=
20
;
return
20
*
hase
+
getText().hashCode(); }
////////////
out put
////////////
/
m1 and m2 are identical
q就是java的对象识别。如果你修改后的Message对象加入到java.util.Set中，不管你加多少Q最后size()仍然??br /> 那么hibernate中的对象识别如何呢？见以后文章。呵c?br />
]]>