unit-testing - 在单元测试中使用随机值有什么缺点？

Question

我说的是一个大型系统，具有许多服务器和高容量的非确定性输入。当我说非确定性时，我指的是已发送的消息，您可以捕获并尽力而为。
消息的类型很多，因此输入可能非常复杂。
我无法想象为这么多场景编写代码，而一个简单的非随机(确定性)消息生成器还不够好。

这就是为什么我想要一个随机的单元测试或服务器测试，在失败的情况下可以写一个日志。

而且我更喜欢 unittest 而不是随机注入(inject)器，因为我希望它作为夜间构建自动化测试的一部分运行。

有什么缺点吗？

Answer 1

随机化单元测试是用 Screwdriver 敲钉子。问题不在于 Screwdriver 不好；问题是你使用了错误的工具来完成这项工作。单元测试的目的是在你破坏某些东西时提供即时反馈，这样你就可以在那里修复它。

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

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

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