This chapter covers Springrsquo;s support for integration testing and best practices for unit testing. The Spring team advocates test-driven development (TDD). The Spring team has found that the correct use of inversion of control (IoC) certainly does make both unit and integration testing easier (in that the presence of setter methods and appropriate constructors on classes makes them easier to wire together in a test without having to set up service locator registries and similar structures).

1. Introduction to Spring Testing

Testing is an integral part of enterprise software development. This chapter focuses on the value added by the IoC principle to unit testing and on the benefits of the Spring Frameworkrsquo;s support for integration testing. (A thorough treatment of testing in the enterprise is beyond the scope of this reference manual.)

2. Unit Testing

Dependency injection should make your code less dependent on the container than it would be with traditional Java EE development. The POJOs that make up your application should be testable in JUnit or TestNG tests, with objects instantiated by using the new operator, without Spring or any other container. You can use mock objects (in conjunction with other valuable testing techniques) to test your code in isolation. If you follow the architecture recommendations for Spring, the resulting clean layering and componentization of your codebase facilitate easier unit testing. For example, you can test service layer objects by stubbing or mocking DAO or repository interfaces, without needing to access persistent data while running unit tests.

True unit tests typically run extremely quickly, as there is no runtime infrastructure to set up. Emphasizing true unit tests as part of your development methodology can boost your productivity. You may not need this section of the testing chapter to help you write effective unit tests for your IoC-based applications. For certain unit testing scenarios, however, the Spring Framework provides mock objects and testing support classes, which are described in this chapter.

2.1. Mock Objects

Spring includes a number of packages dedicated to mocking:

• Environment
• JNDI
• Servlet API
• Spring Web Reactive

2.1.1. Environment

The org.springframework.mock.env package contains mock implementations of the Environment and PropertySourceabstractions (see Bean Definition Profiles and PropertySource Abstraction). MockEnvironment and MockPropertySource are useful for developing out-of-container tests for code that depends on environment-specific properties.

2.1.2. JNDI

The org.springframework.mock.jndi package contains an implementation of the JNDI SPI, which you can use to set up a simple JNDI environment for test suites or stand-alone applications. If, for example, JDBC DataSource instances get bound to the same JNDI names in test code as they do in a Java EE container, you can reuse both application code and configuration in testing scenarios without modification.

2.1.3. Servlet API

The org.springframework.mock.web package contains a comprehensive set of Servlet API mock objects that are useful for testing web contexts, controllers, and filters. These mock objects are targeted at usage with Springrsquo;s Web MVC framework and are generally more convenient to use than dynamic mock objects (such as EasyMock) or alternative Servlet API mock objects (such as MockObjects).

2.1.4. Spring Web Reactive

The org.springframework.mock.http.server.reactive package contains mock implementations of ServerHttpRequest and ServerHttpResponse for use in WebFlux applications. The org.springframework.mock.web.server package contains a mock ServerWebExchange that depends on those mock request and response objects.

Both MockServerHttpRequest and MockServerHttpResponse extend from the same abstract base classes as server-specific implementations and share behavior with them. For example, a mock request is immutable once created, but you can use the mutate() method from ServerHttpRequest to create a modified instance.

In order for the mock response to properly implement the write contract and return a write completion handle (that is, Monolt;Voidgt;), it by default uses a Flux with cache().then(), which buffers the data and makes it available for assertions in tests. Applications can set a custom write function (for example, to test an infinite stream).

The WebTestClient builds on the mock request and response to provide support for testing WebFlux applications without an HTTP server. The client can

本章介绍Spring对集成测试的支持和单元测试的最佳实践。Spring团队提倡测试驱动开发（TDD）。Spring团队发现正确使用控制反转（IoC）肯定会使单元测试和集成测试更容易（因为类的setter方法和适当的构造函数的存在使得它们更容易在测试中连接在一起而不必设置服务定位器注册表和类似结构）。

1.弹簧测试简介

测试是企业软件开发不可或缺的一部分。本章重点介绍IoC原理对单元测试的附加值以及Spring Framework对集成测试支持的好处。（对企业中的测试进行全面处理超出了本参考手册的范围。）

2.单元测试

与传统的Java EE开发相比，依赖注入应该使您的代码对容器的依赖性降低。构成应用程序的POJO应该在JUnit或TestNG测试中可测试，对象使用new 运算符实例化，不使用Spring或任何其他容器。您可以使用模拟对象（与其他有价值的测试技术结合使用）来单独测试代码。如果您遵循Spring的体系结构建议，那么代码库的干净分层和组件化便于单元测试。例如，您可以通过存根或模拟DAO或存储库接口来测试服务层对象，而无需在运行单元测试时访问持久数据。

真正的单元测试通常运行得非常快，因为没有要设置的运行时的基础结构。强调真正的单元测试作为开发方法的一部分可以提高您的工作效率。您可能不需要测试章节的这一部分来帮助您为基于IoC的应用程序编写有效的单元测试。但是，对于某些单元测试场景，Spring Framework提供了模拟对象和测试支持类，本章将对其进行介绍。

2.1。模拟物体

Spring包含许多专门用于模拟的包：

• 环境
• JNDI
• Servlet API
• Spring Web Reactive

2.1.1。环境

该org.springframework.mock.env包包含Environment和PropertySource抽象的模拟实现 （请参阅 Bean定义配置文件 和PropertySource抽象）。 MockEnvironment并且MockPropertySource对于依赖于特定于环境的属性的代码开发容器外测试很有用。

2.1.2。JNDI

该org.springframework.mock.jndi软件包包含JNDI SPI的实现，您可以使用它为测试套件或独立应用程序设置简单的JNDI环境。例如，如果JDBC DataSource实例在测试代码中绑定到与Java EE容器中相同的JNDI名称，则可以在测试方案中重用应用程序代码和配置而无需修改。

2.1.3。Servlet API

该org.springframework.mock.web软件包包含一组全面的Servlet API模拟对象，可用于测试Web上下文，控制器和过滤器。这些模拟对象的目标是使用Spring的Web MVC框架，并且通常比动态模拟对象（例如EasyMock）或替代Servlet API模拟对象（例如MockObjects）更方便使用。

2.1.4。Spring Web Reactive

该org.springframework.mock.http.server.reactive软件包包含WebFlux应用程序的模拟实现ServerHttpRequest和ServerHttpResponse用于WebFlux应用程序。该 org.springframework.mock.web.server包包含一个ServerWebExchange依赖于那些模拟请求和响应对象的模拟。

二者MockServerHttpRequest并MockServerHttpResponse从相同的抽象基类延伸特定于服务器的实现方式，并与他们共享行为。例如，模拟请求一旦创建就是不可变的，但您可以使用该mutate()方法ServerHttpRequest创建修改后的实例。

为了使模拟响应正确地实现写入合同并返回写入完成句柄（即，Monolt;Voidgt;），它默认使用Fluxwith cache().then()，它缓冲数据并使其可用于测试中的断言。应用程序可以设置自定义写入功能（例如，测试无限流）。

在WebTestClient建立在模拟的请求和响应，以用于不具有HTTP服务器测试WebFlux应用提供支持。客户端还可以用于正在运行的服务器的端到端测试。

2.2。单元测试支持类

Spring包含许多可以帮助进行单元测试的类。它们分为两类：

• 一般测试实用程序
• Spring MVC测试实用程序

2.2.1。一般测试实用程序

该org.springframework.test.util软件包包含几个用于单元和集成测试的通用实用程序。

ReflectionTestUtils是基于反射的实用方法的集合。您可以在测试需要更改常量值，设置非public字段，调用非publicsetter方法或public 在测试用例的应用程序代码时调用非配置或生命周期回调方法的场景中使用这些方法。如下：

• ORM框架（例如JPA和Hibernate），它们容忍private或protected字段访问，而不是public域实体中属性的setter方法。
• 弹簧的注解（如支持@Autowired，@Inject和@Resource），即用于提供依赖注入private或protected字段，setter方法和配置方法。
• 使用注释，例如@PostConstruct和@PreDestroy生命周期回调方法。

AopTestUtils是AOP相关实用方法的集合。您可以使用这些方法获取对隐藏在一个或多个Spring代理后面的基础目标对象的引用。例如，如果您通过使用诸如EasyMock或Mockito之类的库将bean配置为动态模拟，并且模拟包装在Spring代理中，则可能需要直接访问底层模拟以配置对它的期望并执行验证。对于Spring的核心AOP实用程序，请参阅AopUtils和 AopProxyUtils。

2.2.2。Spring MVC测试实用程序

该org.springframework.test.web软件包中包含 ModelAndViewAssert，您可以结合使用使用JUnit，TestNG的，或者单元测试，使用Spring MVC处理任何其他测试框架ModelAndView的对象。

3.集成测试

本节（本章的大部分内容）介绍了Spring应用程序的集成测试。它包括以下主题：

• 概观
• 集成测试的目标
• JDBC测试支持
• 注释
• Spring TestContext框架
• Spring MVC测试框架
<!--资料编号：[4500]