spring中的单元测试的策略
本文主要介绍使用spring提供的对junit的扩展机制来进行单元测试，没有设计mock方面的测试。
一、Spring提供的JUnit框架扩展：
AbstractSpringContextTests：spring中使用spring上下文测试的Junit扩展类，我们一般不会使用这个类来进行单元测试，它是spring内部设计使用到的类
AbstractDependencyInjectionSpringContextTests：这是AbstractSpringContextTests的直接子类，支持依赖spring上下文的测试类，这个类不支持事务。
AbstractTransactionalSpringContextTests：这是AbstractDependencyInjectionSpringContextTests的直接子类，这个类一般应用在事务相关的测试中，一旦完成每个测试它就会正常地回滚事务，不会真正更新数据库，若要手动设置事务相关操作，你可以重载onSetUpInTransaction和onTearDownInTransaction方法，以便手工开始并提交事务，或者调用setComplete()方法。这个类也可以在没有事务的情况下，使用这个类。
AbstractTransactionalDataSourceSpringContextTests：这是AbstractTransactionalSpringContextTests的直接子类，它使用了Spring的基于JDBC的jdbcTemplate工具类，支持数据库级别的事务。
我是按照继承顺序介绍上面四个类的，具体可以参考spring的api文档，或者可以阅读spring的源代码，很简单的代码。
二、测试策略：
下面用一个真实项目的简化版本来作例子，测试的具体目录路径：
test
--system
--dao
--UserDAOImplTest.java
......
--service
--UserServiceImplTest.java
......
--AbstractSystemTest.java
--testSystemContext.xml
--manage
--dao
--CustomerDAOImplTest.java
......
--service
--CustomerServiceImplTest.java
......
--AbstractManageTest.java
--testSystemContext.xml
--testApplicationContext.xml
解释：
test是测试路径，system与manage是模块名(这本来是package的路径，为了简化，我就把前面的包名删除了)，每个模块中有一个spring的配置文件(我的spring配置文件的命名策略是test+模块名+Context)，一个模块级别测试基类(主要是载入spring配置文件，每个该模块的单元测试类都继承该类)，然后是分层路径，这里是DAO和service层，包括所有的DAO与service单元测试类，我们还有一个总的spring配置文件testApplicationContext.xml。再多的解释，也不如代码最明显，下面是部分示例代码
testApplicationContext.xml
<bean id="propertyConfigurer"
abstract="true"
/>
</property>
</bean>
<!-- transaction -->
<bean id="transactionManager"
ref="dataSource" />
</bean>
<bean id="baseTransactionProxy"
ref="transactionManager" />
<property name="transactionAttributes">
<props>
<prop key="*">
PROPAGATION_REQUIRED, -ApplicationException
</prop>
<prop key="load*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="list*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
<!-- Base DAO -->
<bean id="baseDAO" abstract="true"
ref="sessionFactory" />
</bean>
所有的spring的基本配置文件都放在这里面，我巧妙的把利用spring提供的配置技巧声明了一个抽象的parentSessionFactory，然后让每个子模块的sessionFactory都继承这个对象，这样就减少了不少重复的配置文件
testSystemContext.xml
<bean id="sessionFactory" parent="parentSessionFactory"
parent="baseDAO"
parent="baseTransactionProxy">
<property name="target">
<bean
ref="userDAO" />
</bean>
</property>
</bean>
在这个文件中，声明了一个继承parentSessionFactory的sessionFactory，只需配置mappingDirectoryLocations
AbstractSystemTest.java
public abstract class AbstractSystemTest extends
AbstractTransactionalDataSourceSpringContextTests ...{
protected String[] getConfigLocations() ...{
String[] config = new String[] ...{ "testApplicationContext.xml",
"system/testSystemContext.xml" };
return config;
}
}
覆盖基类的方法，提供寻找配置文件的功能，自己可以根据情况把基类改为AbstractTransactionalSpringContextTests
UserDAOImplTest.java
public class UserDAOImplTest extends AbstractSystemTest ...{
public UserDAO getUserDAO() ...{
return (UserDAO) applicationContext.getBean("userDAO");
}
public void testLoadObject() ...{
User user = (User) this.getUserDAO().find("01");
assertNull(user);
}
}
UserServiceImplTest.java
public class UserServiceImplTest extends AbstractSystemTest ...{
public UserService getUserService() ...{
return (UserService) applicationContext.getBean("userService");
}
public void testLoadUser() ...{
User user = (User) this.getUserService().find("01");
assertNull(user);
}
}
我的基本策略，就是让让每个开发人员写的单元测试之间不会相互干扰，其实，在spring中的关键问题时把载入context配置文件相互不干扰。上面的示例表明，采用spring提供的配置文件可以轻松达到这个目的
但是，到了项目中后期的时候，会发现service经常需要访问不属于自己模块的DAO，或者是domain对象的关联被映射在hibernate配置文件中，这时会发现这个方式很耗时，因为你需要导入别的模块的配置文件，这时可以采用一个sessionFacotry的配置，而且这时domain对象也很稳定了，不会经常出现
unmmaped class的异常。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wangjian5748/archive/2006/09/09/1199549.aspx
