含随机性实验函数的Unittest策略及实现疑问

1. 能不能用运行时长替代验证循环执行次数？ #

绝对不行。运行时长受环境影响极大——CPU负载、后台进程、系统资源分配都会大幅改变执行耗时，哪怕是同一台机器，两次相同操作的耗时都可能差好几倍。用时长来判断循环次数完全不可靠，根本无法保证测试的准确性。

2. 设置随机种子是唯一方案吗？ #

不是。还有不少更可靠的替代方法：

• 注入mock依赖：把函数里生成随机数据或判断结果有效性的逻辑抽成可替换的参数。测试时传入一个总是返回无效结果的mock实现，同时在mock里加调用计数器。执行函数后，只要检查计数器值等于MAX_TRIES就行。
• 猴子补丁替换内部逻辑：测试时临时替换函数内部使用的随机生成器或有效性判断函数，让每次尝试都必然失败，同时统计调用次数。比如在Python里可以用unittest.mock.patch来做这件事。
• 重构函数拆分逻辑：把循环重试的逻辑和核心实验逻辑分开，比如把核心实验写成单独的run_single_try()函数，perform_experiment只负责循环调用它。测试循环逻辑时，直接调用循环部分，传入一个总是返回无效结果的测试函数，统计调用次数。

3. 无法用seed时该怎么做？ #

优先用上面提到的注入mock依赖或猴子补丁的方法。举个简单例子：
假设perform_experiment内部调用is_valid_result(result)判断结果是否有效，测试时我们可以写一个mock函数：

call_count = 0
def mock_is_valid(result):
    global call_count
    call_count += 1
    return False  # 总是返回无效

然后把原函数里的is_valid_result替换成这个mock，执行perform_experiment后，检查call_count是否等于MAX_TRIES即可。

4. 能不能省略这个测试点？ #

不建议省略。这个测试点是在验证函数的容错逻辑完整性——当所有尝试都失败时，函数确实是耗尽了最大尝试次数才返回空，而不是因为循环提前终止（比如循环条件写错、中途抛出异常未处理等）。根据描述MAX_TRIES远大于NUMBER_OF_RESULTS，说明重试容错是这个函数的核心设计之一，省略这个测试很可能放过严重的逻辑bug。

内容的提问来源于stack exchange，提问作者Allan