Author: 江南白衣
注重实效的TDD的确能加快，而不是拖慢开发的进度（片面的追求覆盖率的全面UnitTest不在此列）
一，可以实现真正分层开发。
二，不需要依赖和频繁重启Web
Container。
三，手工测试总不免改动数据库，如何把数据库恢复到测试前的状态是件伤脑筋的事情。Unit Test可以使用自动Rollback机制，巧妙的解决了这件事情。
Rod的<Professional J2EE with Spring>的例子即是这种风格。这种风格不依赖Spring与ApplicationContext，完全绝对的分层开发。但缺点是需要手工注入所有依赖bean，手工设置所有出场对象的方法和假定返回值，代码量非常巨大，而且这种Mock UT离实际环境很远，仍然需要再写一套集成测试的Test Case。
SS的风格是使用Spring，load all applicationContext file，自动注入所有测试对象，并利用真实对象进行测试。这样的好处是开发人员可以专注于测试检验代码的编写。
仅在需要限定分离解耦某些对象时，才重载public String[] getConfigLocations()函数限定applicationContext，使用EasyMock Mock对象(见BookManagerMockDaoControllerTest.java)
不过各位老大不是很认同这种方式，但懒字当头，使用实用就了，被bs一下也值得了。
Spring 下的Unit
Test主要关注三个方面：
1.
bean的依赖注入
2. 事务控制，Open Session in Test
及默认回滚
3.
脱离WebContainer对控制层的测试
能不依靠WebContainer来完成ApplicationContext的建立与POJO的依赖注入一向是Spring的得意之处。
String[] paths = { "classpath:applicationContext*.xml" };
ApplicationContext ctx =new ClassPathXmlApplicationContext(paths);
UserDAO dao = (UserDAO) ctx.getBean("userDAO");
如果你连这也觉得麻烦，那么只要你的testCase继承于Spring-mock.jar里的AbstractDependencyInjectionSpringContextTests，实现public
String[] getConfigLocations()函数， 并显式写一些需要注入的变量的setter函数。
注：因为是AutoWire的，变量名必须等于Spring context文件里bean的id。
又是来自Spring这个神奇国度的东西，
你可以让testCase继承于AbstractTransactionalDataSourceSpringContextTests，就可以做到Open
Session in Test
，解决Hibernate的lazy-load问题；而且接管原来的DAO里的事务控制定义，通过setDefaultRollback(boolean)方法控制最后回滚还是提交，如果默认为回滚，则测试产生数据变动不会影响数据库内数据。
如果不能继承于这个基类，可以自己简单编写，代码是这样的：
protected PlatformTransactionManager transactionManager;
protected TransactionStatus transactionStatus;
protected boolean defaultRollback = true;
public void setUp()
{
transactionManager = (PlatformTransactionManager) ctx.getBean("transactionManager");
transactionStatus = transactionManager.getTransaction(new DefaultTransactionDefinition());
}
public void tearDown()
{
if (defaultRollback)
transactionManager.rollback(this.transactionStatus);
else
transactionManager.commit(this.transactionStatus);
}
(注，hibernate太奸诈了，如果全部默认回滚，只会在session里干活，一点不写数据库，达不到完全的测试效果。)
BTW.AbstractTransactionalDataSourceSpringContextTests 还通过注入的DataSource创建了一个JDBCTemplate 对象，可以跑SQL帮忙核对Hibernate的结果，但要注意两者的事务。
controller层靠Spring提供的MockHttpServletRequest和Response来模拟真实的servlet环境，并且spring 2.0了加了一个AbstractModelAndViewTests，提供一些检测返回值的utils函数。
protected XmlWebApplicationContext ctx;
protected MockHttpServletRequest request = new MockHttpServletRequest("GET", "");
protected MockHttpServletResponse response = new MockHttpServletResponse();
protected Controller controller = null;
protected ModelAndView mv = null;
public void setUp()
{
String[] paths = {"applicationContext*.xml","myappfuse-servlet.xml"};
ctx = new XmlWebApplicationContext();
ctx.setConfigLocations(paths);
ctx.setServletContext(new MockServletContext("")); ctx.refresh();
controller = (CustomerController) ctx.getBean("customerController");
//再加上前文的事务控制的代码
}
public void testCustomerList() throws Exception
{
request.setRequestURI("/customer.do");
request.addParameter("action", "listView");
mv = controller.handleRequest(request, response);
assertModelAttributeAvailable(mv, "customers");
}
在BaseTest中，setup()函数被移到 protected void onSetUp() throws java.lang.Exception
在BaseDaoTest中，setup()函数被移到 protected void onSetUpBeforeTransaction() throws Exception
MockObject是一样彻底分层开发的好东西，而且使用上没什么难度。而且已不再存在只支持接口不支持Class的限制。
//设定BookManager MockObject
bookManagerMockControl = MockClassControl.createControl(BookManager.class);
bookManagerMock = (BookManager) bookManagerMockControl.getMock();
controller.setBookManager(bookManagerMock);
//录制getAllBook()和getCategorys方法的期望值
bookManagerMock.getAllBook();
bookManagerMockControl.setReturnValue(new ArrayList());
bookManagerMockControl.replay();
//执行操作
mv = controller.handleRequest(request, response);
//验证结果
assertModelAttributeAvailable(mv, "books");
Easy Mock VS JMock:
JMock 要求TestCase继承于MockObjectTestCase太霸道了。妨碍了我继承于Spring2.0的ModelAndViewTestCase和使用MockDao,RealDao并行的继承体系。因此采用没那么霸道的easyMock。
另外，easyMock的脚本录制虽不如jmock那么优美，但胜在简短易读。jmock那句太长了 。
还有，显示层至今没有什么好的UnitTest方法，无论是不成才的httpUnit们还是笨重的GUI test工具。Appfuse一直用的那个ThoughtWork那个Selenium和J3Unit的效果不知如何， 其中J3Unit号称支持prototype。