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

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

我看到两种选择.

>测试设置整个系统并从外边缘进行锻炼.
>每个工件都是单独进行端到端测试,依靠测试内容来强制执行它们之间的协议.

有没有明确的案例只是坚持其中一个,或者是其中一个首选,还是可以互换?如果可以互换,那么它们之间有什么优缺点?

最佳答案 虽然我认为这取决于背景,但我更喜欢第一种选择.这是我的随意想法:

我喜欢我的测试尽可能紧密地映射到用例(BDD风格)(免责声明我滥用术语用例).这些用例可能跨越多个应用程序和子系统.

示例:后台管理员可以从公共界面查看用户进行的事务.

这里,后台管理界面和公共界面是不同的应用程序,但它们包含在相同的用例中.

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

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

编辑:

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

您的资产是功能,即行为,而代码是负债.因此,您希望测试行为,而不是代码(BDD样式).

如果您分别测试每个子系统,则表示您正在测试代码,而不是功能.为什么?当您将系统划分为子系统时,基于某些技术原因这样做.当您了解更多信息时,您可能会发现所选择的接缝处于次优状态,并希望将一些责任从一个子系统转移到另一个子系统.而且你必须同时修改测试和生产代码,让你没有安全网.这是测试实现细节的典型症状.

也就是说,这些测试太过生硬,无法测试一切.因此,您需要在必要时对细节进行补充测试.

点赞