单元测试一种具有随机行为的方法

单元测试每次运行时都应该做同样的事情,否则您可能会遇到这样的情况:单元测试偶尔会失败,这可能是调试的真正痛苦。

尝试每次都用相同的种子(在测试中,也就是——不是在生产代码中)为伪随机数生成器播种。这样,您的测试每次都会生成相同的输入集。

如果你不能控制种子,并且没有办法阻止你正在测试的功能被随机分配,那么我猜你会陷入一个不可预知的单元测试中。:。(

该函数是一个假设,即对于所有输入,输出都符合规范。单元测试是一种试图推翻这一假设的尝试。所以是的,在这种情况下,您所能做的最好的就是生成大量的输出。如果它们都通过了您的规范,那么您可以合理地确保您的函数按照指定的方式工作。

考虑将随机数生成器置于此函数之外并向其传递随机数,使函数具有确定性,而不是让它直接访问随机数生成器。通过这种方式,您可以在测试工具中生成大量随机输入,将它们全部传递给您的函数,并测试输出。如果一个失败了,那么记录这个值是什么,这样您就有了一个文档化的测试用例。

除了测试一些以确保它们通过,我还编写了一个测试来确保密码 打破 规则失败了。

代码库中有没有什么东西在检查生成的密码以确保它们足够随机?如果没有,我可能会考虑创建逻辑来检查生成的密码,测试它,然后您可以声明随机密码生成器正在工作(作为“坏”的密码生成器不会退出)。

一旦你有了这个逻辑,你就可以编写一个集成类型测试,它将生成大量的密码,并通过逻辑传递给你,这时你就会知道你的随机密码生成有多好。

嗯,考虑到它们是随机的,没有真正的方法来确定,但是对100000密码的测试应该可以消除大多数疑问:)

您可以在随机数生成器中植入一个常量值,以便获得非随机结果并测试这些结果。

我假设用户输入的密码与随机生成的密码符合相同的限制。所以您可能想要一组静态密码来检查已知的条件,然后您将得到一个循环来执行动态密码检查。循环的大小并不太重要,但是它应该足够大,可以让您从生成器中获得温暖的模糊感,但不能太大,以至于您的测试需要永远运行。如果随着时间的推移出现任何问题,您可以将这些案例添加到静态列表中。

不过,从长远来看,弱密码不会破坏您的程序,而密码安全则掌握在用户手中。因此,您的首要任务是确保动态生成和强度检查不会破坏系统。

不知道你的规则是什么,很难确定,但假设它们是类似“密码必须至少有8个字符,其中至少有一个大写字母、一个小写字母、一个数字和一个特殊字符”,那么即使使用蛮力也不可能检查足够数量的生成密码来证明这一点。算法是正确的(因为这需要超过8^70=1.63x10^63的检查,这取决于您指定要使用的特殊字符的数量,这需要很长的时间才能完成)。

最终,你所能做的就是尽可能多地测试密码,如果有违反规则的话,你就会知道算法是不正确的。也许最好的办法是让它在一夜之间运行,如果早上一切都好的话,你可能会没事的。

如果您想在生产环境中加倍确定,那么实现一个外部函数,该函数在循环中调用密码生成函数,并根据规则对其进行检查。如果失败,那么记录一个错误,指出这一点(这样您就知道需要修复它),并生成另一个密码。继续,直到你得到一个符合规则的。

你也可以研究突变测试( Jester 对于Java, Heckle 红宝石)

在我看来,你不想做一个有时通过,有时失败的测试。有些人甚至会认为这种测试不是单元测试。但主要的想法是,当你看到绿色条时,确保函数是正常的。

考虑到这一原则,您可以尝试执行合理的次数,以便获得错误更正的机会几乎是CERO。然而,测试的一次失败将迫使您进行更广泛的测试,除了排除失败之外。

要么使用固定的随机种子,要么使其具有可复制性(即:从当天派生)

首先,用种子进行催产。您的输入不再是随机的,并且摆脱了不可预知输出的问题——也就是说,现在您的单元测试是确定性的。

然而,这并不能解决测试实现的问题,但这里有一个例子,说明如何测试依赖随机性的典型方法。

假设我们已经实现了一个函数,该函数取一组红色和蓝色大理石,随机选取一个,但是可以为概率分配一个权重,即2和1的权重意味着红色大理石被选取的可能性是蓝色大理石的两倍。

我们可以通过将一个选项的权重设置为零并验证在所有情况下(实际上,对于大量的测试输入),我们 总是 获取例如蓝色大理石。然后倒转重量会得到相反的结果(所有的红色弹珠)。

这并不能保证我们的功能按预期运行(如果我们通过相同数量的红色和蓝色大理石,并且具有相同的重量,我们在大量试验中总是得到50/50的分布吗?)但实际上,这通常是足够的。