在Spring Boot中使用Docker在测试中进行高级功能测试（二）

想更多地了解Spring Boot项目中的功能测试吗？这篇分享至优锐课的学习笔记带你了解有关在测试中使用Docker容器的更多信息。

本文重点介绍在Spring Boot应用程序的功能测试期间应用一些最佳实践。我们将演示一种高级方法，该方法如何在不设置登台环境的情况下将服务作为黑盒进行测试。深入探讨可以进Java学习资料交流qq群：907135806 一起讨论。

回顾一下上篇：在Spring Boot中使用Docker在测试中进行高级功能测试（一）

功能测试

是时候添加功能测试了！对于TDD，在实现之前需要阅读本节。

地点

开始之前，我们需要选择功能测试的位置；还有两个更合适的地方：

• 与单元测试一起在单独的文件夹中：

这是开始添加功能测试的最简单，最快的方法，尽管它有一个很大的缺点：如果要单独运行单元测试，则需要排除功能测试文件夹。为什么每次应用较小的代码修改后都不运行所有测试？因为在大多数情况下，功能测试与单元测试相比具有巨大的执行时间，因此应单独进行修改以节省开发时间。

• 在一个单独的项目以及一个公共父项下的服务项目中：

1. Parent POM (aggregative project)
2. Service project
3. Functional tests project

这种方法比以前的方法有一个优势——我们有一个与服务单元测试隔离的功能测试模块，因此我们可以通过分别运行单元测试或功能测试轻松地验证逻辑。另一方面，这种方法需要一个多模块的项目结构，与单模块的项目相比，难度更大。

你可能已经从服务pom.xml中猜到了，对于我们的情况，我们将选择第二种方法。

父POM文件

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.tdanylchuk</groupId>
    <artifactId>functional-tests-best-practices</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>pom</packaging>
    <name>Functional tests best practices parent project</name>
    <parent>                                                   <!--1-->
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.0.4.RELEASE</version>
        <relativePath/>
    </parent>
    <modules>                                                  <!--2-->
        <module>user-details-service</module>
        <module>user-details-service-functional-tests</module>
    </modules>
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
        <java.version>1.8</java.version>
    </properties>
</project>

1. spring-boot-starter-parent是我们的父POM的父项目。这样，我们就为Spring提供了依赖管理。
2. 模块声明。注意：顺序很重要，功能测试应始终排在最后。

案例

为了挑选功能测试涵盖的案例，我们需要考虑两个主要方面：

• 功能需求——基本上，每个请求的需求都应具有自己的功能测试。
• 较长的执行时间——专注于应用程序的关键部分，与单元测试相反，在单元测试中，应涵盖每个较小的案例。否则，构建时间将是巨大的。

Architecture

是的，测试还需要架构，尤其是功能测试，在这些测试中执行时间很重要，逻辑可能会随着时间变得过于复杂。而且，它们应该是可维护的。这意味着，如果发生功能转移，功能测试对于开发人员而言将不会是头痛的事情。

Steps

步骤（也称为固定装置）是一种封装每个通信通道逻辑的方法。 每个通道应具有自己的步骤对象，该对象与其他步骤隔离。

就我们而言，我们有两个沟通渠道：

• 用户详细信息服务REST API（在渠道中）
• 联系人服务REST API（渠道外）

对于通道中的REST，我们将使用名为REST Assured的库。与我们使用MockMvc进行REST API验证的集成测试相比，这里我们使用更多的黑盒风格测试，以免将Spring上下文与测试模拟对象弄混。

至于REST out通