run tests in parallel on the jvm

Description

Goals

  • deterministic – calling quick-check with parallel opts gives the same answer as without

    • we have to give up some determinism though, because I don't think we could reasonably
      say that the reporter-fn will be called the same way every time, or even that
      the :num-tests value returned should always be the same

  • does the best possible thing on the jvm w.r.t. things hanging

  • is it necessary to have some sort of dynamic var with a thread id or something similar,
    so users can use it to coordinate usage of global resources? alternatively they could
    use a ThreadLocal by hand, or a pool

Issues

  • Is this really worth it? The downside is it makes the API and impl of quick-check more complex, and arguably most use cases could be served by calling quick-check multiple times from separate threads; would a generic test-suite parallelizer do the job for most people?

Environment

None
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

gfredericks

Reporter

gfredericks