Spring 框架
API
Spring 框架
API

3.2. 集成测试的目标

预计阅读时间: 12 分钟

Spring’s integration testing support has the following primary goals:
春季集成测试支持具有以下主要目标：

The next few sections describe each goal and provide links to implementation and configuration details.
下几节将描述每个目标并提供到实现和配置细节的链接。

(#testing-ctx-management)3.2.1. Context Management and Caching

3.2.1. 上下文管理和缓存

The Spring TestContext Framework provides consistent loading of Spring ApplicationContext instances and WebApplicationContext instances as well as caching of those contexts.
Spring TestContext 框架提供了一致加载 Spring ApplicationContext 实例和 WebApplicationContext 实例，以及缓存这些上下文的功能。
Support for the caching of loaded contexts is important, because startup time can become an issue — not because of the overhead of Spring itself, but because the objects instantiated by the Spring container take time to instantiate.
支持加载上下文的缓存很重要，因为启动时间可能会成为一个问题——不是因为 Spring 本身的开销，而是因为 Spring 容器实例化的对象需要时间来实例化。
For example, a project with 50 to 100 Hibernate mapping files might take 10 to 20 seconds to load the mapping files, and incurring that cost before running every test in every test fixture leads to slower overall test runs that reduce developer productivity.
例如，一个包含 50 到 100 个 Hibernate 映射文件的工程可能需要 10 到 20 秒来加载映射文件，在每次测试每个测试用例之前承担这样的成本会导致整体测试运行速度变慢，从而降低开发者的工作效率。

Test classes typically declare either an array of resource locations for XML or Groovy configuration metadata — often in the classpath — or an array of component classes that is used to configure the application.
测试类通常声明一个用于 XML 或 Groovy 配置元数据的资源位置数组——通常在类路径中——或者一个用于配置应用程序的组件类数组。
These locations or classes are the same as or similar to those specified in web.xml or other configuration files for production deployments.
这些位置或类与 web.xml 或其他生产部署配置文件中指定的相同或类似。

By default, once loaded, the configured ApplicationContext is reused for each test. Thus, the setup cost is incurred only once per test suite, and subsequent test execution is much faster.
默认情况下，一旦加载，配置的 ApplicationContext 将被重复用于每个测试。因此，设置成本在每个测试套件中仅发生一次，后续的测试执行速度要快得多。
In this context, the term “test suite” means all tests run in the same JVM — for example, all tests run from an Ant, Maven, or Gradle build for a given project or module.
在这个上下文中，“测试套件”这个术语指的是在同一个 JVM 中运行的所有测试——例如，对于一个特定项目或模块，从 Ant、Maven 或 Gradle 构建中运行的所有测试。
In the unlikely case that a test corrupts the application context and requires reloading (for example, by modifying a bean definition or the state of an application object) the TestContext framework can be configured to reload the configuration and rebuild the application context before executing the next test.
在不太可能的情况下，如果测试破坏了应用程序上下文并需要重新加载（例如，通过修改 bean 定义或应用程序对象的状态），则可以配置 TestContext 框架在执行下一个测试之前重新加载配置并重建应用程序上下文。

See Context Management and Context Caching with the TestContext framework.
查看 TestContext 框架中的上下文管理和上下文缓存。

(#testing-fixture-di)3.2.2. Dependency Injection of Test Fixtures

3.2.2. 测试固件的依赖注入

When the TestContext framework loads your application context, it can optionally configure instances of your test classes by using Dependency Injection. This provides a convenient mechanism for setting up test fixtures by using preconfigured beans from your application context.
当 TestContext 框架加载您的应用程序上下文时，它可以通过依赖注入的方式选择性地配置您的测试类实例。这提供了一个方便的机制，通过使用预先配置的来自应用程序上下文的 bean 来设置测试固定装置。
A strong benefit here is that you can reuse application contexts across various testing scenarios (for example, for configuring Spring-managed object graphs, transactional proxies, DataSource instances, and others), thus avoiding the need to duplicate complex test fixture setup for individual test cases.
此处的一大优势是您可以在各种测试场景中重用应用程序上下文（例如，用于配置 Spring 管理的对象图、事务代理、 DataSource 实例等），从而避免为单个测试用例重复复杂的测试设置。

As an example, consider a scenario where we have a class (HibernateTitleRepository) that implements data access logic for a Title domain entity. We want to write integration tests that test the following areas:
作为一个例子，考虑一个场景，我们有一个类（ HibernateTitleRepository ）实现了对 Title 域实体的数据访问逻辑。我们希望编写集成测试来测试以下区域：

  • The Spring configuration: Basically, is everything related to the configuration of the HibernateTitleRepository bean correct and present?
    春季配置：基本上，与 HibernateTitleRepository bean 配置相关的所有内容是否正确且存在？

  • The Hibernate mapping file configuration: Is everything mapped correctly and are the correct lazy-loading settings in place?
    Hibernate 映射文件配置：是否所有内容都已正确映射，并且是否已设置正确的懒加载设置？

  • The logic of the HibernateTitleRepository: Does the configured instance of this class perform as anticipated?
    该逻辑 HibernateTitleRepository ：配置的此类实例是否按预期执行？

See dependency injection of test fixtures with the TestContext framework.
查看与 TestContext 框架相关的测试固定依赖注入。

(#testing-tx)3.2.3. Transaction Management

3.2.3. 事务管理

One common issue in tests that access a real database is their effect on the state of the persistence store. Even when you use a development database, changes to the state may affect future tests.
测试访问真实数据库时，一个常见问题是它们对持久化存储状态的影响。即使你使用开发数据库，对状态的变化也可能影响未来的测试。
Also, many operations — such as inserting or modifying persistent data — cannot be performed (or verified) outside of a transaction.
此外，许多操作——例如插入或修改持久数据——无法在事务之外执行（或验证）。

The TestContext framework addresses this issue. By default, the framework creates and rolls back a transaction for each test. You can write code that can assume the existence of a transaction.
测试上下文框架解决了这个问题。默认情况下，框架为每个测试创建和回滚一个事务。您可以编写可以假设事务存在的代码。
If you call transactionally proxied objects in your tests, they behave correctly, according to their configured transactional semantics.
如果您在测试中调用事务代理对象，它们的行为将根据其配置的事务语义正确执行。
In addition, if a test method deletes the contents of selected tables while running within the transaction managed for the test, the transaction rolls back by default, and the database returns to its state prior to execution of the test. Transactional support is provided to a test by using a PlatformTransactionManager bean defined in the test’s application context.
此外，如果在测试的事务管理中运行时，测试方法删除了所选表的内容，则默认情况下事务会回滚，数据库会恢复到测试执行前的状态。通过在测试的应用程序上下文中定义的 PlatformTransactionManager bean 为测试提供事务支持。

If you want a transaction to commit (unusual, but occasionally useful when you want a particular test to populate or modify the database), you can tell the TestContext framework to cause the transaction to commit instead of roll back by using the @Commit annotation.
如果您想使一个事务提交（不常见，但有时在您想使特定测试填充或修改数据库时很有用），您可以使用 @Commit 注解告诉 TestContext 框架使事务提交而不是回滚。

See transaction management with the TestContext framework.
查看使用 TestContext 框架的事务管理。

(#testing-support-classes)3.2.4. Support Classes for Integration Testing

3.2.4. 集成测试支持类

The Spring TestContext Framework provides several abstract support classes that simplify the writing of integration tests. These base test classes provide well-defined hooks into the testing framework as well as convenient instance variables and methods, which let you access:
Spring 测试上下文框架提供了几个支持类，简化了集成测试的编写。这些基本测试类提供了对测试框架的明确钩子以及方便的实例变量和方法，让您可以访问：

  • The ApplicationContext, for performing explicit bean lookups or testing the state of the context as a whole.
    用于执行显式 bean 查找或测试整个上下文的状态的 ApplicationContext 。

  • A JdbcTemplate, for executing SQL statements to query the database. You can use such queries to confirm database state both before and after execution of database-related application code, and Spring ensures that such queries run in the scope of the same transaction as the application code.
    一个 JdbcTemplate ，用于执行 SQL 语句以查询数据库。您可以使用此类查询来确认在执行数据库相关应用程序代码之前和之后数据库的状态，Spring 确保这些查询在与应用程序代码相同的事务范围内运行。
    When used in conjunction with an ORM tool, be sure to avoid false positives.
    当与 ORM 工具结合使用时，务必避免误报。

In addition, you may want to create your own custom, application-wide superclass with instance variables and methods specific to your project.
此外，您可能还想创建一个自己的、适用于整个应用程序的超类，其中包含特定于您项目的实例变量和方法。

See support classes for the TestContext framework.
查看 TestContext 框架的支持类。