为什么需要HtmlUnit集成？

最明显的问题是“我为什么需要这个？”最好的答案是通过探索一个非常基本的示例应用程序找到的。假设您有一个支持在Message对象上进行CRUD操作的Spring MVC Web应用程序。该应用程序还支持浏览所有消息的分页。您将如何测试它？

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

  • Java

  • Kotlin

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"));
@Test
fun test() {
	mockMvc.post("/messages/") {
		param("summary", "Spring Rocks")
		param("text", "In case you didn't know, Spring Rocks!")
	}.andExpect {
		status().is3xxRedirection()
		redirectedUrl("/messages/123")
	}
}

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

<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>

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

  • Java

  • Kotlin

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

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

  • Java

  • Kotlin

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"));
val summaryParamName = "summary";
val textParamName = "text";
mockMvc.get("/messages/form").andExpect {
	xpath("//input[@name='$summaryParamName']") { exists() }
	xpath("//textarea[@name='$textParamName']") { exists() }
}
mockMvc.post("/messages/") {
	param(summaryParamName, "Spring Rocks")
	param(textParamName, "In case you didn't know, Spring Rocks!")
}.andExpect {
	status().is3xxRedirection()
	redirectedUrl("/messages/123")
}

这样可以减少测试错误通过的风险，但仍然存在一些问题：

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

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

  • 最后，我们仍然无法解决一些问题。例如，如果表单具有我们希望测试的JavaScript验证，该怎么办？

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

集成测试来拯救？

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

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

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

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

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

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

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

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

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

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

HtmlUnit集成

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

HtmlUnit集成选项

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

  • MockMvc和HtmlUnit：如果您想使用原始HtmlUnit库，请使用此选项。

  • MockMvc和WebDriver：如果您想要简化开发并在集成测试和端到端测试之间重用代码，请使用此选项。

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