When failures occur, I often see something like this in the final shrinked failure:
Operation sequences:
thread #1
#test.carly.core.Wait {:duration 1}
thread #2
#test.carly.core.Wait {:duration 1}
thread #3
#my.ns.FailingOperation {:key "val"}
This implies the generator for the operation sequences isn't able to shrink the amount of threads, even if the failing case doesn't need multiple threads to reproduce.
Currently the test inputs generator uses a gen/bind from the thread count to the operations of each thread. It might be worth writing a custom generator for this that behaves mostly the same, but considers eliminating or consolidating threads as the result of a shrink.
When failures occur, I often see something like this in the final shrinked failure:
This implies the generator for the operation sequences isn't able to shrink the amount of threads, even if the failing case doesn't need multiple threads to reproduce.
Currently the test inputs generator uses a
gen/bindfrom the thread count to the operations of each thread. It might be worth writing a custom generator for this that behaves mostly the same, but considers eliminating or consolidating threads as the result of a shrink.