Spring中的单元测试的策略

　　覆盖基类的方法，提供寻找配置文件的功能，自己可以根据情况把基类改为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的异常。