测试

@BootstrapWith 是一个类级注解，可用于配置Spring TestContext框架的引导方式。 具体来说，你可以使用 @BootstrapWith 指定自定义 TestContextBootstrapper。 有关更多详细信息，请参阅引导TestContext框架部分。

@ContextConfiguration 定义类级元数据，用于确定如何为集成测试加载和配置 ApplicationContext。 具体来说，@ContextConfiguration 声明应用程序上下文资源位置或用于加载上下文的带注解的类。

以下示例显示了引用XML文件的 @ContextConfiguration 注解：

以下示例显示了引用类的 @ContextConfiguration 注解：

作为声明资源位置或带注解的类的替代或补充，你可以使用 @ContextConfiguration 来声明 ApplicationContextInitializer 类。 以下示例显示了这种情况：

你也可以选择使用 @ContextConfiguration 来声明 ContextLoader 策略。但请注意，你通常不需要显式配置加载器， 因为默认加载器支持 initializers 以及资源 locations 或带注解的 classes。

以下示例同时使用资源位置和加载器：

有关更多详细信息，请参阅上下文管理和 @ContextConfiguration javadocs。

@WebAppConfiguration 是一个类级别的注解，可用于声明为集成测试加载的 ApplicationContext 应该是 WebApplicationContext。 仅在测试类上存在 @WebAppConfiguration 时可确保为测试加载 WebApplicationContext， 使用默认值 “file:src/main/webapp” 作为Web应用程序根目录的路径（即资源基本路径）。 在后台使用资源基本路径来创建 MockServletContext，它充当测试的 WebApplicationContext 的 ServletContext。

以下示例显示如何使用 @WebAppConfiguration 注解：

要覆盖默认值，可以使用隐式属性 value 指定不同的基本资源路径。支持 classpath: 和 file: 资源前缀。如果未提供资源前缀， 则假定该路径是文件系统资源。以下示例显示如何指定类路径资源：

请注意，@WebAppConfiguration 必须与 @ContextConfiguration 结合使用，可以在单个测试类中，也可以在测试类层次结构中使用。 有关更多详细信息，请参阅 @WebAppConfiguration javadoc。

@ContextHierarchy 是一个类级别注解，用于为集成测试定义 ApplicationContext 实例的层次结构。 应使用一个或多个 @ContextConfiguration 实例的列表声明 @ContextHierarchy，每个实例定义上下文层次结构中的级别。 以下示例演示了在单个测试类中使用 @ContextHierarchy（@ContextHierarchy 也可以在测试类层次结构中使用）：

如果需要合并或覆盖测试类层次结构中上下文层次结构的给定级别的配置，你必须通过在类层次结构中的每个相应级别为 @ContextConfiguration 中的 name 属性提供相同的值来显式命名该级别。有关更多示例，请参阅上下文层次结构 和 @ContextHierarchy javadoc。

@ActiveProfiles 是一个类级别注解，用于在为集成测试加载 ApplicationContext 时声明哪些bean定义的配置文件应该处于活动状态。

以下示例表明 dev 配置文件应该被激活：

以下示例表明 dev 和 integration 配置文件都应该被激活：

有关示例和更多详细信息，请参阅使用环境配置文件的上下文配置和 @ActiveProfiles javadoc。

@TestPropertySource 是一个类级别注解，可用于配置属性文件的位置和内联属性，这些属性将被添加到 Environment 的 PropertySource 集合中，用于装载用于集成测试的 ApplicationContext。

测试属性源的优先级高于从操作系统环境或Java系统属性加载的属性源，以及应用程序通过 @PropertySource 或以编程方式声明性地添加的属性源。

以下示例演示如何从类路径声明属性文件：

以下示例演示如何声明内联属性：

@DirtiesContext 指示在执行测试期间底层Spring ApplicationContext 已被污染 （即，测试以某种方式修改或损坏它 — 例如，通过更改单例bean的状态）并应该关闭。当应用程序上下文被标记为脏时， 它将从测试框架缓存中删除并关闭。因此，对于需要具有相同配置元数据的上下文的任何后续测试，都会重建基础Spring容器。

你可以将 @DirtiesContext 用作同一个类或类层次结构中的类级别和方法级别注解。 在这种情况下，ApplicationContext 可在任何带该注解的方法之前或之后以及当前测试类之前或之后被标记为脏， 具体取决于配置的 methodMode 和 classMode。

以下示例说明了各种配置方案的上下文何时会变脏：

如果在测试中使用 @DirtiesContext，其上下文被配置为具有 @ContextHierarchy 的上下文层次结构的一部分， 则可以使用 hierarchyMode 标志来控制如何清除上下文缓存。默认情况下，使用穷举算法来清除上下文缓存，不仅包括当前级别， 还包括共享当前测试的祖先上下文的所有其他上下文层次结构。驻留在公共祖先上下文的子层次结构中的所有 ApplicationContext 实例将从上下文缓存中删除并关闭。如果该穷举算法对于特定测试用例而言过度了，则你可以指定更简单的当前级别算法，如以下示例所示。

有关 EXHAUSTIVE 和 CURRENT_LEVEL 算法的更多详细信息，请参阅 DirtiesContext.HierarchyMode javadoc。

@TestExecutionListeners 定义了类级元数据，用于配置应该使用 TestContextManager 注册的 TestExecutionListener 实现。 通常，@TestExecutionListeners 与 @ContextConfiguration 一起使用。

以下示例显示如何注册两个 TestExecutionListener 实现：

默认情况下，@TestExecutionListeners 支持继承的侦听器。有关示例和更多详细信息，请参阅 javadoc。

@Commit 表示应在测试方法完成后提交事务测试方法中的事务。你可以使用 @Commit 替换 @Rollback(false)， 以更明确地传达代码的意图。类似于 @Rollback，@Commit 也可以声明为类级别或方法级别的注解。

以下示例显示了如何使用 @Commit 注解：

@Rollback 指示在测试方法完成后是否应回滚事务测试方法中的事务。如果为 true，则回滚事务。否则，提交事务 （另请参阅@Commit）。即使没有显式声明 @Rollback，Spring TestContext 框架中的集成测试回滚也默认为 true。

声明为类级别注解时，@Rollback 定义测试类层次结构中所有测试方法的默认回滚语义。 当声明为方法级注解时，@Rollback 定义特定测试方法的回滚语义，可能会覆盖类级别的 @Rollback 或 @Commit 语义。

以下示例导致测试方法的结果不回滚（即，结果提交到数据库）：

@BeforeTransaction 指示对于已经配置为使用Spring的 @Transactional 注解在事务中运行的测试方法， 在启动事务之前应该先运行带注解的 void 方法。从Spring Framework 4.3开始，@BeforeTransaction 方法不需要是 public 的， 可以在基于Java 8的接口默认方法中声明。

以下示例显示如何使用 @BeforeTransaction 注解：

@AfterTransaction 指示对于已经配置为使用Spring的 @Transactional 注解在事务中运行的测试方法， 在事务结束后运行带注解的 void 方法。从Spring Framework 4.3开始，@AfterTransaction 方法不需要是 public 的， 可以在基于Java 8的接口默认方法中声明。

以下示例显示如何使用 @AfterTransaction 注解：

@Sql 用于注解测试类或测试方法，以配置在集成测试期间针对给定数据库运行的SQL脚本。以下示例显示了如何使用它：

有关更多详细信息，请参阅使用 @Sql 声明式执行SQL脚本。

@SqlConfig 定义元数据，用于确定如何解析和运行使用 @Sql 注解配置的SQL脚本。以下示例显示了如何使用它：

@SqlGroup 是一个容器注解，它聚合了多个 @Sql 注解。你可以使用 @SqlGroup 本地声明几个嵌套的 @Sql 注解， 或者你可以将它与Java 8可重复注解结合使用，其中 @Sql 可以在同一个类或方法上多次声明，隐式生成此容器注解。 以下示例显示如何声明SQL组：

@IfProfileValue 表示为特定测试环境启用了带注解的测试。如果配置的 ProfileValueSource 返回所提供 name 的匹配 value， 则启用测试。否则，将禁用测试并有效地忽略测试。

你可以在类级别，方法级别或两者中应用 @IfProfileValue。在类级别使用 @IfProfileValue 优先于该类或其子类中的任何方法的方法级使用。 具体而言，如果在类级别和方法级别启用了测试，则启用测试。缺少 @IfProfileValue 意味着隐式启用了测试。 这类似于JUnit 4的 @Ignore 注解的语义，但除了 @Ignore 的存在总是禁用测试的语义。

以下示例显示了具有 @IfProfileValue 注解的测试：

或者，你可以使用值列表（使用 OR 语义）配置 @IfProfileValue，以在JUnit 4环境中为测试组实现类似TestNG的支持。请考虑以下示例：

@ProfileValueSourceConfiguration 是一个类级注解，它指定在检索通过 @IfProfileValue 注解配置的配置文件值时要使用的 ProfileValueSource 的类型。如果未为测试声明 @ProfileValueSourceConfiguration， 则默认使用 SystemProfileValueSource。以下示例显示如何使用 @ProfileValueSourceConfiguration：

@Timed 表示带注解的测试方法必须在指定的时间段内（以毫秒为单位）完成执行。如果执行时间超过指定的时间段，则测试失败。

时间段包括运行测试方法本身，测试的任何重复（参见 @Repeat），以及测试夹具的任何设置或拆除。以下示例显示了如何使用它：

Spring的 @Timed 注解具有与JUnit 4的 @Test(timeout=…​) 支持不同的语义。具体来说， 由于JUnit 4处理测试执行超时的方式（即，通过在单独的线程中执行测试方法），如果测试时间过长，@Test(timeout=…​) 会抢先测试失败。 另一方面，Spring的 @Timed 并没有预先让测试失败，而是等待测试完成后再失败。

@Repeat 表示必须重复运行带注解的测试方法。在注解中指定测试方法的执行次数。

要重复执行的范围包括执行测试方法本身以及测试夹具的任何设置或拆除。以下示例显示如何使用 @Repeat 注解：

TestContext 封装了执行测试的上下文（与使用中的实际测试框架无关），并为其负责的测试实例提供上下文管理和缓存支持。 如果请求，TestContext 还委托 SmartContextLoader 加载 ApplicationContext。

TestContextManager 是Spring TestContext框架的主要入口点，负责管理单个 TestContext， 并在明确定义的测试执行点向每个注册的 TestExecutionListener 发送信号事件：

TestExecutionListener 定义API，以响应由注册侦听器的 TestContextManager 发布的测试执行事件。 请参阅TestExecutionListener 配置。

ContextLoader 是Spring 2.5中引入的一个策略接口，用于为Spring TestContext框架管理的集成测试加载 ApplicationContext。 你应该实现 SmartContextLoader 而不是此接口，以提供对带注解的类，活跃Bean定义配置文件，测试属性源，上下文层次结构和 WebApplicationContext 支持的支持。

SmartContextLoader 是Spring 3.1中引入的 ContextLoader 接口的扩展子类。SmartContextLoader SPI取代了Spring 2.5 中引入的 ContextLoader SPI。具体来说，SmartContextLoader 可以选择处理资源位置，带注解的类或上下文初始值设定项。 此外，SmartContextLoader 可以在其加载的上下文中设置活跃Bean定义概要文件和测试属性源。

Spring提供以下实现：

你可以使用 @TestExecutionListeners 注解为测试类及其子类注册自定义 TestExecutionListener 实现。 有关详细信息和示例，请参阅注解支持和 @TestExecutionListeners的javadoc。

使用 @TestExecutionListeners 注册自定义 TestExecutionListener 实现适用于在有限测试场景中使用的自定义侦听器。 但是，如果需要在测试套件中使用自定义侦听器，则会变得很麻烦。从Spring Framework 4.1开始，通过支持通过 SpringFactoriesLoader 机制自动发现默认的 TestExecutionListener 实现来解决此问题。

具体来说，spring-test 模块在其 META-INF/spring.factories 属性文件中的 org.springframework.test.context.TestExecutionListener 键下声明所有核心默认的 TestExecutionListener 实现。第三方框架和开发人员可以通过自己的 META-INF/spring.factories 属性文件以相同的方式将自己的 TestExecutionListener 实现提供给默认侦听器列表。

当TestContext框架通过前面提到的 SpringFactoriesLoader 机制发现默认的 TestExecutionListener 实现时， 实例化的侦听器将使用Spring的 AnnotationAwareOrderComparator 进行排序，它遵循Spring的 Ordered 接口和 @Order 注解进行排序。 AbstractTestExecutionListener 和Spring提供的所有默认 TestExecutionListener 实现都使用适当的值进行 Ordered。 因此，第三方框架和开发人员应确保通过实现 Ordered 或声明 @Order 以正确的顺序注册其默认的 TestExecutionListener 实现。 有关为每个核心侦听器分配的值的详细信息，请参阅javadoc以获取核心默认 TestExecutionListener 实现的 getOrder() 方法。

如果通过 @TestExecutionListeners 注册了自定义 TestExecutionListener，则不会注册默认侦听器。在大多数常见的测试场景中， 除了任何自定义侦听器之外，这还有效地迫使开发人员手动声明所有默认侦听器。以下清单演示了这种配置：

这种方法的挑战在于它要求开发人员确切地知道默认情况下注册了哪些监听器。此外，默认侦听器集在发行版间可能有所改变 — 例如，Spring Framework 4.1中引入了 SqlScriptsTestExecutionListener，而Spring Framework 4.2中引入了 DirtiesContextBeforeModesTestExecutionListener。此外，Spring Security等第三方框架通过使用上述 自动发现机制注册了自己的默认 TestExecutionListener 实现。

为避免必须知道并重新声明所有默认侦听器，可以将 @TestExecutionListeners 的 mergeMode 属性设置为 MergeMode.MERGE_WITH_DEFAULTS。MERGE_WITH_DEFAULTS 指示本地声明的侦听器应与默认侦听器合并。 合并算法确保从列表中删除重复项，并根据 AnnotationAwareOrderComparator 的语义对生成的合并侦听器集进行排序， 如排序 TestExecutionListener 实现中所述。 如果侦听器实现 Ordered 或使用 @Order 注解，它可以影响它与默认值合并的位置。否则，在合并时， 本地声明的侦听器将追加到默认侦听器列表后。

例如，如果前一个示例中的 MyCustomTestExecutionListener 类将其顺序值（例如，500）配置为小于 ServletTestExecutionListener （恰好为1000）的顺序，则 MyCustomTestExecutionListener 可以自动与默认值列表合并在 ServletTestExecutionListener 前面， 前面的例子可以替换为以下内容：

测试管理的事务是通过使用 TransactionalTestExecutionListener 以声明方式管理的事务，或使用 TestTransaction 以编程方式管理的事务（稍后描述）。 你不应将此类事务与Spring管理的事务（在为测试加载的 ApplicationContext 中由Spring直接管理的事务）或应用程序管理的事务（在测试调用的应用程序代码中以编程方式管理的事务）混淆。Spring管理和应用程序管理的事务通常参与测试管理的事务。但是，如果Spring管理的事务或应用程序管理的事务配置了除 REQUIRED 或 SUPPORTS 之外的任何传播类型，则应谨慎使用（有关详细信息，请参阅有关 事务传播的讨论）。

使用 @Transactional 注解测试方法会导致测试在事务中运行，默认情况下，该事务在测试完成后自动回滚。如果使用 @Transactional 注解测试类，则该类层次结构中的每个测试方法都在事务中运行。未使用 @Transactional 注解的测试方法（在类或方法级别）不在事务中运行。此外，使用 @Transactional 注解但传播类型设置为 NOT_SUPPORTED 的测试也不会在事务中运行。

请注意，AbstractTransactionalJUnit4SpringContextTests 和 AbstractTransactionalTestNGSpringContextTests 已预先配置为类级别的事务支持。

以下示例演示了为基于Hibernate的 UserRepository 编写集成测试的常见方案：

如事务回滚和提交行为中所述，在 createUser() 方法运行后无需清理数据库，因为对 TransactionalTestExecutionListener 会自动回滚对数据库所做的任何更改。有关其他示例，请参阅PetClinic示例。

默认情况下，测试完成后将自动回滚测试事务；但是，可以通过 @Commit 和 @Rollback 注解声明式配置事务提交和回滚行为。有关更多详细信息，请参阅注解支持部分中的相应条目。

从Spring Framework 4.1开始，你可以使用 TestTransaction 中的静态方法以编程方式与测试管理的事务进行交互。例如，你可以在测试方法中，在方法之前，在方法之后使用 TestTransaction 来启动或结束当前的测试管理事务，或者为回滚或提交配置当前测试管理的事务。每当启用 TransactionalTestExecutionListener 时，都会自动提供对 TestTransaction 的支持。

以下示例演示了 TestTransaction 的一些功能。有关详细信息，请参阅 TestTransaction 的javadoc。

有时，你可能需要在事务测试方法之前或之后，但在事务上下文之外执行某些代码 - 例如，在运行测试之前验证初始数据库状态或在测试运行后验证预期的事务提交行为（如果测试配置为提交事务）。TransactionalTestExecutionListener 完全支持 @BeforeTransaction 和 @AfterTransaction 注解。你可以使用其中一个注解在测试类或测试接口中的任何 void default方法中标注任何 void 方法，并且 TransactionalTestExecutionListener 可确保你的前置事务方法或后置事务方法在适当的时间运行。

TransactionalTestExecutionListener 期望在Spring ApplicationContext 中定义 PlatformTransactionManager bean以进行测试。如果测试的 ApplicationContext 中有多个 PlatformTransactionManager 实例，则可以使用 @Transactional("myTxMgr") 或 @Transactional(transactionManager = "myTxMgr") 声明限定符，或者可以通过 @Configuration 类实现 TransactionManagementConfigurer。有关用于在测试的 ApplicationContext 中查找事务管理器的算法的详细信息，请参阅 TestContextTransactionUtils.retrieveTransactionManager() 的javadoc。

以下基于JUnit 4的示例显示了一个虚构的集成测试场景，该场景突出显示了所有与事务相关的注解。该示例不是为了演示最佳实践，而是为了演示如何使用这些注解。有关更多信息和配置示例，请参阅注解支持部分。@Sql 的事务管理包含一个使用 @Sql 进行声明性SQL脚本执行并具有默认事务回滚语义的附加示例。以下示例以粗体显示相关注解：

Spring提供了以下选项，用于在集成测试方法中以编程方式执行SQL脚本。

ScriptUtils 提供了一组用于处理SQL脚本的静态实用工具方法，主要用于框架内部使用。但是，如果你需要完全控制SQL脚本的解析和执行方式，则 ScriptUtils 可能比后面描述的其他一些替代方案更适合你的需求。有关更多详细信息，请参阅 ScriptUtils 中各个方法的 javadoc。

ResourceDatabasePopulator 提供基于对象的API，用于使用外部资源中定义的SQL脚本以编程方式填充，初始化或清理数据库。ResourceDatabasePopulator 提供用于配置解析和运行脚本时使用的字符编码，语句分隔符，注释分隔符和错误处理标志的选项。每个配置选项都有一个合理的默认值。有关默认值的详细信息，请参阅 javadoc。要运行在`ResourceDatabasePopulator` 中配置的脚本，可以调用 populate(Connection) 方法对 java.sql.Connection 执行填充，或者调用 execute(DataSource) 方法对 javax.sql.DataSource 执行填充。以下示例为测试schema和测试数据指定SQL脚本，将语句分隔符设置为 @@，并针对 DataSource 执行脚本：

请注意，ResourceDatabasePopulator 在内部委托给 ScriptUtils 来解析和运行SQL脚本。类似地，AbstractTransactionalJUnit4SpringContextTests和AbstractTransactionalTestNGSpringContextTests中的 executeSqlScript(..) 方法在内部使用 ResourceDatabasePopulator 来运行SQL脚本。有关更多详细信息，请参阅javadoc以获取各种 executeSqlScript(..) 方法。

除了上述以编程方式运行SQL脚本的机制之外，你还可以在Spring TestContext框架中以声明方式配置SQL脚本。具体来说，你可以在测试类或测试方法上声明 @Sql 注解，以配置应在集成测试方法之前或之后针对给定数据库运行的SQL脚本的资源路径。请注意，方法级声明会覆盖类级声明，并且 SqlScriptsTestExecutionListener 会提供对 @Sql 的支持，默认情况下会启用它。

Spring TestContext框架通过自定义运行器（在JUnit 4.12或更高版本上支持）提供与JUnit 4的完全集成。通过使用 @RunWith(SpringJUnit4ClassRunner.class) 或更短的 @RunWith(SpringRunner.class) 变体来注解测试类，开发人员可以实现基于标准JUnit 4的单元和集成测试，同时获得TestContext框架的好处，例如支持加载应用程序上下文，测试实例的依赖项注入，事务测试方法执行等。如果你想将Spring TestContext框架与替代运行器（例如JUnit 4的 Parameterized runner）或第三方运行程序（例如 MockitoJUnitRunner）一起使用，你可以选择使用 Spring对JUnit规则的支持。

以下代码清单显示了配置测试类以使用自定义Spring Runner运行的最低要求：

在前面的示例中，@TestExecutionListeners 配置了一个空列表，以禁用默认侦听器，否则需要通过 @ContextConfiguration 配置 ApplicationContext。

org.springframework.test.context.junit4.rules 包提供以下JUnit 4规则（JUnit 4.12或更高版本支持）：

SpringClassRule 是一个JUnit TestRule，它支持Spring TestContext框架的类级功能，而 SpringMethodRule 是一个JUnit MethodRule，它支持Spring TestContext框架的实例级和方法级功能。

与 SpringRunner 相比，Spring基于规则的JUnit支持具有独立于任何 org.junit.runner.Runner 实现的优势，因此可以与现有的替代Runner（例如JUnit 4的 Parameterized）或第三方Runner（如 MockitoJUnitRunner）结合使用。

要支持 TestContext 框架的完整功能，必须将 SpringClassRule 与 SpringMethodRule 结合使用。以下示例显示了在集成测试中声明这些规则的正确方法：

org.springframework.test.context.junit4 包为基于JUnit 4的测试用例提供以下支持类（在JUnit 4.12或更高版本上受支持）：

AbstractJUnit4SpringContextTests 是一个抽象基础测试类，它将Spring TestContext框架与JUnit 4环境中的显式 ApplicationContext 测试支持集成在一起。继承 AbstractJUnit4SpringContextTests 时，可以访问受保护的 applicationContext 实例变量，该变量可用于执行显式bean查找或测试整个上下文的状态。

AbstractTransactionalJUnit4SpringContextTests 是 AbstractJUnit4SpringContextTests 的抽象事务的扩展，它为JDBC访问添加了一些便利功能。此类要求在 ApplicationContext 中定义 javax.sql.DataSource bean和 PlatformTransactionManager bean。继承 AbstractTransactionalJUnit4SpringContextTests 时，可以访问受保护的 jdbcTemplate 实例变量，该变量可用于运行SQL语句以查询数据库。你可以在运行与数据库相关的应用程序代码之前和之后使用此类查询来确认数据库状态，Spring确保此类查询在与应用程序代码相同的事务范围内运行。与ORM工具结合使用时，请务必避免误报。正如JDBC测试支持中所提到的，AbstractTransactionalJUnit4SpringContextTests 还提供了方便的方法，通过使用前面提到的 jdbcTemplate 委托调用 JdbcTestUtils 中的方法。此外，AbstractTransactionalJUnit4SpringContextTests 提供了一个 executeSqlScript(..) 方法，用于针对配置的 DataSource 运行SQL脚本。

TODO：请移步 这里。

TODO：请移步 这里。

TODO：请移步 这里。

上一节示例中的流式API需要一些静态导入，例如: MockMvcRequestBuilders.*，MockMvcResultMatchers.* 和 MockMvcBuilders.*。 查找这些类的简单方法是搜索与 MockMvc* 匹配的类型。如果你使用Eclipse或基于Eclipse的Spring Tool Suite，请确保在 Java → Editor → Content Assist → Favorites下的Eclipse首选项中将它们添加为“favorite static members”。 这样做可以在键入静态方法名称的第一个字符后使用内容辅助。其他IDE（例如IntelliJ）可能不需要任何其他配置。检查启用静态成员的代码自动完成支持。

你有两个主要方式来创建 MockMvc 的实例。第一种是通过TestContext框架加载Spring MVC配置，它加载Spring配置并将 WebApplicationContext 注入到测试中以用于构建 MockMvc 实例。以下示例显示了如何执行此操作：

第二个选择是手动创建控制器实例而不加载Spring配置。相反，将自动创建与MVC JavaConfig或MVC命名空间大致相当的基本默认配置。 你可以在一定程度上自定义它。以下示例显示了如何执行此操作：

究竟应该使用哪种设置选项呢？

webAppContextSetup 加载你的实际Spring MVC配置，从而实现更完整的集成测试。由于TestContext框架缓存了已加载的Spring配置， 因此即使你在测试套件中引入了更多测试，它也有助于保持测试快速运行。此外，你可以通过Spring配置将模拟服务注入控制器， 以便专注于测试Web层。以下示例使用Mockito声明模拟的服务：

然后，你可以将模拟服务注入测试以设置和验证你的期望，如以下示例所示：

另一方面，standaloneSetup 更接近单元测试。它一次只测试一个控制器。你可以手动注入模拟依赖项到控制器，而不涉及加载Spring配置。 这些测试更注重风格，并且更容易看到正在测试哪个控制器，是否需要任何特定的Spring MVC配置，等等。 standaloneSetup 也是编写ad-hoc测试以验证特定行为或调试问题的一种非常方便的方法。

与大多数“集成测试vs单元测试”辩论一样，这没有正确或错误的答案。然而，使用 standaloneSetup 确实意味着你需要额外的 webAppContextSetup 测试来验证Spring MVC配置。或者，你可以使用 webAppContextSetup 编写所有测试，以便始终针对你的实际 Spring MVC配置进行测试。

无论你使用哪个 MockMvc 构建器，所有 MockMvcBuilder 实现都提供了一些常用且非常有用的功能。 例如，你可以为所有请求声明 Accept 标头，并期望所有响应中的状态为200以及 Content-Type 标头如你所想，如下所示：

此外，第三方框架（和应用程序）可以预先打包设置指令，例如 MockMvcConfigurer 中的设置指令。 Spring框架有一个这样的内置实现，可以帮助跨请求保存和重用HTTP会话。你可以按如下方式使用它：

有关所有 MockMvc 构建器功能的列表，请参阅 ConfigurableMockMvcBuilder 的javadoc，或使用IDE浏览可用选项。

你可以执行使用任何HTTP方法的请求，如以下示例所示：

你还可以执行内部使用 MockMultipartHttpServletRequest 的文件上传请求，以便不会实际解析multipart请求。 相反，你必须将其设置为类似于以下示例：

你可以在URI模板样式中指定查询参数，如以下示例所示：

你还可以添加表示查询或表单参数的Servlet请求参数，如以下示例所示：

如果应用程序代码依赖于Servlet请求参数，并且不显式检查查询字符串（通常情况下），则使用哪个选项无关紧要。 但请记住，URI模板提供的查询参数会被解码，而通过 param(…​) 方法提供的请求参数期望已经被解码了。

在大多数情况下，最好将上下文路径和Servlet路径保留在请求URI之外。如果必须使用完整请求URI进行测试，请确保相应地设置 contextPath 和 servletPath 以使请求映射有效，如以下示例所示：

在前面的示例中，为每个执行的请求设置 contextPath 和 servletPath 是很麻烦的。相反，你可以设置默认请求属性，如以下示例所示：

前面的属性会影响通过 MockMvc 实例执行的每个请求。如果在给定请求上也指定了相同的属性，则它将覆盖默认值。 这就是为什么在默认请求中设置HTTP方法和URI无关紧要，因为它们必须在每个请求上指定并被覆盖。

你可以通过在执行请求后附加一个或多个 .andExpect(…​) 调用来定义期望，如以下示例所示：

MockMvcResultMatchers.* 提供了许多期望，其中一些进一步嵌套了更详细的期望。

期望分为两大类。第一类断言验证响应的属性（例如，响应状态，标头和内容），这些是断言中最重要的结果。

第二类断言不仅仅是响应。这些断言让你可以检查Spring MVC的特定方面，例如哪个控制器方法处理了请求，是否抛出并处理了异常情况， 模型的内容是什么，选择了什么视图，添加了什么flash属性，等等。它们还允许你检查Servlet的特定方面，例如请求和会话属性。

以下测试断言参数绑定或校验失败：

很多时候，在编写测试时，转储请求的执行结果会很有用。你可以按如下方式执行此操作， 其中 print() 是来自 MockMvcResultHandlers 的静态导入：

只要请求处理不导致未处理的异常，print() 方法就会将所有可用的结果数据打印到 System.out。 Spring Framework 4.2引入了一个 log() 方法和 print() 方法的另外两个变体，一个接受 OutputStream，另一个接受 Writer。 例如，调用 print(System.err) 将结果数据打印到 System.err，而调用 print(myWriter) 将结果数据打印到自定义字符写入流。 如果要记录结果数据而不是打印结果数据，可以调用 log() 方法，该方法将结果数据作为单个 DEBUG 消息记录在 org.springframework.test.web.servlet.result 日志类别下。

在某些情况下，你可能希望直接访问结果并验证一些无法通过其他方式验证的内容。这可以通过在所有其他期望之后附加 .andReturn() 来实现， 如以下示例所示：

如果所有测试都重复声明相同的期望，则可以在构建 MockMvc 实例时设置一次共同期望，如以下示例所示：

请注意，如果不创建单独的 MockMvc 实例，则始终应用共同期望并且无法被覆盖。

当JSON响应内容包含使用 Spring HATEOAS创建的超媒体链接时， 你可以使用JsonPath表达式验证生成的链接，如以下示例所示：

当XML响应内容包含使用 Spring HATEOAS创建的超媒体链接时， 你可以使用XPath表达式验证生成的链接：

设置 MockMvc 实例时，可以注册一个或多个Servlet Filter 实例，如以下示例所示：

注册过滤器会通过 spring-test 中的 MockFilterChain 调用，最后一个过滤器委托给 DispatcherServlet。

如前所述，Spring MVC Test构建于 spring-test 模块的Servlet API模拟对象之上，并不使用正在运行的Servlet容器。因此， 与实际客户端和服务器运行的完整端到端集成测试相比，存在一些重要差异。

考虑这一点的最简单方法是从一个空白的 MockHttpServletRequest 开始。无论你添加什么使请求变成什么。 可能会让你感到意外的事情是默认情况下没有上下文路径、没有 jsessionid cookie、没有转发、错误或异步调度、因此，没有实际的JSP渲染。 相反，“转发”和“重定向”URLs保存在 MockHttpServletResponse 中，并且可用于期望断言。

这意味着，如果使用JSP，则可以验证请求转发到的JSP页面，但不呈现HTML。换句话说，不调用JSP。但请注意，所有其他不依赖转发的渲染技术 （如Thymeleaf和Freemarker）都会按预期将HTML呈现给响应主体。通过 @ResponseBody 方法渲染JSON，XML和其他格式也是如此。

或者，你可以考虑使用 @WebIntegrationTest 从Spring Boot获得完整的端到端集成测试支持。请参阅 Spring Boot参考文档。

每种方法都有利弊。Spring MVC Test中提供的选项是从经典单元测试到完全集成测试的不同阶段。 可以肯定的是，Spring MVC Test中没有一个选项属于经典单元测试类别，但它们很接近它。 例如，你可以通过将模拟服务注入控制器来隔离Web层，在这种情况下，你只通过 DispatcherServlet 测试Web层，但是使用实际的Spring配置， 因为你可能独立于上面的层来测试数据访问层。此外，你可以使用独立设置，一次关注一个控制器并手动提供使其工作所需的配置。

使用Spring MVC Test时的另一个重要区别是，从概念上讲，这样的测试是服务器端，因此你可以检查使用了什么执行器，是否使用 HandlerExceptionResolver 处理异常，模型的内容是什么，绑定错误是什么和其他细节。这意味着编写期望更容易，因为服务器不是黑盒子， 就像通过实际的HTTP客户端测试它一样。这通常是经典单元测试的一个优点：它更容易编写，推理和调试，但不能取代完全集成测试。 同时，重要的是不要忽视响应是最重要的需要去检查的事物。简而言之，即使在同一个项目中，也有多种测试风格和策略的空间。

框架自身的测试包括 许多样例测试，旨在展示如何使用Spring MVC测试。你可以浏览这些示例以获取更多想法。 此外， spring-mvc-showcase项目具有基于Spring MVC Test的完整测试覆盖率。

能想到的最明显的问题是“为什么我需要这个？”通过探索一个非常基本的示例应用程序可以找到答案。假设你有一个Spring MVC Web应用程序， 它支持 Message 对象上的CRUD操作。该应用程序还支持分页所有消息。你会如何测试它？

使用Spring MVC Test，我们可以轻松测试是否能够创建 Message，如下所示：

如果我们要测试允许我们创建消息的表单视图，该怎么办？例如，假设我们的表单看起来像以下代码段：

我们如何确保我们的表单产生创建新消息的正确请求？天真的尝试可能类似于以下内容：

该测试有一些明显的缺点。如果我们更新控制器以使用参数 message 替换 text，我们的表单测试将继续通过， 即使HTML表单与控制器不同步。要解决这个问题，我们可以结合两个测试，如下所示：

这样可以降低我们测试错误传递的风险，但仍然存在一些问题：

总体问题是测试网页不涉及单个交互。相反，它是用户如何与网页交互以及该网页如何与其他资源交互的组合。 例如，表单视图的结果用作用户输入以创建消息。此外，我们的表单视图可能会使用影响页面行为的其他资源，例如JavaScript验证。

本节介绍如何集成MockMvc和HtmlUnit。如果要使用原始HtmlUnit库，请使用此选项。

TODO：请移步 这里。

TODO：请移步 这里。

与服务器端测试一样，用于客户端测试的流式API需要一些静态导入。通过搜索 MockRest* 很容易找到它们。 Eclipse用户应该在Java → Editor → Content Assist → Favorites中添加 MockRestRequestMatchers.* 和 MockRestResponseCreators.* 作为“favorite static members”。这允许在键入静态方法名称的第一个字符后使用内容辅助。 其他IDE（例如IntelliJ）可能不需要任何其他配置。检查是否支持对静态成员的代码自动完成。

Spring MVC Test自己的测试包括客户端REST测试的 示例测试。