在单元测试中使用随机值有哪些缺点？

Question

我想知道在一些单元测试中使用随机值的缺点是什么.

---

我说的是一个大型系统,有许多服务器和高容量的非确定性输入.当我说非确定性时,我正在谈论发送的消息,你抓住你能做到的,尽你所能.有许多类型的消息,因此输入可能非常复杂.我无法想象为这么多场景编写代码,而简单的非随机(确定性)消息的生成器也不够好.这就是为什么我想要进行随机单元测试或服务器测试,以便在出现故障时写入日志.我更喜欢unittest而不是随机注射器,因为我希望它作为夜间构建自动化测试的一部分运行.

Answer 1

缺点

首先,它使测试更加复杂并且稍微难以调试,因为您无法直接看到所有输入的值(尽管总是可以选择生成测试用例作为代码或数据).如果你正在做一些半复杂的逻辑来生成你的随机测试数据,那么这个代码也有可能存在错误.测试代码中的错误可能很痛苦,特别是如果开发人员立即认为错误是生产代码.

其次,通常不可能对预期答案具体说明.如果你根据输入得知答案,那么你就有可能只是在试验中的逻辑(考虑一下 - 如果输入是随机的,你怎么知道预期的输出？)结果,你可能必须交换非常具体的断言(值应该是x)以获得更一般的完整性检查断言(值应该在y和z之间).

第三,除非有广泛的输入和输出,否则通常可以在标准单元测试中使用精心选择的值覆盖相同的范围,而复杂性较低.例如,选择数字-max,( - max + 1), - 2,-1,0,1,2,max-1,max.(或算法的任何有趣内容).

上升空间

如果使用正确的目标,这些测试可以提供非常有价值的补充测试通过.我已经看到了相当多的代码,当被随机生成的测试输入锤击时,由于不可预见的边缘情况而扭曲.我有时会添加一个额外的集成测试过程,它会生成一堆测试用例.

额外的技巧

如果您的某个随机测试失败,请隔离"有趣"值并将其升级为独立单元测试,以确保您可以修复该错误,并且在签入之前永远不会回退.

Answer 2

它们是随机的.

(即使您的代码被破坏,您的测试也可能随机工作.)

Answer 3

此外,您将无法多次重现测试.单元测试应该与给定参数完全相同.

Answer 4

随机化单元测试就是用螺丝刀敲钉子。问题不在于螺丝刀坏了；问题是您在工作中使用了错误的工具。单元测试的重点是在您破坏某些东西时提供即时反馈，以便您可以立即修复它。

假设您提交了一项更改，我们将其称为 BadChange。BadChange 引入了一个错误，您的随机测试有时会发现有时不会。这一次，测试没有发现它。BadChange 被清除并进入代码库。

后来，有人提交了另一个更改 GoodChange。GoodChange 百分百没问题。但这一次，您的随机测试捕获了 BadChange 引入的错误。现在 GoodChange 被标记为一个问题，编写它的开发人员将绕圈子试图找出为什么这个无害的变化会导致问题。

随机测试对于不断探索整个应用程序的问题很有用，而不是验证单个更改。它应该存在于一个单独的套件中，并且运行不应与代码更改相关联；即使没有人进行更改，随机测试仍有可能偶然发现以前运行时遗漏的一些奇特错误。