端到端测试意味着从外部边界运行应用程序以验证其行为。到目前为止，我只对单个可执行工件进行了书面测试。我应该如何测试由部署在不同主机上的多个工件组成的系统？
我看到了两种选择。
是否有明确的理由只遵守其中之一，或者是首选其中之一，还是可以互换？如果可以互换，那么它们之间有哪些优缺点？
【问题讨论】：
标签： tdd end-to-end
尽管我认为这取决于上下文，但我更喜欢第一种选择。以下是我的随机想法：
我希望我的测试尽可能紧密地映射到用例（BDD 风格）（声明我误用了用例这个术语）。这些用例可能跨越多个应用程序和子系统。
示例：后台管理员可以从公共界面查看用户进行的交易。
这里，后台管理界面和公共界面是不同的应用程序，但它们包含在同一个用例中。
将这些想法映射到您在不同主机上部署子系统的问题，我想说这取决于从用户/参与者的角度来看它的使用方式。用例是否跨越多个子系统？
此外，系统部署在多台主机上这一事实可能对测试并不重要。您可以在测试中将进程间通信替换为方法调用，并在测试期间将整个系统置于同一进程中，从而降低复杂性。用仅验证进程间通信的测试来补充这一点。
编辑：
我意识到我忘了包括为什么我更喜欢测试整个系统。
您的资产是特征，即行为，而代码是负债。因此，您想测试行为，而不是代码（BDD 样式）。
如果您分别测试每个子系统，您测试的是代码，而不是功能。为什么？当您将系统划分为子系统时，您这样做是基于一些技术原因。当您了解更多时，您可能会发现所选接缝不是最佳的，并且希望将一些责任从一个子系统转移到另一个子系统。而且你必须同时修改测试和生产代码，这样你就没有安全网了。这是测试实现细节的典型症状。
也就是说，这类测试太生硬，无法测试所有内容。因此，如有必要，您还需要对细节进行补充测试。
【讨论】：
在任何情况下都非常需要单独测试每个工件的端到端。这将确保每个工件都是健全的。
此外，您可能想要测试工件的组合。这将在工件之间的交互中发现问题。我不知道您的情况，但是拥有一个作为生产副本的测试环境很重要。在测试环境中测试系统是一个非常好的主意。您可能还想在生产环境中测试系统；这可能可行或不可行。例如，如果您的系统处理信用卡付款，您可能希望避免在生产系统上进行测试付款。
无论如何，单独测试每个系统比测试组合更重要。一旦你知道你的工件是孤立的，捕捉交互测试就会容易得多。如果你只有整个系统的端到端测试，那么当测试失败时，你很难理解错误在哪里。
【讨论】：