package com.baobaotao.service;
…
public class TestUserService extends TestCase {
public ApplicationContext ctx = null; ①Spring容器引用
private static String[] CONFIG_FILES = { ②Spring配置文件
"baobaotao-dao.xml",
"baobaotao-service.xml" };
protected void setUp() throws Exception {③启动Spring容器
ctx = new FileSystemXmlApplicationContext(CONFIG_FILES);
}
public void testHasMatchUser() { ④测试方法一
④-1从容器中获取Bean
UserService userService = (UserService) ctx.getBean("userService");
boolean b1 = userService.hasMatchUser("admin", "123456");
boolean b2 = userService.hasMatchUser("admin", "1111");
assertTrue(b1);
assertTrue(!b2);
}
public void testAddLoginLog() {⑤测试方法二
⑤-1从容器中获取Bean
UserService userService = (UserService) ctx.getBean("userService");
User user = userService.findUserByUserName("admin");
user.setUserId(1);
user.setUserName("admin");
user.setLastIp("192.168.12.7");
user.setLastVisit(new Date());
userService.loginSuccess(user);
}
…//省略其余的测试方法 
} 

在这个测试用例中，我们使用了最原始的JUnit的TestCase进行集成测试，乍一看并没有多大的问题，但仔细分析一下，我们就可以总结出以下四点明显的不足：

1)导致多次Spring容器初始化问题：根据JUnit测试方法的调用流程（参见错误！未找到引用源。小节的描述），每执行一个测试方法都会创建一个TestUserService实例并调用setUp()方法。由于我们在setUp()方法中初始化Spring容器，这意味着TestUserService有多少个测试方法，Spring容器就会被重复初始化多少次。虽然初始化Spring容器的速度并不会太慢，但由于可能会在Sprnig容器初始化时执行加载Hibernate映射文件等耗时的操作，如果每执行一个测试方法都必须重复初始化Spring容器，则对测试性能的影响是不容忽视的；

2)需要使用硬编码方式手工获取Bean：在④-1和⑤-1处，我们通过ctx.getBean()方法从Spring容器中获取需要测试的目标Bean，并且还要进行强制类型转换的造型操作。这种乏味的操作迷漫在测试用例的代码中，让人觉得繁琐不堪；

3)数据库现场容易遭受破坏：⑤处的测试方法会对数据库记录进行插入操作，虽然是针对开发数据库进行操作，但如果数据操作的影响是持久的，可能会影响到后面的测试行为。举个例子，你在测试方法中插入一条ID为1的User记录，第一次运行不会有问题，第二次运行时，就会因为主键冲突而导致测试用例失败。所以应该既能够完成功能逻辑检查，又能够在测试完成后恢复现场，不会留下“后遗症”；

4)没有对数据操作正确性进行检查：⑤处我们向登录日志表插入了一条成功登录日志，可是我们却没有对t_login_log表中是否确实添加了一条记录进行检查。原来我们的方式是打开数据库，肉眼观察是否插入了相应的记录，但这严重违背了自动测试的原则。试想，你在测试包括成千上万个数据操作行为的程序时，如何用肉眼进行检查？

既然使用传统方式对Spring应用进行集成测试存在这么多不足，Spring责无旁贷地担当起革新之任。它通过扩展JUnit框架提供了一套专门测试Spring应用的有力工具。借助Spring集成测试工具的帮助，以上所罗列的种种问题将冰消雪融、云开雾散。