跳到主要内容

为什么选择 HtmlUnit 集成？

DeepSeek V3 中英对照 Why HtmlUnit Integration?

最显而易见的问题是：“为什么我需要这个？”通过探索一个非常基础的示例应用程序，可以找到最好的答案。假设你有一个支持对 Message 对象进行 CRUD 操作的 Spring MVC Web 应用程序。该应用程序还支持对所有消息进行分页浏览。你会如何进行测试呢？

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

MockHttpServletRequestBuilder createMessage = post("/messages/")
        .param("summary", "Spring Rocks")
        .param("text", "In case you didn't know, Spring Rocks!");

mockMvc.perform(createMessage)
        .andExpect(status().is3xxRedirection())
        .andExpect(redirectedUrl("/messages/123"));
java

如果我们想要测试允许我们创建消息的表单视图，该怎么办？例如，假设我们的表单如下所示：

<form id="messageForm" action="/messages/" method="post">
    <div class="pull-right"><a href="/messages/">Messages</a></div>

    <label for="summary">Summary</label>
    <input type="text" class="required" id="summary" name="summary" value="" />

    <label for="text">Message</label>
    <textarea id="text" name="text"></textarea>

    <div class="form-actions">
        <input type="submit" value="Create" />
    </div>
</form>
xml

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

mockMvc.perform(get("/messages/form"))
        .andExpect(xpath("//input[@name='summary']").exists())
        .andExpect(xpath("//textarea[@name='text']").exists());
java

这个测试有一些明显的缺点。如果我们更新控制器以使用参数 message 而不是 text，我们的表单测试仍然会通过，尽管 HTML 表单与控制器不同步。为了解决这个问题，我们可以将两个测试结合起来，如下所示：

String summaryParamName = "summary";
String textParamName = "text";
mockMvc.perform(get("/messages/form"))
        .andExpect(xpath("//input[@name='" + summaryParamName + "']").exists())
        .andExpect(xpath("//textarea[@name='" + textParamName + "']").exists());

MockHttpServletRequestBuilder createMessage = post("/messages/")
        .param(summaryParamName, "Spring Rocks")
        .param(textParamName, "In case you didn't know, Spring Rocks!");

mockMvc.perform(createMessage)
        .andExpect(status().is3xxRedirection())
        .andExpect(redirectedUrl("/messages/123"));
java

这将降低我们的测试错误通过的风险，但仍然存在一些问题：

  • 如果我们的页面上有多个表单怎么办？诚然，我们可以更新我们的 XPath 表达式，但随着我们考虑更多因素，它们会变得更加复杂：字段类型是否正确？字段是否启用？等等。

  • 另一个问题是我们做了双倍的工作。我们必须首先验证视图，然后使用我们刚刚验证的相同参数提交视图。理想情况下，这可以一次性完成。

  • 最后，我们仍然无法处理某些情况。例如，如果表单有我们想要测试的 JavaScript 验证怎么办？

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

集成测试来拯救？​

为了解决前面提到的问题，我们可以进行端到端的集成测试，但这也有一些缺点。考虑测试允许我们分页浏览消息的视图。我们可能需要以下测试：

  • 当消息为空时，我们的页面是否显示通知以告知用户没有可用的结果？

  • 我们的页面是否正确显示单条消息？

  • 我们的页面是否正确支持分页？

为了设置这些测试，我们需要确保我们的数据库包含正确的消息。这带来了许多额外的挑战：

  • 确保数据库中有正确的信息可能会很繁琐。（考虑外键约束。）

  • 测试可能会变得很慢，因为每个测试都需要确保数据库处于正确的状态。

  • 由于我们的数据库需要处于特定状态，因此无法并行运行测试。

  • 对自动生成的 ID、时间戳等项目进行断言可能会很困难。

这些挑战并不意味着我们应该完全放弃端到端集成测试。相反，我们可以通过重构我们的详细测试来减少端到端集成测试的数量，使用运行速度更快、更可靠且没有副作用的模拟服务。然后，我们可以实现少量的真正端到端集成测试，以验证简单的工作流程，确保所有部分都能正常协同工作。

进入 HtmlUnit 集成​

那么，我们如何在测试页面交互的同时，仍然保持测试套件的良好性能呢？答案是：“通过将 MockMvc 与 HtmlUnit 集成。”

HtmlUnit 集成选项​

当你想将 MockMvc 与 HtmlUnit 集成时，你有多种选择：

  • MockMvc 和 HtmlUnit: 如果你想使用原生的 HtmlUnit 库，请选择此选项。

  • MockMvc 和 WebDriver: 选择此选项可以简化开发并在集成测试和端到端测试之间重用代码。

  • MockMvc 和 Geb: 如果你想使用 Groovy 进行测试、简化开发并在集成测试和端到端测试之间重用代码，请选择此选项。