将c.t.c/quick-check重构为状态机以提供更多扩展点

Question

我们可以将quick-check过程想象成一个具有类似状态流的状态机：

`

   started
      v

尝试，尝试，[...]

      v

成功 | 失败

             v
shrinking, shrinking, [...]
             v
           shrunk"

`

过程开始，根据生成的值运行试验，它要么成功要么失败。如果成功，则过程结束。如果失败，然后它会运行失败的 Params 的连续压缩直到达到终端压缩状态。

以这种方式表示过程，我们可以在过程的有趣点上调用step-fn，它有两个用途：
- 向用户反馈关于过程的反馈（通过副作用）
- 增强或修改流程跟踪的状态，使实现就像在流程完成之前优雅地终止过程、对生成的值计算统计信息（TCHECK-87）、添加时间戳（TCHECK-8、TCHECK-95、TCHECK-96）等变得容易。

附带的补丁旨在实现100%向后兼容。添加了新的函数{{clojure.test.check2/quick-check}}。旧函数{{clojure.test.check/quick-check}}通过调用新函数重新实现，通过在reporter-fn->step-fn适配器函数中将reporter-fn提升为step-fn来保持所有当前行为。

编辑：添加了一个替代补丁（TCHECK126-test.check-refactor.patch），该补丁将c.t.c/quick-check“原地”重构，而不是添加一个新的test.check2命名空间。最重要的变化是，它从reporter-fn切换到step-fn，这使得通过将step-fn的返回值反馈到quick-check状态（即改变）来驱动或增强quick-check过程成为可能。

Answer 1

-comment by: nberger

增加了一个替代补丁（TCHECK126-test.check-refactor.patch），它对c.t.c/quick-check进行“原地”重构，而不是添加一个新的test.check2命名空间。最重要的改变是，它从reporter-fn切换到了step-fn，这为通过向quick-check状态（作为step-fn的返回值）反馈更改来驱动/增强quick-check过程提供了可能性。

尽管reporter-fn已经存在于master分支中有一段时间了，但它从未成为版本发布的一部分，因此我提议从reporter-fn切换到这个新的step-fn，希望它能在下一次发布之前被整合。

Answer 2

参考：[https://clojure.atlassian.net/browse/TCHECK-126](https://clojure.atlassian.net/browse/TCHECK-126)（由nberger报告）