We're updating the issue view to help you get more done. 

Refactor c.t.c/quick-check as a state machine to provide more extension points

Description

We can think of the quick-check process as a state machine with a state flow like:

1 2 3 4 5 6 7 8 9 started v trying, trying, [...] v succeeded | failure v shrinking, shrinking, [...] v shrunk"

The process starts, runs trials based on the generated values and either it succeeds or it fails. If it succeeds, the process is done. If it fails, then it runs successive shrinks of the failed args until it gets to the terminal shrunk state.

Modelling the process this way, we can call a step-fn at interesting points of the process that serves two purposes:

  • Provide feedback to the user about the process (via side-effects)

  • Augment/modify the state being tracked by the process, making it easy to implement things like gracefully aborting the process before it finishes, calculating statistics on the generated values (TCHECK-87), add timestamps (TCHECK-8, TCHECK-95, TCHECK-96), etc.

The attached patch aims at being 100% backwards compatible. Adds a new clojure.test.check2/quick-check function. The "old" clojure.test.check/quick-check is re-implemented by calling the new one, maintaining all the current behavior by lifting the reporter-fn into a step-fn via a reporter-fn->step-fn adapter fn.

EDIT: Added an alternative patch (TCHECK126-test.check-refactor.patch) that refactors `c.t.c/quick-check` "in-place", instead of adding a new test.check2 namespace. The most important change is that it switches from the reporter-fn to a step-fn which gives the possibility to drive/augment the quick-check process by feeding back changes to the quick-check state (as the return value of step-fn).

Environment

None

Status

Assignee

gfredericks

Reporter

Nicolás Berger

Labels

None

Approval

None

Patch

Code and Test

Priority

Major