8.3. 集成测试

• 正确配置Spring IoC 容器上下文。

• 使用JDBC或ORM工具的数据访问。可能包括如SQL脚本，Hibernate query，JPA 实体映射等的正确性验证。

• 跨越各个测试案例执行期的Spring IoC容器缓存。

• 测试fixture实例的依赖注入 (这很爽)。

• 适合集成测试的事务管理(这更加爽)。

• Spring特有的支持类在编写集成测试时真的很有用。

Spring集成测试支持框架提供了ApplicationContext的持久化载入和这些上下文的缓存机制。 对已载入上下文的缓存是很重要的，因为如果你是在一个大型的项目中，启动时间会成为一个问题——不是因为Spring本身的开销， 而是因为靠Spring容器来初始化的对象需要很长时间。比如一个有50-100 Hibernate映射文件的项目可能需要10-20秒来载入映射文件， 而每次单一测试fixture的每个单一测试前都要这样的时间开销，减慢了整体的测试进度进而降低效率。

测试类通常会提供一个数组来包含XML配置元数据的资源路径——通常是classpath——来配置应用。这通常和web.xml或其它部署描述中指定的配置路径是相同或相近的。

默认情况下,一旦载入，ApplicationContext将在每次测试中重用。 这样启动的开销将只需要一次（每个测试fixture），接下来的测试执行就会快得多。 在一些少见的会“污染”应用上下文的案例中需要重新载入—— 例如，改变一个bean定义或应用对象的状态—— Spring的测试支持提供了在执行下一个测试前让测试fixture重新载入配置并重建应用上下文的机制。

上下文管理和缓存使用：

当Spring集成测试支持框架载入你的应用上下文时，它们能通过依赖注入选择性配置测试类实例。 这提供了一个方便的机制来使用预先在应用上下文中配置的bean来搭建测试fixture。 很大的好处就是你可以在各种测试场景中重用应用上下文(例如配置Spring管理的对象图， 事务代理DataSource等)，从而能避免为单个的测试案例重复进行测试fixture搭建。

作为例子，考虑一个场景：我们有一个HibernateTitleDao类来实现数据访问逻辑，假设是Title域对象。我们希望编写测试所有以下方面的集成测试：

测试fixtures依赖注入使用：

访问实际数据库的测试的一个通常问题是对持久化状态的影响。 即使你使用开发数据库，状态的改变也可能影响后面的测试。而且很多操作 —— 如插入或修改持久化数据 —— 不能在事务外完成（或验证）。

Spring集成测试支持框架满足了这些需求。默认情况下，对每次测试它们会创建并回滚事务。 你编写代码可以假定事务已经存在。如果你在测试中调用事务代理对象，它们将根据配置的事务语义正常响应。 另外，如果测试方法在事务内删除了选定表的数据，这个事务会默认回滚，数据库也将回到测试执行前的状态。 事务支持通过在测试应用上下文中定义的PlatformTransactionManager bean提供。

如果你希望事务被提交 —— 不常见,但可能你希望特定的测试插入或修改数据库 —— Spring集成测试支持框架 可以通过调用一个继承下来的钩子(Hook)方法或声明特定注解来让事务提交而不是回滚。

事务管理使用:

Spring集成测试支持框架提供了几个abstract支持类来简化编写集成测试。 这些测试基类提供了定义良好的测试框架钩子，比如方便的变量实例和方法，来访问以下对象：

你经常会提供一个应用范围的超类来为多个集成测试提供有用的实例变量。

支持类：

• @IfProfileValue

  提示一下，注解测试只针对特定的测试环境。 如果配置的ProfileValueSource类返回对应的提供者的名称值， 这个测试就可以启动。这个注解可以应用到一个类或者单独的方法。

  @IfProfileValue(name="java.vendor", value="Sun Microsystems Inc.")
  public void testProcessWhichRunsOnlyOnSunJvm() {
      // some logic that should run only on Java VMs from Sun Microsystems
  }

  同时@IfProfileValue可配置一个值列表 (使用OR 语义) 来在JUnit环境中获得TestNG的测试组支持。 看下面的例子：

  @IfProfileValue(name="test-groups", values={"unit-tests", "integration-tests"})
  public void testProcessWhichRunsForUnitOrIntegrationTestGroups() {
      // some logic that should run only for unit and integration test groups
  }

• @ProfileValueSourceConfiguration

  类级别注解用来指定当通过@IfProfileValue注解获取已配置的profile值时使用何种ProfileValueSource。 如果@ProfileValueSourceConfiguration没有在测试中声明，将默认使用SystemProfileValueSource。

  @ProfileValueSourceConfiguration(CustomProfileValueSource.class)
  public class CustomProfileValueSourceTests {
      // class body...
  }

• @DirtiesContext

  在测试方法上出现这个注解时，表明底层Spring容器在该方法的执行中被“污染”，从而必须在方法执行结束后重新创建（无论该测试是否通过）。

  @DirtiesContext
  public void testProcessWhichDirtiesAppCtx() {
      // some logic that results in the Spring container being dirtied
  }

• @ExpectedException

  表明被注解方法预期在执行中抛出一个异常。预期异常的类型在注解中给定。如果该异常的实例在测试方法执行中被抛出， 则测试通过。同样的如果该异常实例没有在测试方法执行时抛出，则测试失败。

  @ExpectedException(SomeBusinessException.class)
  public void testProcessRainyDayScenario() {
      // some logic that should result in an Exception being thrown
  }

• @Timed

  表明被注解的测试方法必须在规定的时间区间内执行完成（以毫秒记）。如果测试执行时间超过了规定的时间区间，测试就失败了。

  注意该时间区间包括测试方法本身的执行，任何重复测试（参见 @Repeat），还有任何测试fixture的set up或tear down时间。

  @Timed(millis=1000)
  public void testProcessWithOneSecondTimeout() {
      // some logic that should not take longer than 1 second to execute
  }

• @Repeat

  表明被注解的测试方法必须重复执行。执行的次数在注解中声明。

  注意重复执行范围包括包括测试方法本身的执行，以及任何测试fixture的set up或tear down。

  @Repeat(10)
  public void testProcessRepeatedly() {
      // ...
  }

• @Rollback

  表明被注解方法的事务在完成后是否需要被回滚。 如果true，事务将被回滚，否则事务将被提交。 使用@Rollback接口来在类级别覆写配置的默认回滚标志。

  @Rollback(false)
  public void testProcessWithoutRollback() {
      // ...
  }

• @NotTransactional

  出现该注解表明测试方法必须不在事务中执行。

  @NotTransactional 
  public void testProcessWithoutTransaction() {
      // ...
  }

• JUnit 3.8遗留支持： 所有上面列举的注解都被支持，但必须与AbstractAnnotationAwareTransactionalTests类联合使用，以保证这些注解能起作用。

• TestContext框架： 支持上面列举的所有注解，而且提供了额外的TestContext特定注解 (例如@ContextConfiguration、@BeforeTransaction等等)。 注意，但是一些注解只有与JUnit联合使用时(例如，基于SpringJUnit4ClassRunner 或JUnit 3.8以及JUnit 4.4的测试类)。 详细内容参见TestContext框架章节。

AbstractSingleSpringContextTests为基于JUnit 3.8的测试案例提供了上下文管理和缓存支持。 它暴露了一个protected方法来给子类覆写以提供上下文定义文件的路径：

protected String[] getConfigLocations()

这个方法的实现必须提供包含XML配置元数据的资源路径 —— 通常是类路径 —— 的一个数组。 这和在web.xml或其它部署配置中的资源路径是相同的或基本相同的。 作为可选方案，你也可以覆写下面的方法。详细内容参见相关JavaDoc。

protected String[] getConfigPaths()

protected String getConfigPath()

默认情况下，一旦配置文件被载入就会在每个测试案例中重用。 这样构建的开销只会产生一次（每个测试fixture），然后后面的测试执行会快速的多。 在较少的情况下测试可能“污染”应用上下文，需要重新载入 —— 例如， 改变一个bean定义或应用对象状态 —— 你可以调用AbstractSingleSpringContextTests类中的 setDirty()方法来让测试fixture在执行下一个测试案例时重新载 AbstractAnnotationAwareTransactionalTests类， 你可以使用@DirtiesContext来对测试方法进行注解以达到同样的效果。

当AbstractDependencyInjectionSpringContextTests类(及其子类)载入你的应用上下文时， 它们可以通过Setter注入选择性配置你的测试类实例。你需要做的仅仅是定义实例变量和相应的setter方法。 AbstractDependencyInjectionSpringContextTests将在getConfigLocations()方法定义的配置文件集中自动查找相应对象。

假定这样一个场景，我们有一个HibernateTitleDao类(在通常目标章节详述)。 让我们看基于JUnit 3.8 的测试类实现本身(我们很快将看看配置本身)。

public final class HibernateTitleDaoTests extends AbstractDependencyInjectionSpringContextTests  {

    // this instance will be (automatically) dependency injected    
    private HibernateTitleDao titleDao;

    // a setter method to enable DI of the 'titleDao' instance variable
    public void setTitleDao(HibernateTitleDao titleDao) {
        this.titleDao = titleDao;
    }

    public void testLoadTitle() throws Exception {
        Title title = this.titleDao.loadTitle(new Long(10));
        assertNotNull(title);
    }

    // specifies the Spring configuration to load for this test fixture
    protected String[] getConfigLocations() {
        return new String[] { "classpath:com/foo/daos.xml" };
    }

}

这个文件被getConfigLocations()方法指定(比如，"classpath:com/foo/daos.xml") 像这样：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <!-- this bean will be injected into the HibernateTitleDaoTests class -->
    <bean id="titleDao" class="com.foo.dao.hibernate.HibernateTitleDao">
        <property name="sessionFactory" ref="sessionFactory"/>
    </bean>
    
    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
        <!-- dependencies elided for clarity -->
    </bean>

</beans>

AbstractDependencyInjectionSpringContextTests类使用按类型自动装配。 因此如果你有多个bean定义是相同的类型，就不能在这些bean中使用这种方法。 这种情况下，你可以使用继承的applicationContext实例变量并实现显式的查找（比如）， 调用applicationContext.getBean("titleDao")方法。

如果你不希望在测试案例中使用依赖注入，只要不声明任何public setter方法就可以简单实现。 作为替代的，你可以扩展AbstractSpringContextTests - 在org.springframework.test 包中的JUnit 3.8集成测试支持类层次的根 - 它仅仅包含了一些载入Spring上下文的简单方法，而且不在测试fixture中使用依赖注入。

public final class HibernateTitleDaoTests extends AbstractDependencyInjectionSpringContextTests  {

    public HibernateTitleDaoTests() {
        // switch on field level injection
        setPopulateProtectedVariables(true);
    }

    // this instance will be (automatically) dependency injected
    protected HibernateTitleDao titleDao;

    public void testLoadTitle() throws Exception {
        Title title = this.titleDao.loadTitle(new Long(10));
        assertNotNull(title);
    }

    // specifies the Spring configuration to load for this test fixture
    protected String[] getConfigLocations() {
        return new String[] { "classpath:com/foo/daos.xml" };
    }

}

AbstractTransactionalSpringContextTests类 依赖于应用上下文中定义的PlatformTransactionManager bean。 名字是无关紧要的，因为使用了按类型自动装配.

通常你会扩展其子类AbstractTransactionalDataSourceSpringContextTests。 这个类也需要在应用上下文中有一个DataSource bean定义(同样可以是任意名称)。 它创建一个JdbcTemplate实例变量，可以用来方便的查询和删除选定表的内容（ 请记住默认情况下事务将被回滚，因而这样做是安全的）。

如果你希望编程式提交事务 —— 不常见但对于特殊的插入数据库的测试很有用 —— 你可以调用继承自AbstractTransactionalSpringContextTests类的setComplete() 方法。 这将使事务提交而不是回滚。作为可替代的，如果你在Java 5或更高环境中开发扩展AbstractAnnotationAwareTransactionalTests类， 你可以使用@Rollback(false)来注解测试方法，以通过配置获得相同的效果。

通过调用endTransaction()方法，这里可以在测试案例完成时中止一个事务。 默认将回滚事务，除非前面调用了setComplete()方法。 这个特性当你希望测试‘断连接’的 数据对象行为是很有用，比如事务外的web或远程使用的Hibernate映射实体。 通常懒加载错误只有通过UI测试发现。如果你调用endTransaction()方法 可以保证JUnit测试时UI操作的正确性。

当你扩展 AbstractTransactionalDataSourceSpringContextTests类时，你将需要访问下面protected 实例变量:

框架的核心包括TestContext和TestContextManager类以及TestExecutionListener接口。 每次测试都会创建TestContextManager。TestContextManager管理了一个TestContext， 它负责持有当前测试的上下文。TestContextManager还负责在测试执行过程中更新TestContext的状态并代理到TestExecutionListener， 它用来监测测试实际的执行（如提供依赖注入、管理事务等等）。请查看JavaDoc及Spring测试套件以获得进一步的信息和各种配置示例。

以下三个章节讲述了如何通过注解配置TestContext框架并提供了使用该框架编写真实的单元和集成测试的示例。

每个TestContext都会为其所负责的测试实例提供上下文和缓存管理。 测试实例不会自动访问配置好的ApplicationContext；然而，如果一个测试类实现了ApplicationContextAware接口， 那么测试实例就会拥有一个对ApplicationContext的引用（假如默认已经配置好了DependencyInjectionTestExecutionListener）。 AbstractJUnit38SpringContextTests、 AbstractJUnit4SpringContextTests及AbstractTestNGSpringContextTests已经实现了ApplicationContextAware， 因此自带了上述功能。

与JUnit 3.8遗留支持不同，使用TestContext框架的测试类无需重写任何protected成员方法来配置应用上下文。 只需在类层次上声明@ContextConfiguration注解就可以完成配置。 如果你的测试类没有显式声明任何应用上下文资源的位置，那么配置好的ContextLoader就会决定如何以及是否从默认的集合位置上加载一个上下文。 例如，GenericXmlContextLoader - 默认的ContextLoader - 会基于测试类的名字产生一个默认的位置。 如果类名叫做com.example.MyTest，那么GenericXmlContextLoader就会从"classpath:/com/example/MyTest-context.xml"加载应用上下文。

package com.example;

@RunWith(SpringJUnit4ClassRunner.class)
// ApplicationContext will be loaded from "classpath:/com/example/MyTest-context.xml"
@ContextConfiguration
public class MyTest {
    // class body...
}

如果默认位置不适合你的需求，你可以使用一个包含了XML配置元数据的资源位置的数组来配置@ContextConfiguration的locations属性 （假如已经配置好了一个可以使用XML的ContextLoader）- 一般在classpath上，该属性被用来配置应用程序。 这就和在web.xml或者其他部署配置中指定配置列表时，方法完全一样，或者几乎一样。 作为另外一种选择，你可以实现并配置自己的ContextLoader

@RunWith(SpringJUnit4ClassRunner.class)
// ApplicationContext will be loaded from "/applicationContext.xml" and "/applicationContext-test.xml"
// in the root of the classpath
@ContextConfiguration(locations={"/applicationContext.xml", "/applicationContext-test.xml"})
public class MyTest {
    // class body...
}

@ContextConfiguration还提供了一个boolean类型的inheritLocations属性以表明是否继承父类的locations。 其默认值是true，表明一个被注解的类会继承被注解的父类中定义的资源位置。 特别地，一个被注解的类的资源位置会附加到其被注解的父类中的资源位置列表上。这样子类就可以继承资源位置列表。 在下面的例子中，将按顺序从"/base-context.xml"和"/extended-context.xml"中加载针对ExtendedTest的ApplicationContext。 所以定义在"/extended-context.xml"中的Beans会覆盖掉定义在"/base-context.xml"中的Beans。

@RunWith(SpringJUnit4ClassRunner.class)
// ApplicationContext will be loaded from "/base-context.xml" in the root of the classpath
@ContextConfiguration(locations={"/base-context.xml"})
public class BaseTest {
    // class body...
}

// ApplicationContext will be loaded from "/base-context.xml" and "/extended-context.xml"
// in the root of the classpath
@ContextConfiguration(locations={"/extended-context.xml"})
public class ExtendedTest extends BaseTest {
    // class body...
}

如果将inheritLocations设为false，那么就会屏蔽掉父类的资源位置，然后可以替换父类中定义的任何资源位置。

默认情况下, 配置好的ApplicationContext一旦被加载就会重用到每个测试上。这样设置的成本仅产生一次（每个测试fixture）， 随后测试的执行就会很快了。在某些不太可能发生的情况下，一个测试可能会破坏应用上下文， 这时它需要重新加载 - 例如，通过改变应用对象的bean定义或者状态 - 你可以使用@DirtiesContext （假设默认已经配置了DirtiesContextTestExecutionListener）来注解测试方法使得测试fixture重新加载配置文件并在测试下次执行前重新构建应用上下文。

当你配置DependencyInjectionTestExecutionListener时 - 它会被默认配置 - 通过@TestExecutionListeners注解， 你的测试实例依赖的bean会被注入，而这些bean是通过@ContextConfiguration使用Setter注入、Field注入或者两者都有来注入的， 到底使用哪种方式取决于你选择的注解以及你将它们放到setter方法中还是属性中。为了与Spring 2.5的注解保持一致， 你可以选择Spring的@Autowired注解或者JSR 250中的@Resource注解。其语义对于Spring框架来说都是一致的。 例如， 如果你喜欢 按类型自动织入， 那么请使用@Autowired来注解你的settter方法或者属性。另一方面，如果你喜欢按名字注入， 那么请使用@Resource来注解你的settter方法或者属性。

既然@Autowired执行按类型自动编织， 那么如果你有相同类型的多个bean定义的话，对那些特定的bean就不能使用该方式。在这种情况下， 你可以使用@Resource按名字注入。另外，如果你的测试类实现了ApplicationContextAware， 就可以直接访问ApplicationContext并调用applicationContext.getBean("titleDao")执行一个显式的查找。

如果你不想让你的测试实例使用依赖注入，只要不将@Autowired或者@Resource注解到任何属性或者setter方法上就行了。 另一种方式，你可以使用@TestExecutionListeners并忽略掉监听器列表中的DependencyInjectionTestExecutionListener.class就可以完全禁用依赖注入。

考虑如下场景：我们有一个类，名字叫HibernateTitleDao（通用目标章节已经进行了介绍）。 首先，让我们看看基于JUnit 4.4的测试类的实现，它使用@Autowired进行属性注入（在所有示例代码之后我们会查看应用上下文的配置）。 注意：下面代码的依赖注入行为并不是特定于JUnit 4.4的。同样的依赖注入技术可以使用在任何测试框架中。

@RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
@ContextConfiguration(locations={"daos.xml"})
public final class HibernateTitleDaoTests {

    // this instance will be dependency injected by type
    @Autowired    
    private HibernateTitleDao titleDao;

    public void testLoadTitle() throws Exception {
        Title title = this.titleDao.loadTitle(new Long(10));
        assertNotNull(title);
    }
}

此外，我们可以使用@Autowired进行setter注入。

@RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
@ContextConfiguration(locations={"daos.xml"})
public final class HibernateTitleDaoTests {

    // this instance will be dependency injected by type
    private HibernateTitleDao titleDao;

    @Autowired
    public void setTitleDao(HibernateTitleDao titleDao) {
        this.titleDao = titleDao;
    }

    public void testLoadTitle() throws Exception {
        Title title = this.titleDao.loadTitle(new Long(10));
        assertNotNull(title);
    }
}

现在让我们看看使用@Resource进行属性注入的一个示例。

@RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
@ContextConfiguration(locations={"daos.xml"})
public final class HibernateTitleDaoTests {

    // this instance will be dependency injected by name
    @Resource
    private HibernateTitleDao titleDao;

    public void testLoadTitle() throws Exception {
        Title title = this.titleDao.loadTitle(new Long(10));
        assertNotNull(title);
    }
}

最后，这是使用@Resource进行setter注入的一个示例。

@RunWith(SpringJUnit4ClassRunner.class)
// specifies the Spring configuration to load for this test fixture
@ContextConfiguration(locations={"daos.xml"})
public final class HibernateTitleDaoTests {

    // this instance will be dependency injected by name
    private HibernateTitleDao titleDao;
    
    @Resource
    public void setTitleDao(HibernateTitleDao titleDao) {
        this.titleDao = titleDao;
    }

    public void testLoadTitle() throws Exception {
        Title title = this.titleDao.loadTitle(new Long(10));
        assertNotNull(title);
    }
}

上面的代码使用了相同的XML上下文文件，@ContextConfiguration注解使用了这些信息(如 "daos.xml")，它是这样的：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans 
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <!-- this bean will be injected into the HibernateTitleDaoTests class -->
    <bean id="titleDao" class="com.foo.dao.hibernate.HibernateTitleDao">
        <property name="sessionFactory" ref="sessionFactory"/>
    </bean>
    
    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
        <!-- dependencies elided for clarity -->
    </bean>

</beans>

在TestContext框架中，事务是由TransactionalTestExecutionListener进行管理的， 默认情况下这是通过@TestExecutionListeners注解进行配置的， 即使你没有在测试类中显式声明 @TestExecutionListeners注解。 为了支持事务，你必须通过@ContextConfiguration在应用上下文中加载一个PlatformTransactionManager bean。 此外，你必须在类或方法层次上声明一个@Transactional。

请参考TestContext框架的注解支持中的@TransactionConfiguration以了解类层次的事务配置（例如为事务管理器设置bean名称以及默认的回滚标志）。

为每个测试方法配置事务时有几种选项。如果对于整个类来说事务不可用，那么可以使用@Transactional来显式注解方法。 与此类似，如果对于整个类来说事务可用，那么可以使用@NotTransactional来注解方法表明不为该方法增加事务。 你可以使用@Rollback注解覆盖类级别的默认的回滚设置进而针对一个特定的测试方法控制其事务的提交。

请注意，AbstractTransactionalJUnit38SpringContextTests、 AbstractTransactionalJUnit4SpringContextTests 及 AbstractTransactionalTestNGSpringContextTests已经在类级别预先配置好了事务支持。

偶尔你需要在一个事务性测试方法前、后执行某些代码，而这些代码是处在事务上下文之外的，例如， 在测试执行前去验证初始的数据库状态或者在测试执行后验证期待的事务提交行为（举例来说，该测试被配置为不进行回滚的）。 支持@BeforeTransaction和@AfterTransaction注解的TransactionalTestExecutionListener正好适用于这种情况。 使用这些注解之一来注解测试类中任何的public void方法， 同时TransactionalTestExecutionListener会保证你的事务方法之前的代码或者事务方法之后的代码会在正确的时间执行。

下面的基于JUnit 4的示例展示了一个假想的集成测试场景，重点阐述了事务相关的注解。请查看参考手册的TestContext框架注解支持章节以了解进一步的信息和配置示例。

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
@TransactionConfiguration(transactionManager="txMgr", defaultRollback=false)
@Transactional
public class FictitiousTransactionalTest {

	@BeforeTransaction
	public void verifyInitialDatabaseState() {
		// logic to verify the initial state before a transaction is started
	}

	@Before
	public void setUpTestDataWithinTransaction() {
		// set up test data within the transaction
	}

	@Test
	// overrides the class-level defaultRollback setting
	@Rollback(true)
	public void modifyDatabaseWithinTransaction() {
		// logic which uses the test data and modifies database state
	}

	@After
	public void tearDownWithinTransaction() {
		// execute "tear down" logic within the transaction
	}

	@AfterTransaction
	public void verifyFinalDatabaseState() {
		// logic to verify the final state after transaction has rolled back
	}

	@Test
	@NotTransactional
	public void performNonDatabaseRelatedAction() {
		// logic which does not modify database state
	}
}

Spring TestContext Framework支持通用注解章节提到的所有注解。 然而下面的这些注解只有配合JUnit才能使用（比如搭配SpringJUnit4ClassRunner或者 JUnit 3.8及JUnit 4.4支持类）。

Spring TestContext Framework还支持下面这些非特定于测试的注解，并且保持其语义不变。

下面的列表包含了特定于Spring TestContext Framework的所有注解。请查看相应的JavaDoc以了解进一步的信息，包括默认的属性值等等。

• 该测试用例继承了AbstractTransactionalJUnit4SpringContextTests类， 从这里它继承了针对依赖注入的配置（通过DependencyInjectionTestExecutionListener）和事务性行为（通过TransactionalTestExecutionListener）。

• clinic成员变量 - 要测试的应用程序对象 - 是通过@Autowired进行依赖注入的。

• testGetVets()方法说明如何使用继承下来的countRowsInTable()方法来轻松验证表中的行数， 进而测试应用代码的正确行为。这点允许实现更强大的测试，减少了对确切测试数据的依赖。例如，无需打断测试就可以向数据库中增加新行。

• 像很多使用数据库的集成测试一样，AbstractClinicTests中的大多数测试依赖于测试运行前数据库中已有的最小量的数据。 但是你可能在测试用例中改变数据库——当然，在同一个事务中。