[微服务下的测试第三季] 新系统测试的策略

新的测试使用REST访问所有的服务，这是比Java RMI更灵活和更通用的远程调用方式。 每个测试用例还会监听在处理测试请求时在各种微服务之间发送的所有消息。 这使我们能够在运行时跟踪测试的进度，如果测试失败，可以更轻松地找出错误发生的位置。 这也意味着测试可以对系统中的事件作出反应，并触发特殊的工作流程。

这些决定在某种程度上是非常明显的，测试应该与微服务语言相同。 通过这样做，测试自然而然地运行得更快，并且更容易调试。 我觉得我们可以做更多来减轻维护负担。 为此，我们决定他们也将是数据驱动的，并使用审批测试。

“新的测试使用REST访问所有的服务，这是一种比Java RMI更灵活和更普遍的远程调用方式。”

数据驱动测试

数据驱动的测试意味着您通常保持工作流程相同，但不同情况下的数据会有所不同。 这样可以最大限度地减少每个测试用例的新代码数量，因为大部分时间足以改变输入数据以便执行新的或更新的功能。 在Pagero Online的情况下，最重要的用例是将发行者的文件发送给收件人。 所以这就是我们几乎所有的测试都会使用的用例。

在这个基本的前提下，一个测试包括一个发行者，一个收件人，以及在他们之间发送的一个文件，还有一些你需要覆盖的变化。 如果你看看我们的测试案例，基本上所有这些都是基于这三个要素的。

我们在结构化文本文件中定义它们，与执行用例的夹具代码分开。 夹具代码解析文本文件，使REST调用在系统中创建相应的发行者和收件人，然后代表发行者向PageRed在线请求发送文档给收件人。

定义一个新的测试用例通常只是为这三个实体定义一个不同的配置。 只有当你需要在这个基本的用例上有一个重要的变化时，你才需要写入任何新的测试夹具代码。

批准测试

批准测试是指您确定测试是否通过的方式。 您可能已经熟悉了基于断言的测试，您必须通过对所需输出进行断言来决定每个测试用例的正确行为。 在批准测试中，您将当前输出与之前测试运行中收集的“批准”版本的输出进行比较。 实际输出和批准版本之间的任何差异都被标记为失败。

因此，在Pagero Online中，我们存储了提交给收件人的文档的批准版本。 我们还存储了正在处理文档时在服务之间传递的消息列表的批准版本以及与其相关的任何错误日志。 通过检查Pagero Online的所有不同类型的输出，我们可以确信文档处理正确。

这种方法有几个优点，特别是与数据驱动的测试一起使用时。 您大多不必编写特定于某个测试用例的断言代码，从而进一步减少了测试代码的数量。 更重要的是，因为每个测试实际上都会检查很多东西，所以当你编写测试时，最终会发现你没有预料到的错误。 例如，发现一个不应该被发送的附加消息，或者在文档演示文稿的第三页上发现格式错误。