Spring测试套件

org.springframework.test包能够提供如下一些功能：
缓存Spring上下文
完成测试类的依赖注入
为测试引入事务管理
提供有助于测试的实例变量

1、上下文管理、缓存
借助于org.springframework.test包，能够完成Spring上下文的装载、缓存工作。注意，缓存Spring上下文非 常有意义。在大型项目中，应用启动的时间很长，因为Spring IoC容器需要实例化大量的对象。这并不是由 Spring本身造成的。比如，某项目存在50-100个Hibernate映射文件，则为装载它们，需要耗费10-20秒左右。 如果每次执行测试用例时都需要重新装载它们，生产率可想而知。 因此，AbstractDependencyInjectionSpringContextTests提供了如下抽象protected方法（用于定位Spring上
下文配置文件），子类必须实现它：
protected abstract String[] getConfigLocations();
开发者需要为它提供Spring配置文件列表。注意，列表是通过classpath路径给定的。这同web.xml或其他部署 配置中使用的Spring配置内容并无（或，基本上不存在）区别。
默认时，Spring上下文一旦装载完成，以后的各个测试用例便能够重用它了。由于Spring上下文的装载过程只 会发生一次，因此测试用例的执行将会很快。 在极端情况下，某测试用例可能会对Spring配置文件（的位置）进行变更。此时，便需要重新装载Spring上下文了。通过调用AbstractDependencyInjectionSpringContextTests提供的setDirty()方法，便能够触发Spring 上下文的重新装载，从而为后续测试用例服务。

2、测试类实例的依赖注入
当AbstractDependencyInjectionSpringContextTests（及其子类）在装载Spring应用上下文时，它们可以通过设值方式注入测试类中的实例变量值。期间，开发者只需要定义相应的实例变量和设值方法。随后，
AbstractDependencyInjectionSpringContextTests便能够自动从Spring配置文件（getConfigLocations()）中定位到合适的对象，并注入到测试类中的实例变量。
注意，这里采用了autowire by type。因此，如果为同一类型的POJO定义了多个Spring受管POJO，则要小心了。此时，必须借助于applicationContext实例变量，并显式地使用getBean()方法。
如果开发者不希望设值注入方式作用到测试类，则不需声明任何setter方法。或者，可以直接继承AbstractSpringContextTests。它是org.springframework.test包的最基础类。它仅仅会完成Spring上下文的装载，而并不会去完成依赖注入。

3、事务管理
如果在（开发阶段的）测试过程中需要对RDBMS进行CRUD操作，则RDBMS的状态会发生变动。自然地，这将影响后续测试工作的进行。
请注意，在对RDBMS进行插入或修改数据时，务必使用事务保护它。
Spring提供了org.springframework.test.AbstractTransactionalDataSourceSpringContextTests超类，以应对上述问题。默认时，它会为每个测试用例创建、回滚事务。开发者编写的测试代码将会参与到现有事务中。如果在测试中调用了事务性代理对象，则测试执行过程不会受到
AbstractTransactionalDataSourceSpringContextTests的影响，而会根据事务性代理对象本身的语意执行。
另外，AbstractTransactionalSpringContextTests要求在Spring应用上下文中定义
PlatformTransactionManager受管POJO对象。注意，由于采用了autowire by type，因此这一POJO对象的名字并不重要。
通常，我们会直接继承AbstractTransactionalDataSourceSpringContextTests。此时，还需为它提供DataSource 受管POJO对象。类似地，名字并不重要。期间，它会创建jdbcTemplate实例变量，便于对RDBMS进行CRUD操作。注意，默认时，事务会回滚，因此尽管用它吧！
如果希望事务提交，则可以调用AbstractTransactionalSpringContextTests中的setComplete()方法。此时，事务不会回滚，而会提交！
另外，在测试用例未执行完之前，通过调用endTransaction()方法能够结束事务。默认时，这将触发事务的回滚。当然，如果在这之前调用了setComplete()方法，则会提交事务。这对于如下场合非常有用：测试“不再相连的”数据对象。比如，在Web或远程时，使用到Hibernate中的POJO对象，此时并不存在事务。通常，只有通过UI测试，才能发现延迟装载错误。如果在JUnit测试套件（Suite）中调用endTransaction()方法，则能够确保UI操作的正确性。

4、辅助变量
在继承org.springframework.test包中的基类时，我们可以访问到如下一些protected实例变量：applicationContext(ConfigurableApplicationContext)：注意，applicationContext来自于AbstractDependencyInjectionSpringContextTests。通过它，能够显式地完成Spring受管JavaBean（POJO）的查找工作，或者测试Spring上下文的状态。
jdbcTemplate：来自于AbstractTransactionalDataSourceSpringContextTests。使用它，以确认RDBMS的状态。比如，在集成测试之前，使用它查询RDBMS数据；在集成测试之后，使用它能够确认：测试期间应用创建的对象是否成功借助于ORM工具完成了数据的持久化。注意，Spring并没有为jdbcTemplate单独管理事务（它将参与到应用代码的现有事务中）。在集成测试期间，可能需要告知ORM工具去刷新（flush）变更，从而确保（内存和RDBMS）数据的一致性。比如，使用Hibernate Session接口的flush()方法。通常，我们都会为集成测试提供自身开发的、应用级的测试基类，其中会包含不同测试中都会使用到的实例变量。