实用测试金字塔

功能

应用程序的功能很简单。它提供了一个具有三个端点的 REST 接口

高级结构

系统在高层级的结构如下

图 3：微服务系统的层次结构

我们的微服务提供了一个可以通过 HTTP 调用的 REST 接口。对于某些端点，该服务会从数据库中获取信息。在其他情况下，该服务会通过 HTTP 调用外部天气 API来获取和显示当前天气状况。

内部架构

在内部，Spring 服务具有典型的 Spring 架构

图 4：微服务的内部结构

• Controller 类提供REST 端点，并处理HTTP 请求和响应
• Repository 类与数据库交互，并负责将数据写入/从持久性存储中读取数据
• Client 类与其他 API 通信，在我们的案例中，它通过HTTPS 从 darksky.net 天气 API 中获取JSON
• Domain 类捕获我们的领域模型，包括领域逻辑（公平地说，在我们的案例中非常简单）。

经验丰富的 Spring 开发人员可能会注意到这里缺少一个经常使用的层：受领域驱动设计的启发，许多开发人员构建了一个包含服务类的服务层。我决定不在此应用程序中包含服务层。原因之一是我们的应用程序足够简单，服务层将是一个不必要的间接级别。另一个原因是我认为人们对服务层做得太过火了。我经常遇到代码库，其中整个业务逻辑都在服务类中捕获。领域模型仅仅成为数据层，而不是行为层（贫血领域模型）。对于每个非平凡的应用程序，这都会浪费很多潜力来保持代码结构良好且可测试，并且没有充分利用面向对象的功能。

我们的存储库非常简单，并提供简单的CRUD功能。为了保持代码简单，我使用了Spring Data。Spring Data 为我们提供了一个简单且通用的 CRUD 存储库实现，我们可以使用它来代替自己动手。它还负责为我们的测试启动一个内存数据库，而不是像在生产中那样使用真正的 PostgreSQL 数据库。

查看代码库，并熟悉内部结构。这将有助于我们下一步：测试应用程序！

什么是单元？

如果你问三个不同的人在单元测试的上下文中“单元”意味着什么，你可能会收到四个不同的、略有细微差别的答案。在某种程度上，这是你自己的定义问题，没有规范答案是可以的。

如果您使用的是函数式语言，则一个单元很可能是一个单独的函数。您的单元测试将使用不同的参数调用一个函数，并确保它返回预期的值。在面向对象语言中，一个单元可以从单个方法到整个类。

社交和独处

一些人认为，受测对象的所有协作者（例如，受测类调用的其他类）都应替换为模拟或存根，以实现完美的隔离并避免副作用和复杂的测试设置。另一些人则认为，只有速度慢或副作用较大的协作者（例如，访问数据库或进行网络调用的类）才应该被存根或模拟。

偶尔人们将这两种类型的测试标记为孤立单元测试（用于存根所有协作者的测试）和社交单元测试（允许与真实协作者对话的测试）（Jay Fields 的使用单元测试高效工作创造了这些术语）。如果您有一些空闲时间，您可以深入了解并阅读有关不同思想流派的利弊。

最终，决定采用孤立单元测试还是社交单元测试并不重要。编写自动化测试才是最重要的。就我个人而言，我发现自己一直在使用这两种方法。如果使用真实协作者变得很尴尬，我将慷慨地使用模拟和存根。如果我觉得让真实协作者参与会让我对测试更有信心，我只会存根服务的最外层部分。

模拟和存根

用通俗的话来说，这意味着您用该事物的假版本替换真实事物（例如，类、模块或函数）。假版本看起来并像真实事物一样（对相同的方法调用做出响应），但使用您在单元测试开始时自己定义的罐头响应进行响应。

使用测试替身不仅仅适用于单元测试。更精细的测试替身可用于以受控方式模拟系统的整个部分。但是，在单元测试中，您最有可能遇到许多模拟和存根（取决于您是社交型还是孤立型开发人员），仅仅是因为许多现代语言和库使设置模拟和存根变得容易且方便。

无论您选择哪种技术，您的语言的标准库或一些流行的第三方库都很有可能为您提供设置模拟的优雅方法。甚至从头开始编写自己的模拟也只需要编写一个假类/模块/函数，其签名与真实类/模块/函数相同，并在测试中设置假类/模块/函数即可。

您的单元测试将运行得非常快。在性能良好的机器上，您可以在几分钟内运行数千个单元测试。在隔离中测试代码库的小部分，并避免访问数据库、文件系统或发出 HTTP 查询（通过对这些部分使用模拟和存根）以保持测试速度。

一旦你掌握了编写单元测试，你将变得越来越熟练。模拟外部协作者，设置一些输入数据，调用被测对象并检查返回的值是否是你所期望的。深入了解测试驱动开发，让你的单元测试指导你的开发；如果应用得当，它可以帮助你进入一个良好的流程，并提出一个良好且可维护的设计，同时自动生成一个全面且完全自动化的测试套件。不过，它并不是灵丹妙药。继续吧，给它一个真正机会，看看它是否适合你。

测试什么？

单元测试的好处是，你可以为所有生产代码类编写它们，无论它们的功能如何，或者它们属于内部结构中的哪一层。你可以像单元测试存储库、域类或文件读取器一样单元测试控制器。只需坚持每个生产类一个测试类的经验法则，你就可以有一个良好的开端。

单元测试类至少应该测试类的公共接口。私有方法无论如何都无法测试，因为你根本无法从不同的测试类中调用它们。受保护的或包私有的方法可以从测试类访问（假设你的测试类的包结构与生产类相同），但测试这些方法可能已经走得太远了。

在编写单元测试时有一个微妙的界限：它们应该确保所有非平凡的代码路径都经过测试（包括正常路径和边缘情况）。同时，它们不应该与你的实现联系得太紧密。

为什么呢？

与生产代码过于接近的测试很快就会变得讨厌。只要你重构生产代码（快速回顾：重构是指在不改变外部可见行为的情况下改变代码的内部结构），单元测试就会中断。

这样，你就会失去单元测试的一大好处：充当代码更改的安全网。你反而会厌倦这些愚蠢的测试，每次重构时都会失败，造成的工作量大于帮助；而且，是谁想出这种愚蠢的测试东西的？

你该怎么做？不要在单元测试中反映内部代码结构。而是测试可观察行为。考虑

如果我输入值x和y，结果会是z吗？

而不是

如果我输入x和y，方法会首先调用类 A，然后调用类 B，再返回类 A 的结果加上类 B 的结果吗？

私有方法通常应被视为实现细节。这就是为什么你甚至不应该有测试它们的冲动。

我经常听到单元测试（或TDD）的反对者争论说，编写单元测试会变成毫无意义的工作，你必须测试所有方法才能获得高测试覆盖率。他们经常引用这样的场景：一个过于急切的团队负责人强迫他们为 getter 和 setter 以及所有其他琐碎代码编写单元测试，以获得 100% 的测试覆盖率。

这里有很多错误。

是的，你应该测试公共接口。然而，更重要的是，你不要测试琐碎的代码。别担心，Kent Beck 说这样做是可以的。你不会从测试简单的getter或setter或其他琐碎的实现（例如，没有任何条件逻辑）中获得任何好处。节省时间，这可是你可以参加的又一次会议，万岁！

测试结构

所有测试（这不仅限于单元测试）的一个好结构是

1. 设置测试数据
2. 调用要测试的方法
3. 断言返回了预期的结果

有一个很好的助记符可以记住这个结构：“安排、执行、断言”。另一个你可以使用的助记符是从BDD中获得灵感。它是“给定”、“当”、“然后”三元组，其中给定反映了设置，当反映了方法调用，然后反映了断言部分。

此模式还可以应用于其他更高级别的测试。在每种情况下，它们都能确保你的测试保持易读且一致。最重要的是，牢记此结构编写的测试往往更短且更具表现力。

实施单元测试

现在我们知道了要测试的内容以及如何构建单元测试，我们终于可以看到一个真实的示例。

让我们采用 ExampleController 类的简化版本

@RestController
public class ExampleController {

    private final PersonRepository personRepo;

    @Autowired
    public ExampleController(final PersonRepository personRepo) {
        this.personRepo = personRepo;
    }

    @GetMapping("/hello/{lastName}")
    public String hello(@PathVariable final String lastName) {
        Optional<Person> foundPerson = personRepo.findByLastName(lastName);

        return foundPerson
                .map(person -> String.format("Hello %s %s!",
                        person.getFirstName(),
                        person.getLastName()))
                .orElse(String.format("Who is this '%s' you're talking about?",
                        lastName));
    }
}

针对 hello(lastname) 函数的单元测试可能如下所示

public class ExampleControllerTest {

    private ExampleController subject;

    @Mock
    private PersonRepository personRepo;

    @Before
    public void setUp() throws Exception {
        initMocks(this);
        subject = new ExampleController(personRepo);
    }

    @Test
    public void shouldReturnFullNameOfAPerson() throws Exception {
        Person peter = new Person("Peter", "Pan");
        given(personRepo.findByLastName("Pan"))
            .willReturn(Optional.of(peter));

        String greeting = subject.hello("Pan");

        assertThat(greeting, is("Hello Peter Pan!"));
    }

    @Test
    public void shouldTellIfPersonIsUnknown() throws Exception {
        given(personRepo.findByLastName(anyString()))
            .willReturn(Optional.empty());

        String greeting = subject.hello("Pan");

        assertThat(greeting, is("Who is this 'Pan' you're talking about?"));
    }
}

我们使用 JUnit 编写单元测试，JUnit 是 Java 的事实标准测试框架。我们使用 Mockito 用存根替换真正的 PersonRepository 类以进行测试。此存根允许我们定义罐头响应，存根函数应在此测试中返回。存根使我们的测试更加简单、可预测，并允许我们轻松设置测试数据。

遵循“安排、执行、断言”结构，我们编写两个单元测试 - 一个正例和一个搜索不到人员的情况。第一个正例测试用例创建一个新人员对象，并告知模拟存储库在使用 “Pan” 作为 lastName 参数的值调用它时返回此对象。然后，测试继续调用应测试的函数。最后，它断言响应等于预期响应。

第二个测试的工作方式类似，但测试的是测试函数未针对给定参数找到人员的情况。

数据库集成

PersonRepository 是代码库中唯一的存储库类。它依赖于 Spring Data，并且没有实际实现。它只是扩展了 CrudRepository 接口，并提供了一个单一的方法头。其余部分是 Spring 的魔力。

public interface PersonRepository extends CrudRepository<Person, String> {
    Optional<Person> findByLastName(String lastName);
}

通过 CrudRepository 接口，Spring Boot 提供了一个功能齐全的 CRUD 存储库，其中包含 findOne、findAll、save、update 和 delete 方法。我们的自定义方法定义 (findByLastName()) 扩展了此基本功能，并为我们提供了一种按姓氏获取 Person 的方法。Spring Data 分析方法的返回类型及其方法名称，并根据命名约定检查方法名称，以找出它应该做什么。

尽管 Spring Data 在实现数据库存储库方面做了大量工作，但我仍然编写了一个数据库集成测试。你可能会认为这是在 测试框架，而我应该避免这样做，因为我们不是在测试我们的代码。不过，我相信至少在这里进行一次集成测试至关重要。首先，它测试了我们的自定义 findByLastName 方法是否按预期实际运行。其次，它证明了我们的存储库正确地使用了 Spring 的布线，并且可以连接到数据库。

为了让你更轻松地在你的机器上运行测试（无需安装 PostgreSQL 数据库），我们的测试连接到了一个内存中的 H2 数据库。

我在 build.gradle 文件中将 H2 定义为一个测试依赖项。测试目录中的 application.properties 没有定义任何 spring.datasource 属性。这告诉 Spring Data 使用内存数据库。由于它在类路径中找到了 H2，因此在运行我们的测试时它只会使用 H2。

在使用 int 配置文件运行实际应用程序时（例如，通过将 SPRING_PROFILES_ACTIVE=int 设置为环境变量），它会连接到 application-int.properties 中定义的 PostgreSQL 数据库。

我知道，这是很多需要了解和理解的 Spring 细节。为了做到这一点，你必须仔细阅读 大量文档。生成的代码很容易理解，但如果你不知道 Spring 的细节，就很难理解。

最重要的是，使用内存数据库是一件有风险的事情。毕竟，我们的集成测试针对的是不同类型的数据库，而不是生产中的数据库。继续，根据自己的喜好，决定是选择 Spring 的魔力与简单的代码，还是选择明确但更冗长的实现。

解释已经足够了，这里有一个简单的集成测试，它将一个人保存到数据库中，并按其姓氏查找

@RunWith(SpringRunner.class)
@DataJpaTest
public class PersonRepositoryIntegrationTest {
    @Autowired
    private PersonRepository subject;

    @After
    public void tearDown() throws Exception {
        subject.deleteAll();
    }

    @Test
    public void shouldSaveAndFetchPerson() throws Exception {
        Person peter = new Person("Peter", "Pan");
        subject.save(peter);

        Optional<Person> maybePeter = subject.findByLastName("Pan");

        assertThat(maybePeter, is(Optional.of(peter)));
    }
}

你可以看到，我们的集成测试遵循与单元测试相同的 安排、执行、断言 结构。告诉你，这是一个普遍的概念！

与独立服务的集成

我们的微服务与 darksky.net 通信，这是一个天气 REST API。当然，我们希望确保我们的服务正确发送请求并解析响应。

在运行自动化测试时，我们希望避免访问真正的 darksky 服务器。我们的免费计划的配额限制只是原因之一。真正的原因是 解耦。我们的测试应该独立于 darksky.net 上可爱的人们正在做什么。即使你的机器无法访问 darksky 服务器或 darksky 服务器因维护而关闭。

在运行集成测试时，我们可以通过运行我们自己的、假的 darksky 服务器来避免访问真正的 darksky 服务器。这听起来像一项艰巨的任务。感谢 Wiremock 等工具，这很容易。看这个

@RunWith(SpringRunner.class)
@SpringBootTest
public class WeatherClientIntegrationTest {

    @Autowired
    private WeatherClient subject;

    @Rule
    public WireMockRule wireMockRule = new WireMockRule(8089);

    @Test
    public void shouldCallWeatherService() throws Exception {
        wireMockRule.stubFor(get(urlPathEqualTo("/some-test-api-key/53.5511,9.9937"))
                .willReturn(aResponse()
                        .withBody(FileLoader.read("classpath:weatherApiResponse.json"))
                        .withHeader(CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
                        .withStatus(200)));

        Optional<WeatherResponse> weatherResponse = subject.fetchWeather();

        Optional<WeatherResponse> expectedResponse = Optional.of(new WeatherResponse("Rain"));
        assertThat(weatherResponse, is(expectedResponse));
    }
}

要使用 Wiremock，我们在一个固定的端口 (8089) 上实例化一个 WireMockRule。使用 DSL，我们可以设置 Wiremock 服务器，定义它应该侦听的端点，并设置它应该响应的罐头响应。

接下来，我们调用我们要测试的方法，即调用第三方服务的方法，并检查结果是否被正确解析。

了解测试如何知道它应该调用伪造的 Wiremock 服务器，而不是真正的 darksky API 非常重要。秘密就在于我们包含在 src/test/resources 中的 application.properties 文件中。这是 Spring 在运行测试时加载的属性文件。在此文件中，我们使用适合于我们的测试目的的值覆盖了 API 密钥和 URL 等配置，例如调用伪造的 Wiremock 服务器，而不是真正的服务器

weather.url = https://127.0.0.1:8089

请注意，此处定义的端口必须与我们在测试中实例化 WireMockRule 时定义的端口相同。通过在 WeatherClient 类的构造函数中注入 URL，可以在测试中用伪造的 URL 替换真正的天气 API 的 URL

@Autowired
public WeatherClient(final RestTemplate restTemplate,
                     @Value("${weather.url}") final String weatherServiceUrl,
                     @Value("${weather.api_key}") final String weatherServiceApiKey) {
    this.restTemplate = restTemplate;
    this.weatherServiceUrl = weatherServiceUrl;
    this.weatherServiceApiKey = weatherServiceApiKey;
}

通过这种方式，我们告诉 WeatherClient 从我们在应用程序属性中定义的 weather.url 属性中读取 weatherUrl 参数的值。

使用 Wiremock 等工具为单独的服务编写窄集成测试非常容易。不幸的是，这种方法有一个缺点：我们如何确保我们设置的伪造服务器的行为与真正的服务器一样？使用当前实现，单独的服务可以更改其 API，而我们的测试仍然会通过。现在，我们只是在测试我们的 WeatherClient 是否可以解析伪造服务器发送的响应。这是一个开始，但它非常脆弱。使用端到端测试并针对真正的服务的测试实例运行测试，而不是使用伪造的服务，将解决此问题，但会使我们依赖于测试服务的可用性。幸运的是，对于这个难题，有一个更好的解决方案：针对伪造的和真正的服务器运行契约测试，以确保我们在集成测试中使用的伪造是忠实的测试替身。让我们看看接下来如何进行。

消费者测试（我们的团队）

我们的微服务使用天气 API。因此，我们有责任编写一个消费者测试，该测试定义了我们对微服务和天气服务之间的契约（API）的期望。

首先，我们在 build.gradle 中包含一个用于编写 pact 消费者测试的库

testCompile('au.com.dius:pact-jvm-consumer-junit_2.11:3.5.5')

借助此库，我们可以实现消费者测试并使用 pact 的模拟服务

@RunWith(SpringRunner.class)
@SpringBootTest
public class WeatherClientConsumerTest {

    @Autowired
    private WeatherClient weatherClient;

    @Rule
    public PactProviderRuleMk2 weatherProvider =
            new PactProviderRuleMk2("weather_provider", "localhost", 8089, this);

    @Pact(consumer="test_consumer")
    public RequestResponsePact createPact(PactDslWithProvider builder) throws IOException {
        return builder
                .given("weather forecast data")
                .uponReceiving("a request for a weather request for Hamburg")
                    .path("/some-test-api-key/53.5511,9.9937")
                    .method("GET")
                .willRespondWith()
                    .status(200)
                    .body(FileLoader.read("classpath:weatherApiResponse.json"),
                            ContentType.APPLICATION_JSON)
                .toPact();
    }

    @Test
    @PactVerification("weather_provider")
    public void shouldFetchWeatherInformation() throws Exception {
        Optional<WeatherResponse> weatherResponse = weatherClient.fetchWeather();
        assertThat(weatherResponse.isPresent(), is(true));
        assertThat(weatherResponse.get().getSummary(), is("Rain"));
    }
}

如果您仔细观察，您会看到 WeatherClientConsumerTest 与 WeatherClientIntegrationTest 非常相似。这次我们使用 Pact，而不是使用 Wiremock 作为服务器存根。事实上，消费者测试的工作方式与集成测试完全相同，我们将真实的第三方服务器替换为存根，定义预期的响应，并检查我们的客户端是否可以正确解析响应。从这个意义上说，WeatherClientConsumerTest 本身就是一个狭义的集成测试。与基于 Wiremock 的测试相比，此测试的优点在于每次运行时都会生成一个pact 文件（位于 target/pacts/&pact-name>.json 中）。此 pact 文件以一种特殊的 JSON 格式描述了我们对契约的期望。然后可以使用此 pact 文件来验证我们的存根服务器是否像真实服务器一样运行。我们可以获取 pact 文件并将其交给提供接口的团队。他们获取此 pact 文件并使用其中定义的期望编写提供者测试。通过这种方式，他们测试他们的 API 是否满足我们的所有期望。

您会看到，这就是 CDC 的消费者驱动部分的来源。消费者通过描述他们的期望来驱动接口的实现。提供者必须确保他们满足所有期望，并且他们已经完成。没有镀金，没有 YAGNI 等。

有多种方法可以将 pact 文件传送到提供团队。一种简单的方法是将它们检入版本控制，并告诉提供者团队始终获取 pact 文件的最新版本。更高级的方法是使用工件存储库、Amazon 的 S3 或 pact 代理等服务。从简单开始，根据需要逐渐增加。

在您的实际应用程序中，您不需要为客户端类同时使用集成测试和消费者测试。示例代码库包含两者，以向您展示如何使用其中任何一种。如果您想使用 pact 编写 CDC 测试，我建议坚持使用后者。编写测试的精力是相同的。使用 pact 的好处是您可以自动获得一个 pact 文件，其中包含对契约的期望，其他团队可以使用该文件轻松地实现其提供者测试。当然，只有当您说服其他团队也使用 pact 时，这才有意义。如果这不起作用，使用集成测试和 Wiremock 组合是一个不错的备用方案。

提供者测试（其他团队）

提供程序测试必须由提供天气 API 的人员来实现。我们正在使用 darksky.net 提供的公共 API。从理论上讲，darksky 团队会在其端实现提供程序测试，以检查他们是否破坏了其应用程序与我们服务之间的契约。

显然，他们不在乎我们微不足道的示例应用程序，也不会为我们实现 CDC 测试。这是面向公众的 API 与采用微服务的组织之间的巨大差异。面向公众的 API 无法考虑那里的每一个消费者，否则它们将无法继续前进。在您自己的组织内，您可以（并且应该）这样做。您的应用程序很可能只为少数消费者服务，最多可能只有几十个消费者。为了保持系统稳定，您可以为这些接口编写提供程序测试。

提供团队获取契约文件，并针对其提供服务运行该文件。为此，他们实现了一个提供程序测试，该测试读取契约文件，截断一些测试数据，并针对其服务运行契约文件中定义的期望。

契约人员已经编写了多个库来实现提供程序测试。他们的主要 GitHub 存储库 为您提供了很好的概述，介绍了哪些消费者和哪些提供程序库可用。选择最适合您的技术堆栈的那个。

为了简单起见，我们假设 darksky API 也在 Spring Boot 中实现。在这种情况下，他们可以使用 Spring 契约提供程序，该提供程序很好地连接到了 Spring 的 MockMVC 机制。darksky.net 团队将实现的假设提供程序测试可能如下所示

@RunWith(RestPactRunner.class)
@Provider("weather_provider") // same as the "provider_name" in our clientConsumerTest
@PactFolder("target/pacts") // tells pact where to load the pact files from
public class WeatherProviderTest {
    @InjectMocks
    private ForecastController forecastController = new ForecastController();

    @Mock
    private ForecastService forecastService;

    @TestTarget
    public final MockMvcTarget target = new MockMvcTarget();

    @Before
    public void before() {
        initMocks(this);
        target.setControllers(forecastController);
    }

    @State("weather forecast data") // same as the "given()" in our clientConsumerTest
    public void weatherForecastData() {
        when(forecastService.fetchForecastFor(any(String.class), any(String.class)))
                .thenReturn(weatherForecast("Rain"));
    }
}

您会看到，提供程序测试所要做的就是加载契约文件（例如，通过使用 @PactFolder 注解来加载以前下载的契约文件），然后定义如何提供预定义状态的测试数据（例如，使用 Mockito 模拟）。没有要实现的自定义测试。这些全部都源自契约文件。重要的是，提供程序测试具有与消费者测试中声明的提供程序名称和状态相匹配的对应项。

提供者测试（我们的团队）

我们已经了解了如何测试我们的服务与天气提供程序之间的契约。通过此界面，我们的服务充当消费者，天气服务充当提供程序。再深入思考一下，我们会看到我们的服务也充当其他人的提供程序：我们提供了一个 REST API，该 API 提供了一些端点，供其他人使用。

正如我们刚刚了解到的，契约测试非常流行，因此我们当然也为该契约编写契约测试。幸运的是，我们正在使用消费者驱动的契约，因此所有消费团队都会向我们发送其契约，我们可以使用这些契约来为我们的 REST API 实现提供程序测试。

让我们首先将 Spring 的契约提供程序库添加到我们的项目中

testCompile('au.com.dius:pact-jvm-provider-spring_2.12:3.5.5')

实现提供者测试遵循之前描述的相同模式。为了简单起见，我只需将我们的 简单消费者 中的契约文件检入到我们的服务存储库中。对于我们的目的而言，这更容易，在实际场景中，你可能会使用更复杂的机制来分发你的契约文件。

@RunWith(RestPactRunner.class)
@Provider("person_provider")// same as in the "provider_name" part in our pact file
@PactFolder("target/pacts") // tells pact where to load the pact files from
public class ExampleProviderTest {

    @Mock
    private PersonRepository personRepository;

    @Mock
    private WeatherClient weatherClient;

    private ExampleController exampleController;

    @TestTarget
    public final MockMvcTarget target = new MockMvcTarget();

    @Before
    public void before() {
        initMocks(this);
        exampleController = new ExampleController(personRepository, weatherClient);
        target.setControllers(exampleController);
    }

    @State("person data") // same as the "given()" part in our consumer test
    public void personData() {
        Person peterPan = new Person("Peter", "Pan");
        when(personRepository.findByLastName("Pan")).thenReturn(Optional.of
                (peterPan));
    }
}

所示的 ExampleProviderTest 需要根据给定的契约文件提供状态，就是这样。一旦我们运行提供者测试，Pact 将选取契约文件并针对我们的服务发出 HTTP 请求，然后根据我们设置的状态做出响应。

用户界面端到端测试

对于端到端测试，Selenium 和 WebDriver 协议是许多开发人员的首选工具。使用 Selenium，您可以选择自己喜欢的浏览器，并让它自动调用您的网站，单击此处和那里，输入数据并检查用户界面中的内容是否发生变化。

Selenium 需要一个浏览器，它可以启动该浏览器并使用该浏览器来运行其测试。有多个所谓的“驱动程序”可用于不同的浏览器。选择一个（或多个）并将其添加到您的 build.gradle 中。无论您选择哪种浏览器，您都需要确保团队中的所有开发人员和您的 CI 服务器已在本地安装了正确版本的浏览器。保持同步可能非常痛苦。对于 Java，有一个名为 webdrivermanager 的不错的小型库，它可以自动下载并设置您想要使用的浏览器的正确版本。将这两个依赖项添加到您的 build.gradle 中，您就可以开始了

testCompile('org.seleniumhq.selenium:selenium-chrome-driver:2.53.1')
testCompile('io.github.bonigarcia:webdrivermanager:1.7.2')

在您的测试套件中运行一个功能齐全的浏览器可能很麻烦。特别是当使用持续交付时，运行您的管道的服务器可能无法启动包括用户界面在内的浏览器（例如，因为没有可用的 X 服务器）。您可以通过启动虚拟 X 服务器（如 xvfb）来解决此问题。

一种更新的方法是使用无头浏览器（即没有用户界面的浏览器）来运行您的 webdriver 测试。直到最近，PhantomJS 都是用于浏览器自动化的领先无头浏览器。自 Chromium 和 Firefox 宣布已在其浏览器中实施无头模式以来，PhantomJS 突然变得过时。毕竟，最好使用用户实际使用的浏览器（如 Firefox 和 Chrome）来测试您的网站，而不是仅仅因为对您作为开发人员来说很方便而使用人工浏览器。

无头 Firefox 和 Chrome 都是全新的，尚未被广泛采用来实现 webdriver 测试。我们希望保持简单。不要忙于使用前沿无头模式，让我们坚持使用 Selenium 和常规浏览器的经典方式。一个简单的端到端测试，它启动 Chrome，导航到我们的服务并检查网站的内容如下所示

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class HelloE2ESeleniumTest {

    private WebDriver driver;

    @LocalServerPort
    private int port;

    @BeforeClass
    public static void setUpClass() throws Exception {
        ChromeDriverManager.getInstance().setup();
    }

    @Before
    public void setUp() throws Exception {
        driver = new ChromeDriver();
    }

    @After
    public void tearDown() {
        driver.close();
    }

    @Test
    public void helloPageHasTextHelloWorld() {
        driver.get(String.format("http://127.0.0.1:%s/hello", port));

        assertThat(driver.findElement(By.tagName("body")).getText(), containsString("Hello World!"));
    }
}

请注意，此测试仅在您在运行此测试的系统（您的本地计算机、您的 CI 服务器）上安装了 Chrome 时才会在您的系统上运行。

测试很简单。它使用 @SpringBootTest 在随机端口上启动整个 Spring 应用程序。然后，我们实例化一个新的 Chrome webdriver，告诉它导航到我们微服务的 /hello 端点，并检查它在浏览器窗口上打印“Hello World!”。很酷的东西！

REST API 端到端测试

在测试应用程序时避免使用图形用户界面可能是提出一些想法的好办法，这些想法比完全端到端测试更少出错，同时仍然涵盖应用程序堆栈的广泛部分。当通过应用程序的 Web 界面进行测试特别困难时，这会派上用场。也许你甚至没有 Web UI，而是提供 REST API（因为你在某个地方有一个与该 API 通信的单页面应用程序，或者仅仅是因为你鄙视所有漂亮的东西）。无论哪种方式，一个皮下测试仅在图形用户界面下方进行测试，并且可以在不影响信心的情况下让你走得很远。如果你像我们在示例代码中那样提供 REST API，那就刚刚好

@RestController
public class ExampleController {
    private final PersonRepository personRepository;

    // shortened for clarity

    @GetMapping("/hello/{lastName}")
    public String hello(@PathVariable final String lastName) {
        Optional<Person> foundPerson = personRepository.findByLastName(lastName);

        return foundPerson
             .map(person -> String.format("Hello %s %s!",
                     person.getFirstName(),
                     person.getLastName()))
             .orElse(String.format("Who is this '%s' you're talking about?",
                     lastName));
    }
}

让我向你展示另一个在测试提供 REST API 的服务时派上用场的库。REST-assured是一个库，它为你提供了一个不错的 DSL，用于向 API 发出真正的 HTTP 请求并评估你收到的响应。

首先：将依赖项添加到你的 build.gradle。

testCompile('io.rest-assured:rest-assured:3.0.3')

有了这个库，我们可以为我们的 REST API 实现一个端到端测试

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class HelloE2ERestTest {

    @Autowired
    private PersonRepository personRepository;

    @LocalServerPort
    private int port;

    @After
    public void tearDown() throws Exception {
        personRepository.deleteAll();
    }

    @Test
    public void shouldReturnGreeting() throws Exception {
        Person peter = new Person("Peter", "Pan");
        personRepository.save(peter);

        when()
                .get(String.format("https://127.0.0.1:%s/hello/Pan", port))
        .then()
                .statusCode(is(200))
                .body(containsString("Hello Peter Pan!"));
    }
}

同样，我们使用 @SpringBootTest 启动整个 Spring 应用程序。在这种情况下，我们 @Autowire 的 PersonRepository，以便我们可以轻松地将测试数据写入我们的数据库。当我们现在要求 REST API 向我们的朋友“Mr Pan”问候时，我们会收到一个友好的问候。太棒了！如果你甚至没有一个 Web 界面，那么这已经足够作为一个端到端测试了。