tdd - 端到端测试整个系统的最佳实践

Question

端到端测试意味着从外部边界运行应用程序以验证其行为。到目前为止，我只对单个可执行工件进行了书面测试。我应该如何测试由部署在不同主机上的多个工件组成的系统？

我看到两种选择。

• 测试建立了整个系统并从最外层边缘进行测试。
• 每个工件都经过端到端隔离测试，依靠测试内容来强制执行它们之间的协议(protocol)。

是否有明确的理由只遵循其中一项，或者优先选择其中一项，还是可以互换？如果可以互换，那么它们之间有哪些优缺点？

Answer 1

尽管我认为这取决于上下文，但我更喜欢第一种选择。以下是我的随意想法:

我希望我的测试尽可能紧密地映射到用例(BDD 风格)(并声明我滥用了术语用例)。这些用例可能跨越多个应用程序和子系统。

示例:后台管理员可以通过公共(public)界面查看用户进行的交易。

这里，后台管理界面和公共(public)界面是不同的应用程序，但它们包含在同一用例中。

将这些想法映射到您在不同主机上部署子系统的问题，我想说这取决于从用户/参与者的角度来看它的使用方式。用例是否跨越多个子系统？

此外，也许系统部署在多个主机上这一事实对于测试来说并不重要。您可以在测试中用方法调用替换进程间通信，并在测试期间将整个系统置于同一进程中，从而降低复杂性。通过仅验证进程间通信的测试来补充这一点。

编辑:

我意识到我忘记了为什么我更喜欢测试整个系统。

你的 Assets 是特性，即行为，而代码是一种负债。因此，您希望测试行为，而不是代码(BDD 风格)。

如果您单独测试每个子系统，那么您正在测试代码，而不是功能。为什么？当您将系统划分为子系统时，您是基于一些技术原因这样做的。当您了解更多信息时，您可能会发现所选接缝不是最佳的，并且希望将一些责任从一个子系统转移到另一个子系统。而且您必须同时修改测试和生产代码，这让您没有安全网。这是测试实现细节的典型症状。

也就是说，此类测试过于生硬，无法测试所有内容。因此，必要时您还需要对细节进行补充测试。